Discussion:
problem linking kernel
(too old to reply)
Dimitry Andric
2023-10-29 12:07:40 UTC
Permalink
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
--------------------------------------------------------------

-Dimitry
Wojciech Puchar
2023-10-29 12:10:10 UTC
Permalink
fine. so where to seek a problem. userland is the same as kernel.
can some leftover files in /usr or something in other configuration cause
that?

Now i compiled it too on my laptop without problems
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>
...
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
--------------------------------------------------------------
-Dimitry
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Wojciech Puchar
2023-10-29 12:16:31 UTC
Permalink
reason found.


/usr/local/bin/ld which is part of gcc from ports takes precedence

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games make

and all builds
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>
...
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
--------------------------------------------------------------
-Dimitry
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Mark Millard
2023-10-29 17:11:15 UTC
Permalink
From: Wojciech Puchar <wojtek_at_puchar.net> wrote on
Post by Wojciech Puchar
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/acpphint/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.
Post by Wojciech Puchar
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games make
and all builds
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>
...
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



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Wojciech Puchar
2023-10-29 19:05:14 UTC
Permalink
right but anyway it was my fault i for some reason some time ago changed
$PATH so /usr/local had precedence.
Post by Mark Millard
From: Wojciech Puchar <wojtek_at_puchar.net> wrote on
Post by Wojciech Puchar
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.
https://lists.freebsd.org/archives/freebsd-toolchain/2022-September/000898.html
/usr/local/bin/aarch64-unknown-freebsd14.0-ld
/sur/bin/ld
/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.
clang++ -v
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
Post by Mark Millard
clang -cc1 version 14.0.5 based upon LLVM 14.0.5 default target aarch64-unknown-freebsd14.0
../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.
# 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.
Post by Wojciech Puchar
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games make
and all builds
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>
...
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
David Chisnall
2023-10-30 09:31:26 UTC
Permalink
right but anyway it was my fault i for some reason some time ago changed $PATH so /usr/local had precedence.
That is a common setting and I don’t think it should break the build. Both Clang and GCC support a -B flag that specifies the directory for the tools to use. We should probably be passing that from the build system, since the FreeBSD built system has a notion of tool sets and where they come from.

David



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...