Date: Sun, 29 Oct 2023 20:05:14 +0100 (CET) From: Wojciech Puchar <wojtek@puchar.net> To: Mark Millard <marklmi@yahoo.com> Cc: Dimitry Andric <dim@FreeBSD.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: problem linking kernel Message-ID: <8e5b7eea-cfb-1cbb-8eb-18ea18b230d4@puchar.net> In-Reply-To: <FA0E9EEA-B282-4DBD-8FF8-183DAD91CFE4@yahoo.com> References: <FA0E9EEA-B282-4DBD-8FF8-183DAD91CFE4.ref@yahoo.com> <FA0E9EEA-B282-4DBD-8FF8-183DAD91CFE4@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3974694515-1688657752-1698606316=:1940 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 8BIT right but anyway it was my fault i for some reason some time ago changed $PATH so /usr/local had precedence. On Sun, 29 Oct 2023, Mark Millard wrote: > From: Wojciech Puchar <wojtek_at_puchar.net> wrote on > Date: Sun, 29 Oct 2023 12:16:31 UTC : > >> reason found. >> >> >> /usr/local/bin/ld which is part of gcc from ports takes precedence > > I've run into the FreeBSD system toolchain using a linker > that was below /usr/local/ multiple times before. I try to > avoid building ports that results in the conflict. > > But, in my view, the FreeBSD toolchain should require an > explicit command line option to be willing to use part > of a toolchain that is someplace under /usr/local/ instead > of using its own toolchain materials for everything. > > See, for example, my report from 2022-Sept: > > https://lists.freebsd.org/archives/freebsd-toolchain/2022-September/000898.html > > where, in an aarch64 context, it used: > > /usr/local/bin/aarch64-unknown-freebsd14.0-ld > > instead of: > > /sur/bin/ld > or: > /usr/bin/dl.lld > > It did not do this if -fuse-ld=lld was explicitly indicated on > the command line: one way to avoid the problem. > > What is used can be seen in the extra output from use of: > > clang++ -v > > Back then the example was: > > clang++ -v -std=c++20 -Wpedantic -Wall -Wextra -I../other_src_used -pedantic -g3 -O3 -mcpu=cortex-a72 -flto=thin -pthread -flto=thin ../objs/cpp_thousandslocale-clang++_14_O3lto-libc++.o ../objs/cpp_clockinfo-clang++_14_O3lto-libc++.o -o ../cpp_clockinfo_main-HoneyComb-65536MiB-threads_16-LP64-FreeBSD_main_n256584_5bc926af9fd1_64bit-clang++_14_O3lto-libc++ -DCPPCLOCKINFO_VERS='"acpphint_0.1.24"' ../other_src_used/cpp_clockinfo_main.cpp > FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c) > Target: aarch64-unknown-freebsd14.0 > Thread model: posix > InstalledDir: /usr/bin > "/usr/bin/clang++" -cc1 -triple aarch64-unknown-freebsd14.0 -emit-llvm-bc -flto=thin -flto-unit -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name cpp_clockinfo_main.cpp -mrelocation-model static -mframe-pointer=non-leaf -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu cortex-a72 -target-feature +v8a -target-feature +fp-armv8 -target-feature +neon -target-feature +crc -target-feature +crypto -target-feature +sha2 -target-feature +aes -target-abi aapcs -fallow-half-arguments-and-returns -mllvm -treat-scalable-fixed-error-as-warning -debug-info-kind=standalone -dwarf-version=4 -debugger-tuning=gdb -v -fcoverage-compilation-dir=/root/acpphint/acpphint_src -resource-dir /usr/lib/clang/14.0.5 -I ../other_src_used -D "CPPCLOCKINFO_VERS=\"acpphint_0.1.24\"" -internal-isystem /usr/include/c++/v1 -O3 -Wpedantic -Wall -Wextra -pedantic -std=c++20 -fdeprecated-macro -fdebug-compilation-dir=/root/a! cpphint/acpphint_src -ferror-limit 19 -pthread -fno-signed-char -fgnuc-version=4.2.1 -fno-implicit-modules -fcxx-exceptions -fexceptions -fcolor-diagnostics -vectorize-loops -vectorize-slp -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/cpp_clockinfo_main-56273f.o -x c++ ../other_src_used/cpp_clockinfo_main.cpp > clang -cc1 version 14.0.5 based upon LLVM 14.0.5 default target aarch64-unknown-freebsd14.0 > #include "..." search starts here: > #include <...> search starts here: > ../other_src_used > /usr/include/c++/v1 > /usr/lib/clang/14.0.5/include > /usr/include > End of search list. > "/usr/local/bin/aarch64-unknown-freebsd14.0-ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --enable-new-dtags -o ../cpp_clockinfo_main-HoneyComb-65536MiB-threads_16-LP64-FreeBSD_main_n256584_5bc926af9fd1_64bit-clang++_14_O3lto-libc++ /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib -plugin /usr/bin/../lib/LLVMgold.so -plugin-opt=mcpu=cortex-a72 -plugin-opt=O3 -plugin-opt=thinlto ../objs/cpp_thousandslocale-clang++_14_O3lto-libc++.o ../objs/cpp_clockinfo-clang++_14_O3lto-libc++.o /tmp/cpp_clockinfo_main-56273f.o -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o > /usr/local/bin/aarch64-unknown-freebsd14.0-ld: /usr/bin/../lib/LLVMgold.so: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" > clang++: error: linker command failed with exit code 1 (use -v to see invocation) > *** Error code 1 > > Note the: "/usr/local/bin/aarch64-unknown-freebsd14.0-ld" after the search list. > > It looks like I did not report my PATH back then. But finding and using > aarch64-unknown-freebsd14.0-ld is not going to be found under any > system path for the system toolchain. So my view is that the name > should not be looked for by the system toolchain --or should be last > if the normal system names are not found. > > FYI: > > # echo $PATH > /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/home/root/bin > > and it is unlikely to have had any changes since back then. > >> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games make >> >> and all builds >> >> On Sun, 29 Oct 2023, Dimitry Andric wrote: >> >>> On 29 Oct 2023, at 11:34, Wojciech Puchar <wojtek@puchar.net> wrote: >>>> >>>> i get this linking my custom kernel. No errors until link >>>> >>>> linking kernel >>>> ld: dynamic STT_GNU_IFUNC symbol `rdtsc_ordered' with pointer equality in `cpu_machdep.o' can not be used when making an executable; recompile with -fPIE and relink with -pie >>>> >>>> >>>> kernel config attached, latest FreeBSD-13 downloaded today. >>>> >>>> can you help?<conf.txt> >>> >>> I just tried it here, and it works fine: >>> >>> ... >>> linking kernel >>> objcopy --strip-debug kernel >>> text data bss dec hex filename >>> 7925073 779012 3411328 12115413 0xb8ddd5 kernel >>> -------------------------------------------------------------- >>>>>> Kernel build for PUCHAR completed on Sun Oct 29 12:06:08 UTC 2023 >>> -------------------------------------------------------------- >>>>>> Kernel(s) PUCHAR built in 28 seconds, ncpu: 32, make -j32 >>> -------------------------------------------------------------- >>> > > === > Mark Millard > marklmi at yahoo.com > > > --3974694515-1688657752-1698606316=:1940--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8e5b7eea-cfb-1cbb-8eb-18ea18b230d4>