I'm a bit confused by the comments, cc is the compiler and ld is the linker. Does the build pass compiler flags to LD?

For some reason the configure script by default chooses ld as the linker. I have had this issue in several other builds I am working on. This causes errors because the Makefile assumes that gcc or clang is used for the linker. Additionally gcc and clang pass the appropriate linking flags to include glibc pthreads etc. Is there a more elegant way to do this? cc is symlinked to either gcc or clang depending on the OS.

Yes that's very normal, gcc and clang are not linkers. Could you explain or post the error?

Here is the error if I do not manually set cc as the linker.

I am aware that gcc and clang are not linkers (they are wrappers around preprocessing, compiling, and linking). From what I know they can be used as linkers and call ld with appropriate arguments.

....
gcc -I.. -Wall -Wextra -std=c11 -pedantic -O2 -g -fPIC -c seq.c -o .objs/seq.o
gcc -I.. -Wall -Wextra -std=c11 -pedantic -O2 -g -fPIC -c symtable.c -o .objs/symtable.o
gcc -I.. -Wall -Wextra -std=c11 -pedantic -O2 -g -fPIC -c util.c -o .objs/util.o
gcc -I.. -Wall -Wextra -std=c11 -pedantic -O2 -g -fPIC -c values.c -o .objs/values.o
ld -shared -Wl,-soname,libndtypes.so.0 -o libndtypes.so.0.2.0dev3 .objs/alloc.o .objs/attr.o .objs/context.o .objs/copy.o .objs/encodings.o .objs/equal.o .objs/grammar.o .objs/io.o .objs/lexer.o .objs/match.o .objs/ndtypes.o .objs/parsefuncs.o .objs/parser.o .objs/seq.o .objs/symtable.o .objs/util.o .objs/values.o compat/.objs/bpgrammar.o compat/.objs/bplexer.o compat/.objs/import.o
/nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/ld: unrecognized option '-Wl,-soname,libndtypes.so.0'
/nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/ld: use the --help option for usage information
make[1]: *** [Makefile:57: libndtypes.so.0.2.0dev3] Error 1
make[1]: Leaving directory '/build/source/libndtypes'
make: *** [Makefile:23: default] Error 2
builder for '/nix/store/5gplhcy8rxmiabvw43agnwpkflrvz29l-libndtypes-0.2.0dev3.drv' failed with exit code 2
error: build of '/nix/store/5gplhcy8rxmiabvw43agnwpkflrvz29l-libndtypes-0.2.0dev3.drv' failed

'-Wl,-soname,libndtypes.so.0' is a argument that is passed to gcc or clang that is appropriately passed to ld. If I am understanding anything wrong please let me know. Or if it could be done in a nicer way.

Ah I see, the build is passing compiler specific flags to ld like I thought. -Wl is a compiler flag to specify extra flags to pass to the linker. Could you rephrase the comment to avoid confusion.

That should be, so using LD=cc basically turns the incorrect usage into the first variant.

$CC -Wl,-soname,libndtypes.so.0 ...
# or
$LD -soname libndtypes.so.0 ...

Might be worth creating an upstream issue.

Ok I have updated the pull request with a better comment for why cc was used as a linker. Its ready to merge.

I still am not convinced this is incorrect usage. While in this case using ld would have been simple enough. For some complex libraries this is not always the case. Take for example mpicc, mpif90 these are wrappers around gcc with linker and special compilation flags. So similarly using gcc for linking simplifies the process by not having to worry about the location of glibc, lm, ld-linux-x86-64.so.2, etc. Using -Wl,--verbose you can print all of the work done by gcc for linking.

Here are the linking flags used by mpicc -showme:linker

mpicc -showme:linker

gcc -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include -I/usr/lib/x86_64-linux-gnu/openmpi/include -pthread -L/usr//lib -L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi

I only have a vague understanding of this, somebody like @Ericson2314 can probably explain this better. But we explicitly set LD=ld in the stdenv which is probably what exposed the issue.

Yeah it is done for cross on other things to force configure scripts to use the right linker. But then some configure scripts are crazy and have defaults like LD ?= gcc for this. I've seen a CCLD environment variable instead, which is a much better way to use a C compiler for linking but also be independent ofCC. That is what upstream ought to use.

@Ericson2314 I have made the changes that you requested for cross compatibiliy.

Just to make sure that I understand correctly. Using a variable CCLD is useful because it indicates that you are using a compiler to determine the linker. Setting LD=gcc can be confusing and is not good style. Is that correct?

@costrouc I'd change "compiler to determine the linker" to "using a compiler to do the linking". The compiler will modify how you link things in subtle ways to pick up the C/C++ runtime things, etc.

Should be ready for a build now