Bug 240716 - LD in make.conf is not setting linker
Summary: LD in make.conf is not setting linker
Status: Closed Works As Intended
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.0-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-20 21:37 UTC by sid
Modified: 2019-09-26 01:07 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sid 2019-09-20 21:37:25 UTC
LD and XLD in make.conf does not set the linker as it's supposed to do. It always uses base linker. I have to manually softlink /usr/bin/ld to /usr/local/bin/ld.lld* or to binutil's linker.
Comment 1 sid 2019-09-20 21:53:38 UTC
This problem is likely for other architectures as well.
Comment 2 sid 2019-09-20 22:34:14 UTC
Just a reminder.

LD is meant to set the linker for everything: kernel, world and ports.

XLD only overrides LD for ports and perhaps custom source code.

The other options for the compiler in make.conf work this way with CC, CXX, CPP and their variants with the X in front.
Comment 3 sid 2019-09-20 22:36:32 UTC
This problem is also likely for other FreeBSD versions too. It has been a problem in earlier 11 releases. So it's likely for production, stable and current versions.
Comment 4 Mark Millard 2019-09-22 21:44:42 UTC
(In reply to sid from comment #2)

The claims about LD and XLD are false. They only apply
to makefiles that explicitly use ${LD} and/or ${XLD}
notation for linking commands.

Makefiles that use cc, c++, clang, clang++, gcc, or g++
commands (or other such) to request linking do not use
LD or XLD and are not intended to use them.

In any case where LD or XLD was not used, check if the
makefile involved used ${LD} or ${XLD} or not.

I expect that this defect report will be rejected by
those that can do so.

(The same points were made on the lists by multiple
people, me being one of them.)
Comment 5 sid 2019-09-23 09:11:44 UTC
In make.conf

 COMPILER_TYPE=  clang
 CC=             /usr/local/bin/clang*0
 CXX=            /usr/local/bin/clang++*0
 CPP=            /usr/local/bin/clang-cpp*0

these arguments set the compiler for the whole system, base system and kernel, which is not limited to ports, which makefiles of ports are about.
 LD=

is supposed to set the linker, as CC, CXX and CPP do.

XCC, XCXX, XCPP and XLD are specifically about port makefiles, so makefiles about ports can apply to these arguments containing the prefix of X.

LD has to do with the base system, and everything else. It's not specific to port makefiles.

If LD is not being used, why is it an argument? The linker for everything should be able to be chosen from make.conf, even if the one from base is to be recommended. LD still works for building world and ports, and it did and is still meant to set the linker for the kernel.

I believe a lot of bugs will remain hidden, if it is assumed that LD in make.conf sets the actual linker. This is going to hide bugs that may be impeding why the linker for other architectures isn't consistent. It is going to slow down using the fixes similar to those from the base linker that work, to the linkers in ports that don't work for everything.
Comment 6 sid 2019-09-23 09:41:47 UTC
In a previous 11 release, LD did set the linker for base, kernel and ports. Then in another 11 release, and in 12.0, the LD argument in make.conf stopped working.

Linking manually allowed all linkers to build ports and the world. Binutil's linker can build everything.

In my last post, I left out that CC, CXX and CPP also builds ports, as well as world and kernel. XCC, XCXX and XCPP override for ports only.

When a port requires a linker, it usually pulls in binutil's linker. LLVM60 and LLVM80 get pulled in as a requirement for some ports, possibly because of the linker, which is not independent of the package.

These details about LD and LLVM's linkers need to be documented, or at least addressed in 12.1, stable or current. LD was intended to set the linker, and it should.
Comment 7 sid 2019-09-23 22:55:00 UTC
Ok, I understand a little more.

LD for everything was meant to be overridden by the makefile in /usr/src/.

It should be addressed still in 12-stable, current and for later llvm versions in ports, for the purpose of finding and fixing bugs.
Comment 8 Mark Millard 2019-09-24 02:57:04 UTC
(In reply to sid from comment #5)

QUOTE
If LD is not being used, why is it an argument?
END QUOTE

Some makefiles use ${LD} (or ${XLD}) to request linking.
many do not. That some do use them is enough to justify
the existence of LD (and XLD) in the infrastructure.

In effect you are requesting changes to a large number
of makefiles to work differently than they do now: to
explicitly use ${LD} (or ${XLD}) based link commands
instead of what they now use.

There are issues, such as powerpc family --secure-plt
clang output being incompatible with modern binutils'
ld: ld reverts to bss plt and returns on error code
because it did so. One can not switch linkers
independently in all cases, only some.
Comment 9 Ed Maste freebsd_committer 2019-09-26 01:07:55 UTC
It is perhaps inconvenient that LD controls only direct linker invocations from Makefiles, not the linker invoked by the compiler driver, but this is as expected.

You may be able to make use of the compiler's -B option.