Date: Wed, 4 Sep 2019 13:38:08 -0700 From: Mark Millard <marklmi@yahoo.com> To: Sid <sid@bsdmail.com> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: linker not using make.conf Message-ID: <B6D72F66-99BF-4F42-AA73-8A7320D3A421@yahoo.com> In-Reply-To: <trinity-f7249ad8-8384-426d-8015-21a67f243ab5-1567622104520@3c-app-mailcom-lxa13> References: <trinity-008aa4cb-9c85-4504-9364-cd7875281113-1567544648345@3c-app-mailcom-lxa02> <20190904151842.GA71523@spindle.one-eyed-alien.net> <trinity-f7249ad8-8384-426d-8015-21a67f243ab5-1567622104520@3c-app-mailcom-lxa13>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-Sep-4, at 11:35, Sid <sid at bsdmail.com> wrote:
> When the base linker is not available, the link needs to be from =
/usr/bin/ld rather than from /usr/local/*/ to /usr/local/bin/ld.lld80 or =
variant of that. Also, programs being compiled do look for /usr/bin/ld =
or maybe another ld under /usr/local/*. There were about two locations =
that could be used for each version of the compiler and its toolchain, =
one like you described, because another also had a soft link.
>=20
> Mine works, since I have a soft link from /usr/bin/ld to the needed =
one in /usr/local/bin/*
>=20
> If I remember correctly, installing xtoolchain-llvm didn't do much, =
except for give hints on what to put as XLD. =46rom trial an error, I =
found that, LD covers everything, including what XLD covers, except when =
XLD is used, it overrides LD only for ports. In other words, LD in =
make.conf covered building the kernel, base, and ports. When XLD was =
set, it overrode LD's settings only for ports. At least the X version =
(XCC, XCXX, compared to CC, CXX) of the other make.conf setting.
>=20
> The point is, I wonder how much confusion is being caused for =
developers, when LD and XLD are not working as they are supposed to. =
When one gets fixed, but ends up with the same problem, because the base =
linker is used, rather than the one make.conf is intended to make work. =
I wonder if this has to do with why some ports require llvm80, and =
others llvm60, when the assumption is on the wrong needed update, when =
it's not using the linkers from those. I also guess that, this is =
causing difficulties for when trying to make clang's utils work for =
different architectures. A problem like this doesn't help, and it likely =
slows down development, that a new release must be waited for before =
significant improvements can be made. The LD setting in make.conf not =
working properly is a fundamental problem, that can cause other =
problems, and false assumptions.
>=20
> It's more difficult to see the problem, if the base ld is available.
>=20
>=20
>> Sent: Wednesday, September 04, 2019 at 10:18 AM
>> From: <brooks@freebsd.org>
>> Cc: freebsd-toolchain@freebsd.org
>> Subject: Re: linker not using make.conf
>=20
>> The LD variable only effects the very few cases where the linker is =
called
>> directly. The linker is almost always run via clang. If you install =
the
>> xtoolchain-llvm80 port it will install a link from
>> /usr/local/llvm80/bin/ld.lld to /usr/local/llvm80/bin/ld which I =
think will
>> be sufficient for your use case.
>>=20
>> On Tue, Sep 03, 2019 at 11:04:08PM +0200, Sid wrote:
>>> In /etc/make.conf, I have
>>> LD=3D /usr/local/bin/ld.lld80
>>>=20
>>> This is not used for ports. It may be used for building the kernel =
and world.
>>>=20
>>> clang-8: error: unable to execute command: Executable "ld" doesn't =
exist!
>>> clang-8: error: linker command failed with exit code 1 (use -v to =
see invocation)
>>> *** Error code 1
>>>=20
>>> XLD=3D /usr/local/bin/ld.lld80 being set as well also provides the =
same error. XD sets it for all, but XLD is only applicable if a =
different compiler is used for ports than kernel and the base. When LD =
is set, XLD only applies when it is set as well, but this suggests that =
XLD is not working correctly either.
>>>=20
>>> I have to manually link /usr/bin/ld to /usr/local/bin/ld.lld80 for =
ports to build correctly. This is with both make, and with portmaster.
>>>=20
>>> I built my computer without ld in the base system, and this has =
worked well. make.conf should reference the chosen linker without having =
to manually link it. Otherwise, LD in make.conf is not working =
correctly, and gives the impression that one linker is used, when it's =
not. This can cause faulty conclusions and confusion for developers as =
well, who think one linker is set, when it's not.
May be what brooks was referring to is not familiar.
So I show examples for system-clang++, llvm90's
clang++90, and g++9.
Here is an example of building and linking a program:
# c++ -std=3Dc++17 -pedantic -O3 -pthread -c cpp_thousandslocale.cpp
# c++ -std=3Dc++17 -pedantic -O3 -pthread -c cpp_clockinfo.cpp
# c++ -std=3Dc++17 -pedantic -O3 -pthread cpp_thousandslocale.o =
cpp_clockinfo.o -o cpp_clockinfo_main cpp_clockinfo_main.cpp
That last runs a linker aa part of its activity.
It make s no use of makefile macros or environment variables LD or XLD.
This would be true even if if comamnds were in a makefile.
Use of the -### option for the last of those commands shows the link
command that clang used ("/usr/bin/ld"):
FBSDFHUGE# c++ -### -std=3Dc++17 -pedantic -O3 -pthread =
cpp_thousandslocale.o cpp_clockinfo.o -o cpp_clockinfo_main =
cpp_clockinfo_main.cpp
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on =
LLVM 8.0.1)
Target: x86_64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin
"/usr/bin/c++" "-cc1" "-triple" "x86_64-unknown-freebsd13.0" =
"-emit-obj" "-disable-free" "-main-file-name" "cpp_clockinfo_main.cpp" =
"-mrelocation-model" "static" "-mthread-model" "posix" =
"-mdisable-fp-elim" "-masm-verbose" "-mconstructor-aliases" =
"-munwind-tables" "-fuse-init-array" "-target-cpu" "x86-64" =
"-dwarf-column-info" "-debugger-tuning=3Dgdb" "-resource-dir" =
"/usr/lib/clang/8.0.1" "-internal-isystem" "/usr/include/c++/v1" "-O3" =
"-pedantic" "-std=3Dc++17" "-fdeprecated-macro" =
"-fdebug-compilation-dir" "/root/c_tests" "-ferror-limit" "19" =
"-fmessage-length" "200" "-pthread" "-fobjc-runtime=3Dgnustep" =
"-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" =
"-fcolor-diagnostics" "-vectorize-loops" "-vectorize-slp" "-o" =
"/tmp/cpp_clockinfo_main-bf9d80.o" "-x" "c++" "cpp_clockinfo_main.cpp" =
"-faddrsig"
"/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" =
"--hash-style=3Dboth" "--enable-new-dtags" "-o" "cpp_clockinfo_main" =
"/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" =
"cpp_thousandslocale.o" "cpp_clockinfo.o" =
"/tmp/cpp_clockinfo_main-bf9d80.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"
Systenm-clang makes no use of ${LD} or ${XLD} but directly tries to use =
/usr/bin/ld
instead.
Similarly for devel/llvm90 : its clang++90 uses
"/usr/local/llvm90/bin/ld" directly:
# clang++90 -std=3Dc++17 -pedantic -O3 -pthread -c =
cpp_thousandslocale.cpp
# clang++90 -std=3Dc++17 -pedantic -O3 -pthread -c cpp_clockinfo.cpp
# clang++90 -std=3Dc++17 -pedantic -O3 -pthread cpp_thousandslocale.o =
cpp_clockinfo.o -o cpp_clockinfo_main cpp_clockinfo_main.cpp
Again using -### :
# clang++90 -### -std=3Dc++17 -pedantic -O3 -pthread =
cpp_thousandslocale.o cpp_clockinfo.o -o cpp_clockinfo_main =
cpp_clockinfo_main.cpp
clang version 9.0.0 (tags/RELEASE_900/rc2)
Target: x86_64-portbld-freebsd13.0
Thread model: posix
InstalledDir: /usr/local/llvm90/bin
"/usr/local/llvm90/bin/clang-9" "-cc1" "-triple" =
"x86_64-portbld-freebsd13.0" "-emit-obj" "-disable-free" =
"-disable-llvm-verifier" "-discard-value-names" "-main-file-name" =
"cpp_clockinfo_main.cpp" "-mrelocation-model" "static" "-mthread-model" =
"posix" "-mdisable-fp-elim" "-masm-verbose" "-mconstructor-aliases" =
"-munwind-tables" "-fuse-init-array" "-target-cpu" "x86-64" =
"-dwarf-column-info" "-debugger-tuning=3Dgdb" "-resource-dir" =
"/usr/local/llvm90/lib/clang/9.0.0" "-internal-isystem" =
"/usr/include/c++/v1" "-O3" "-pedantic" "-std=3Dc++17" =
"-fdeprecated-macro" "-fdebug-compilation-dir" "/root/c_tests" =
"-ferror-limit" "19" "-fmessage-length" "200" "-pthread" =
"-fobjc-runtime=3Dgnustep" "-fcxx-exceptions" "-fexceptions" =
"-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops" =
"-vectorize-slp" "-faddrsig" "-o" "/tmp/cpp_clockinfo_main-bb1750.o" =
"-x" "c++" "cpp_clockinfo_main.cpp"
"/usr/local/llvm90/bin/ld" "--eh-frame-hdr" "-dynamic-linker" =
"/libexec/ld-elf.so.1" "--hash-style=3Dboth" "--enable-new-dtags" "-o" =
"cpp_clockinfo_main" "/usr/lib/crt1.o" "/usr/lib/crti.o" =
"/usr/lib/crtbegin.o" "-L/usr/lib" "cpp_thousandslocale.o" =
"cpp_clockinfo.o" "/tmp/cpp_clockinfo_main-bb1750.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"
Similarly for g++9 which uses "/usr/local/bin/ld" directly:
# g++9 -std=3Dc++17 -pedantic -O3 -pthread -c cpp_thousandslocale.cpp
# g++9 -std=3Dc++17 -pedantic -O3 -pthread -c cpp_clockinfo.cpp
# g++9 -std=3Dc++17 -pedantic -O3 -pthread cpp_thousandslocale.o =
cpp_clockinfo.o -o cpp_clockinfo_main cpp_clockinfo_main.cpp
Again using -### :
# g++9 -### -std=3Dc++17 -pedantic -O3 -pthread cpp_thousandslocale.o =
cpp_clockinfo.o -o cpp_clockinfo_main cpp_clockinfo_main.cpp
Using built-in specs.
COLLECT_GCC=3Dg++9
=
COLLECT_LTO_WRAPPER=3D/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13=
.0/9.2.0/lto-wrapper
Target: x86_64-portbld-freebsd13.0
Configured with: /wrkdirs/usr/ports/lang/gcc9/work/gcc-9.2.0/configure =
--enable-multilib --with-build-config=3Dbootstrap-debug --disable-nls =
--enable-gnu-indirect-function --libdir=3D/usr/local/lib/gcc9 =
--libexecdir=3D/usr/local/libexec/gcc9 --program-suffix=3D9 =
--with-as=3D/usr/local/bin/as --with-gmp=3D/usr/local =
--with-gxx-include-dir=3D/usr/local/lib/gcc9/include/c++/ =
--with-ld=3D/usr/local/bin/ld --with-pkgversion=3D'FreeBSD Ports =
Collection' --with-system-zlib --enable-languages=3Dc,c++,objc,fortran =
--prefix=3D/usr/local --localstatedir=3D/var --mandir=3D/usr/local/man =
--infodir=3D/usr/local/share/info/gcc9 =
--build=3Dx86_64-portbld-freebsd13.0
Thread model: posix
gcc version 9.2.0 (FreeBSD Ports Collection)=20
COLLECT_GCC_OPTIONS=3D'-std=3Dc++17' '-Wpedantic' '-O3' '-pthread' '-o' =
'cpp_clockinfo_main' '-shared-libgcc' '-mtune=3Dgeneric' '-march=3Dx86-64'=
/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/cc1plus =
-quiet cpp_clockinfo_main.cpp -quiet -dumpbase cpp_clockinfo_main.cpp =
"-mtune=3Dgeneric" "-march=3Dx86-64" -auxbase cpp_clockinfo_main -O3 =
-Wpedantic "-std=3Dc++17" -o /tmp//ccqXOrjE.s
COLLECT_GCC_OPTIONS=3D'-std=3Dc++17' '-Wpedantic' '-O3' '-pthread' '-o' =
'cpp_clockinfo_main' '-shared-libgcc' '-mtune=3Dgeneric' '-march=3Dx86-64'=
/usr/local/bin/as -o /tmp//ccxktS2W.o /tmp//ccqXOrjE.s
=
COMPILER_PATH=3D/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2=
.0/:/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/:/usr/loc=
al/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/:/usr/local/lib/gcc9/gcc/x8=
6_64-portbld-freebsd13.0/9.2.0/:/usr/local/lib/gcc9/gcc/x86_64-portbld-fre=
ebsd13.0/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/../../.=
./../../x86_64-portbld-freebsd13.0/bin/
=
LIBRARY_PATH=3D/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/:/=
usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/../../../../../x86=
_64-portbld-freebsd13.0/lib/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebs=
d13.0/9.2.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS=3D'-std=3Dc++17' '-Wpedantic' '-O3' '-pthread' '-o' =
'cpp_clockinfo_main' '-shared-libgcc' '-mtune=3Dgeneric' '-march=3Dx86-64'=
/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/collect2 =
-plugin =
/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/liblto_plugin=
.so =
"-plugin-opt=3D/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.=
0/lto-wrapper" "-plugin-opt=3D-fresolution=3D/tmp//ccA61h1w.res" =
"-plugin-opt=3D-pass-through=3D-lgcc_s" =
"-plugin-opt=3D-pass-through=3D-lgcc" =
"-plugin-opt=3D-pass-through=3D-lpthread" =
"-plugin-opt=3D-pass-through=3D-lc" "-plugin-opt=3D-pass-through=3D-lgcc_s=
" "-plugin-opt=3D-pass-through=3D-lgcc" --eh-frame-hdr -m =
elf_x86_64_fbsd -dynamic-linker /libexec/ld-elf.so.1 -o =
cpp_clockinfo_main /usr/lib/crt1.o /usr/lib/crti.o =
/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/crtbegin.o =
-L/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0 =
-L/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/../../../../../=
x86_64-portbld-freebsd13.0/lib =
-L/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/../../.. =
cpp_thousandslocale.o cpp_clockinfo.o /tmp//ccxktS2W.o "-lstdc++" -lm =
-lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc =
/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/crtend.o =
/usr/lib/crtn.o
COLLECT_GCC_OPTIONS=3D'-std=3Dc++17' '-Wpedantic' '-O3' '-pthread' '-o' =
'cpp_clockinfo_main' '-shared-libgcc' '-mtune=3Dgeneric' '-march=3Dx86-64'=
Although here it is less obvious what:
/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/collect2
ends up using. So using truss produced the evidence:
3472: execve("/usr/local/bin/ld",0x800b35180,0x7fffffffd380) EJUSTRETURN
Again: no use of ${LD} or ${XLD} .
Builds that want to control which linker is used need to avoid
using such commands and instead use ${LD} or ${XLD} or such
explicitly. Many do not do this.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B6D72F66-99BF-4F42-AA73-8A7320D3A421>