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.
>
> Mine works, since I have a soft link from /usr/bin/ld to the needed one in
> /usr/local/bin/*
>
> If I remember correctly, installing xtoolchain-llvm didn't do much, except
> for give hints on what to put as XLD. From 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.
>
> 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.
>
> It's more difficult to see the problem, if the base ld is available.
>
>
>> Sent: Wednesday, September 04, 2019 at 10:18 AM
>> From: <[email protected]>
>> Cc: [email protected]
>> Subject: Re: linker not using make.conf
>
>> 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.
>>
>> On Tue, Sep 03, 2019 at 11:04:08PM +0200, Sid wrote:
>>> In /etc/make.conf, I have
>>> LD= /usr/local/bin/ld.lld80
>>>
>>> This is not used for ports. It may be used for building the kernel and
>>> world.
>>>
>>> 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
>>>
>>> XLD= /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.
>>>
>>> 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.
>>>
>>> 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=c++17 -pedantic -O3 -pthread -c cpp_thousandslocale.cpp
# c++ -std=c++17 -pedantic -O3 -pthread -c cpp_clockinfo.cpp
# c++ -std=c++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=c++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=gdb" "-resource-dir"
"/usr/lib/clang/8.0.1" "-internal-isystem" "/usr/include/c++/v1" "-O3"
"-pedantic" "-std=c++17" "-fdeprecated-macro" "-fdebug-compilation-dir"
"/root/c_tests" "-ferror-limit" "19" "-fmessage-length" "200" "-pthread"
"-fobjc-runtime=gnustep" "-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=both" "--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=c++17 -pedantic -O3 -pthread -c cpp_thousandslocale.cpp
# clang++90 -std=c++17 -pedantic -O3 -pthread -c cpp_clockinfo.cpp
# clang++90 -std=c++17 -pedantic -O3 -pthread cpp_thousandslocale.o
cpp_clockinfo.o -o cpp_clockinfo_main cpp_clockinfo_main.cpp
Again using -### :
# clang++90 -### -std=c++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=gdb" "-resource-dir"
"/usr/local/llvm90/lib/clang/9.0.0" "-internal-isystem" "/usr/include/c++/v1"
"-O3" "-pedantic" "-std=c++17" "-fdeprecated-macro" "-fdebug-compilation-dir"
"/root/c_tests" "-ferror-limit" "19" "-fmessage-length" "200" "-pthread"
"-fobjc-runtime=gnustep" "-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=both" "--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=c++17 -pedantic -O3 -pthread -c cpp_thousandslocale.cpp
# g++9 -std=c++17 -pedantic -O3 -pthread -c cpp_clockinfo.cpp
# g++9 -std=c++17 -pedantic -O3 -pthread cpp_thousandslocale.o cpp_clockinfo.o
-o cpp_clockinfo_main cpp_clockinfo_main.cpp
Again using -### :
# g++9 -### -std=c++17 -pedantic -O3 -pthread cpp_thousandslocale.o
cpp_clockinfo.o -o cpp_clockinfo_main cpp_clockinfo_main.cpp
Using built-in specs.
COLLECT_GCC=g++9
COLLECT_LTO_WRAPPER=/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=bootstrap-debug --disable-nls
--enable-gnu-indirect-function --libdir=/usr/local/lib/gcc9
--libexecdir=/usr/local/libexec/gcc9 --program-suffix=9
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc9/include/c++/
--with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection'
--with-system-zlib --enable-languages=c,c++,objc,fortran --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/share/info/gcc9 --build=x86_64-portbld-freebsd13.0
Thread model: posix
gcc version 9.2.0 (FreeBSD Ports Collection)
COLLECT_GCC_OPTIONS='-std=c++17' '-Wpedantic' '-O3' '-pthread' '-o'
'cpp_clockinfo_main' '-shared-libgcc' '-mtune=generic' '-march=x86-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=generic"
"-march=x86-64" -auxbase cpp_clockinfo_main -O3 -Wpedantic "-std=c++17" -o
/tmp//ccqXOrjE.s
COLLECT_GCC_OPTIONS='-std=c++17' '-Wpedantic' '-O3' '-pthread' '-o'
'cpp_clockinfo_main' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/local/bin/as -o /tmp//ccxktS2W.o /tmp//ccqXOrjE.s
COMPILER_PATH=/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/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/../../../../../x86_64-portbld-freebsd13.0/bin/
LIBRARY_PATH=/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-freebsd13.0/9.2.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-std=c++17' '-Wpedantic' '-O3' '-pthread' '-o'
'cpp_clockinfo_main' '-shared-libgcc' '-mtune=generic' '-march=x86-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=/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/lto-wrapper"
"-plugin-opt=-fresolution=/tmp//ccA61h1w.res"
"-plugin-opt=-pass-through=-lgcc_s" "-plugin-opt=-pass-through=-lgcc"
"-plugin-opt=-pass-through=-lpthread" "-plugin-opt=-pass-through=-lc"
"-plugin-opt=-pass-through=-lgcc_s" "-plugin-opt=-pass-through=-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 -lg
cc_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='-std=c++17' '-Wpedantic' '-O3' '-pthread' '-o'
'cpp_clockinfo_main' '-shared-libgcc' '-mtune=generic' '-march=x86-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.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[email protected]"
