Wed, Jan 16
Updated following @ruiu 's comments - thank you!
Tue, Jan 15
Sun, Jan 13
Split target logic into D56650, switched to using target to determine which paths to apply. While at it, copied the code from clang since it now can match exactly.
Fri, Jan 11
Actually probably Linux MIPS used it and some proprietary OSes.. but we skip them for now. Only FreeBSD sets OSABI in lld and uses an emulation name detection hack. Once we will get merged TripleTarget detection we can switch it to use proper Triple check.
Right, I'm not aware of anyone but FreeBSD really using the OSABI field. For FreeBSD it was a long standing hack around limitations in the ELF kernel loader. I'm not even sure if FreeBSD use(d) to set the OSABI field for the intermediate object files.
@mgorny could you check if we can get crossbuilding functional for:
Implemented checking the triple against target registry. Also made --version output the detected target.
Thu, Jan 10
@joerg if you think that this patch is OK, please click accept so we can be aware that this is what you want.
I am pretty sure we can land this because having a patch on a review for about a year is always a terrible thing. My comments are inline.
Wed, Jan 9
Adjusted to make paths sysroot-relative.
Tue, Jan 8
I want to handle NetBSD in the same way as the other operating systems. I'm sorry to have been saying no to a few recent patches for NetBSD, but I think that's for a good reason, and I don't think you presented a convincing reason why we had to handle only NetBSD differently.
@ruiu: No, it is exactly what you want, since it allows you to point lld into the normal sysroot. Cross-compiling is the default case for the NetBSD toolchain.
To be honest, I don't think I would lgtm a patch that changes lld's default behavior depending on host/target only for NetBSD, and it seems like a NetBSD's issue rather than an lld's issue. As I said, could you please make an effort to pass the flags you need from the compiler driver to the linker just like other systems do? That is easy to do, doesn't hurt anyone, probably a good thing to do anyway as it makes options explicit rather than implicit, and solves at least most of the problems you have.
I'm sorry to say this but I don't think this is a good approach. Just like changing the default behavior depending on host hurts cross-build and is against the policy of the lld driver, changing the default behavior depending on the target hurts it too. Imagine that you are doing a cross-build on non-NetBSD system to create a NetBSD executable. You definitely want to ignore /usr/lib/i386 and /usr/lib on the host system. This patch does the opposite.
Thanks, this looks like a good starting point.
Next version, based on recognizing NetBSD from triple.
Mon, Jan 7
There is a list of 140-150 unsafe (LLD_UNSAFE) packages with LLD.
Sat, Jan 5
I've grepped FreeBSD, OpenBSD and pkgsrc.
Fri, Jan 4
Hi @ruiu ! This is waiting for your final review / approval. Could you possibly take a quick look please? Thank you!
Or if you really need to call the linker directly without specifying search paths you could also install a shell script as /usr/bin/ld that passes the appropriate flags to /usr/bin/ld.lld?
Thu, Jan 3
For the record, another option is to actually fix other software not to call LD directly.
Not sure what I understand the point, but as to make lld work on/for NetBSD, I wonder if you can just add -L<path> to the command line in the compiler driver. Isn't a NetBSD triple passed to the compiler driver? If so, I wonder if you can add a few extra options when invoking the linker.
Actually I think that we can handle two cases witch a combination of proposals:
- native mode
- cross mode