Bug 241003

Summary: make buildworld ignores make.conf LD parameter
Product: Base System Reporter: oz42
Component: binAssignee: Mark Linimon <linimon>
Status: Closed Works As Intended    
Severity: Affects Only Me CC: emaste, imp, marklmi26-fbsd
Priority: ---    
Version: 12.0-RELEASE   
Hardware: i386   
OS: Any   

Description oz42 2019-10-02 10:48:17 UTC
/usr/local/bin/clang++80 -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections -fdata-sections -DNDEBUG -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -Wl,--gc-sections -static  -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib -o llvm-tblgen  AsmMatcherEmitter.o AsmWriterEmitter.o AsmWriterInst.o Attributes.o CTagsEmitter.o CallingConvEmitter.o CodeEmitterGen.o CodeGenDAGPatterns.o CodeGenHwModes.o CodeGenInstruction.o CodeGenMapTable.o CodeGenRegisters.o CodeGenSchedule.o CodeGenTarget.o DAGISelEmitter.o DAGISelMatcher.o DAGISelMatcherEmitter.o DAGISelMatcherGen.o DAGISelMatcherOpt.o DFAPacketizerEmitter.o DisassemblerEmitter.o FastISelEmitter.o FixedLenDecoderEmitter.o GlobalISelEmitter.o InfoByHwMode.o InstrDocsEmitter.o InstrInfoEmitter.o IntrinsicEmitter.o OptParserEmitter.o PseudoLoweringEmitter.o RegisterBankEmitter.o RegisterInfoEmitter.o SDNodeProperties.o SearchableTableEmitter.o SubtargetEmitter.o SubtargetFeatureInfo.o TableGen.o Types.o X86DisassemblerTables.o X86EVEX2VEXTablesEmitter.o X86FoldTablesEmitter.o X86ModRMFilters.o X86RecognizableInstr.o /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/ncurses/ncursesw -lncursesw -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libthr -lpthread -legacy
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

make[3]: stopped in /usr/src/usr.bin/clang/llvm-tblgen

# grep LD /etc/make.conf

# ls -l /usr/local/bin/ld.lld80
-r-xr-xr-x  66 root  wheel  377 Sep 22 23:41 /usr/local/bin/ld.lld80*
root@betsy:/usr/src #
Comment 1 Ed Maste freebsd_committer 2019-11-28 17:12:40 UTC
This is as expected; LD only controls the linker used for direct invocation and does not change the compiler driver's behaviour.

What is your ultimate goal here?
Comment 2 oz42 2019-12-02 08:34:11 UTC
I assume this is a bug because the LD variable is ignored. When it is defined in make.conf, it should be used or - even better - 'make buildworld' should pre-build its own needed ld binary and use that.
Comment 3 Ed Maste freebsd_committer 2019-12-02 18:06:43 UTC
LD is not being ignored, it is used when the build needs to invoke the linker directly (e.g., some parts of the kernel build).

"make buildworld" does build and use its own ld, although maybe that gets broken if you override LD=.

Let me ask a different question, what are you trying to accomplish with LD= in /etc/make.conf?
Comment 4 Mark Millard 2019-12-02 19:16:55 UTC
(In reply to oz42 from comment #0 and #2)

This report is a duplicate of the closed:


Reading the comments there may be appropriate, avoiding
the need to repeat material here.
Comment 5 oz42 2019-12-03 07:38:54 UTC
OK, so LD= is a 'maybe it works, maybe not, good luck, buddy'-setting.

This does just not feel right. Not if it's about FreeBSD.

Last question: where is that behaviour documented?
Comment 6 Ed Maste freebsd_committer 2019-12-03 14:52:36 UTC
(In reply to oz42 from comment #5)
>  OK, so LD= is a 'maybe it works, maybe not, good luck, buddy'-setting.

No, that is not correct. LD works, consistently, to control the linker used for explicit linker invocation in the FreeBSD build.

Again, would you please describe what your ultimate goal is, in setting LD= in src.conf?

I certainly agree that we mustn't have incorrect documentation, so if you can point me at the documentation you followed that described setting LD= in src.conf I'll update it with a note to this effect.
Comment 7 Warner Losh freebsd_committer 2019-12-03 16:18:33 UTC
I think there's some confusion here.

LD=x is used only by our build system when it needs to directly invoke the linker. This is actually fairly rare in the sources as normally the compiler invokes a linker on our behalf. It's a fairly specialized setting and a bit weird to try to set, which suggests to me that this issue may be an attempt to fix another issue that didn't work.

However, I think the problem isn't what LD=xxx does or doesn't do. I think the real problem is with external toolchain support. The compiler invoked in clang++80, but /usr/local/bin/clang++80, which is being used inside of buildworld, but it's not finding ld for some reason. Most likely because it's not in the path of the build environment. clang doesn't get it's notion of what ld to use from there, and it isn't finding it for some reason.

So, we need to get to the bottom of that reason. And we can't do that with the tiny snippet of the logs posted to this bug.

So a bigger picture question: Why are you using /usr/local/bin/clang++80 to buildworld? Let's start there. Maybe there's a CXX= or CC= that in make.conf, and that's causing issues.
Comment 8 oz42 2019-12-04 09:45:38 UTC
Thank you both for clarifying! I am still learning. In fact, the final goal was simply to learn how to build a clang less system using an external toolchain. 
So I suggest we close this bug as it was a misunderstanding on my side.