Problem using linker options -L=-nostdlib and friends

[JinShil]

Consider the following:

module test;

extern(C) void _d_dso_registry(void* data)
{ }

extern(C) void _d_run_main()
{ }

extern(C) void _start()
{ }

void main(string[] args)
{ }  

Compiling with ldc2 test.d -defaultlib= -L=-nostdlib -L=-nodefaultlibs -L=-nostartfiles -v shows the command to the linker...

/usr/bin/gcc test.o -o test -L/usr/lib -L/usr/lib32 -Xlinker --no-warn-search-mismatch -Xlinker -nostdlib -Xlinker -nodefaultlibs -Xlinker -nostartfiles -lrt -Wl,--gc-sections -ldl -lpthread -lm -m64 

... and the output below indicates that it is still linking to the default libs and the start files when it shouldn't.

test.o: In function `_start':
test.d:(.text._start+0x0): multiple definition of `_start'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib/crt1.o:(.text+0x0): first defined here
/usr/bin/ld: cannot find -lrt
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1

This appears to be because gcc is used for the linker, but the linker options are further forwarded to ld with the -Xlinker option instead of being passed directly to gcc. So, either the options specified by -L={option} should be gcc options, or ld should be used for the linker.

Furthermore, I'd expect -defaultlib= to prevent the compiler from passing -lrt -ldl -lpthread -lm to the linker, but that depends on how -defaultlib= is defined.

Compiling with ldc2 -c test.d and linking manually with gcc -nodefaultlibs -nostdlib -nostartfiles test.o produces the correct result. And, of course, manually linking with ld test.o also produces the correct result.

Documentation on these options can be found here: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

Testing on Arch Linux 64 with LDC 0.14.0 (DMD v2.065, LLVM 3.4.2)

[JinShil]

This appears to already be an issue logged for DMD: https://issues.dlang.org/show_bug.cgi?id=6952
I'm not sure if fixing it in DMD would automatically mean a fix of LDC.

[JinShil]

I think the proper solution is to have DMD use ld as the linker, and that needs to be done first. I don't have the resources to implement and test that, so it probably won't happen.

If LDC is striving for compatibility with DMD, then this is a DMD issue, not an LDC issue. Closing.

[dnadlinger]

I think the proper solution is to have DMD use ld as the linker

I don't think so. We don't want to duplicate the logic for linking against the C standard library, as it would turn into a very platform-dependent mess – at least I think it would, didn't actually try to implement it so far.

[JinShil]

We don't want to duplicate the logic for linking against the C standard library, as it would turn into a very platform-dependent mess – at least I think it would, didn't actually try to implement it so far.

It would require DMD to become more knowledgeable of the underlying platform, and it would certainly make the command line in dmd.conf longer, but I don't think that qualifies as a "mess". I find the dependency natural for a native compiler. I think using gcc as the linker is a bit of a cheat.

I'm curious, though... if LDC is the LLVM D compiler, do you plan on using lld when it reaches maturity? Or, if you believe leveraging the underlying C compiler is the right approach, why not use clang instead of gcc?