Don't strip paths from libc.so ldscript

[emaste]

Summary

lld does not have built-in search paths (e.g. /lib, /usr/lib) and relies on -L arguments passed by the caller. As the linker is nearly always invoked from the clang driver this is fine other than the fact that /usr/lib/libc.so is an ldscript that refers to libc.so.7 which is in /lib, not /usr/lib.

Address this by leaving the paths in the GROUP entry rather than stripping them out. The paths were originally stripped due to a lack of --sysroot support in ld, fixed by @bdrewery in rS291226.

PR 207980

[emaste]

Aside, default search paths (/lib and /usr/lib) were added to lld in http://reviews.llvm.org/rL262910 and reverted in http://reviews.llvm.org/rL262941

[bdrewery]

This does break the DIRDEPS_BUILD:

/usr/bin/ld: cannot find /usr/obj/root/git/freebsd/stage/amd64.amd64/lib/libc.so.7 inside /usr/obj/root/git/freebsd/stage/amd64.amd64

# cat OBJ/stage/amd64.amd64/usr/lib/libc.so
/* $FreeBSD$ */
GROUP ( /usr/obj/root/git/freebsd/stage/amd64.amd64/lib/libc.so.7 /usr/obj/root/git/freebsd/stage/amd64.amd64/usr/lib/libc_nonshared.a /usr/obj/root/git/freebsd/stage/amd64.amd64/usr/lib/libssp_nonshared.a )

So the problem is that the path is getting the DESTDIR into it with this change.

[bdrewery]

You can test this with the following, which builds libc and then tries to link it in an early consumer:

WITH_DIRDEPS_BUILD=yes make -C gnu/lib/libgcc -j10

[bdrewery]

This is normally hacked around in buildworld/installworld (for lib32 which also sets an objdir for the _LDSCRIPTROOT) because installworld will generate a new file to install without the bad paths in it. I'm testing removing _LDSCRIPTROOT but the comments in bsd.lib.mk make me think I am missing something about the --sysroot usage in build32. I'll see once my build gets there.

[bdrewery]

As the comment notes, the --sysroot is actually the 64bit WORLDTMP while only -L points to the 32bit /usr/lib32. Nothing can link for lib32 libs using the ldscript (without _LDSCRIPTROOT or --sysroot) since it wants to read the hosts's /usr/lib32. I had to move my /usr/lib32 to notice that. The _LDSCRIPTROOT solution jlh added ensures the 32bit libc is used for linking.

As noted, the file build for lib32 has the objdir in it while the file installed does not.

So the problem with DIRDEPS_BUILD is that building essentially is installing. The staging directory is intended to be the final product to install. Via package or some other means. Same as for ports, we shouldn't have file content changed in stagedir vs the installed file.

The problem really only exists for the lib32 build since it doesn't use a proper --sysroot. I believe that removing DIRDEPS_BUILD use of _LDSCRIPTROOT would work fine since --sysroot is used, but it then restricts DIRDEPS_BUILD to never being able to build lib32 in the same way buildworld does.

[emaste]

As noted, the file build for lib32 has the objdir in it while the file installed does not.

This wasn't intentional - I have been excluding the lib32 build because it doesn't work with lld at the moment anyway. I haven't yet figured out what I think /usr/lib32/libc.so ought to contain.

[bdrewery]

This change isn't enough. Something else was broken in the meta mode change here.

(Not using DIRDEPS, purely buildworld/installworld):

~/git/freebsd # less /tmp/blah/usr/lib32/libc.so
/* $FreeBSD$ */
GROUP ( /usr/obj/root/git/freebsd/lib32/usr/lib32/libc.so.7 /usr/obj/root/git/freebsd/lib32/usr/lib32/libc_nonshared.a /usr/obj/root/git/freebsd/lib32/usr/lib32/libssp_nonshared.a )

[bdrewery]

This https://people.freebsd.org/~bdrewery/patches/ldscript.paths.patch fixes it to rebuild it on installworld as it originally did.