Date: Wed, 4 Sep 2019 20:35:04 +0200 From: Sid <sid@bsdmail.com> To: "Brooks Davis" <brooks@freebsd.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: linker not using make.conf Message-ID: <trinity-f7249ad8-8384-426d-8015-21a67f243ab5-1567622104520@3c-app-mailcom-lxa13> In-Reply-To: <20190904151842.GA71523@spindle.one-eyed-alien.net> References: <trinity-008aa4cb-9c85-4504-9364-cd7875281113-1567544648345@3c-app-mailcom-lxa02> <20190904151842.GA71523@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 anot= her ld under /usr/local/*. There were about two locations that could be us= ed for each version of the compiler and its toolchain, one like you descri= bed, 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 bu= ilding the kernel, base, and ports. When XLD was set, it overrode LD's set= tings only for ports. At least the X version (XCC, XCXX, compared to CC, C= XX) 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 fix= ed, but ends up with the same problem, because the base linker is used, ra= ther 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 ass= umption is on the wrong needed update, when it's not using the linkers fro= m those. I also guess that, this is causing difficulties for when trying t= o 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 mu= st be waited for before significant improvements can be made. The LD setti= ng in make.conf not working properly is a fundamental problem, that can ca= use 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: <brooks@freebsd.org> > Cc: freebsd-toolchain@freebsd.org > Subject: Re: linker not using make.conf > The LD variable only effects the very few cases where the linker is call= ed > directly. The linker is almost always run via clang. If you install th= e > xtoolchain-llvm80 port it will install a link from > /usr/local/llvm80/bin/ld.lld to /usr/local/llvm80/bin/ld which I think w= ill > 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=3D /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 ex= ist! > > clang-8: error: linker command failed with exit code 1 (use -v to see= invocation) > > *** Error code 1 > > > > XLD=3D /usr/local/bin/ld.lld80 being set as well also provides the sa= me error. XD sets it for all, but XLD is only applicable if a different co= mpiler is used for ports than kernel and the base. When LD is set, XLD onl= y applies when it is set as well, but this suggests that XLD is not workin= g correctly either. > > > > I have to manually link /usr/bin/ld to /usr/local/bin/ld.lld80 for por= ts 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 manu= ally link it. Otherwise, LD in make.conf is not working correctly, and giv= es the impression that one linker is used, when it's not. This can cause f= aulty conclusions and confusion for developers as well, who think one link= er is set, when it's not.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?trinity-f7249ad8-8384-426d-8015-21a67f243ab5-1567622104520>