Nixpkgs: gnustep.base fails with undefined symbol: xmemdup

[tobim]

This blocks nixpkgs-unstable from advancing.
https://hydra.nixos.org/build/109464669/nixlog/1

checking for gcc... clang
checking whether the C compiler works... no
configure: error: in `/build/gnustep-base-1.26.0':
configure: error: C compiler cannot create executables
See `config.log' for more details
builder for '/nix/store/hm1p3p0jx93vqrx2rbws0h8yra73496x-gnustep-base-1.26.0.drv' failed with exit code 77

cc @ashalkhakov @matthewbauer

[xvello]

Dump of config.log here. The relevant section seems to be:

configure:4149: checking for gcc
configure:4176: result: clang
configure:4405: checking for C compiler version
configure:4414: clang --version >&5
clang version 7.1.0 (tags/RELEASE_710/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /nix/store/vh4m511m1w387via0xqzbqz09j2zi0pb-clang-7.1.0/bin
configure:4425: $? = 0
configure:4414: clang -v >&5
clang version 7.1.0 (tags/RELEASE_710/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /nix/store/vh4m511m1w387via0xqzbqz09j2zi0pb-clang-7.1.0/bin
configure:4425: $? = 0
configure:4414: clang -V >&5
clang-7: error: unsupported option '-V -B/nix/store/jpvkgxrx8jngi1lpqgs8p8ggk85g0wvk-clang-7.1.0-lib/lib'
clang-7: error: no input files
configure:4425: $? = 1
configure:4414: clang -qversion >&5
clang-7: error: unknown argument '-qversion', did you mean '--version'?
clang-7: error: no input files
configure:4425: $? = 1
configure:4445: checking whether the C compiler works
configure:4467: clang -I/nix/store/c7vm4sb539qnffqz3i78a7jdiass17d7-gnustep-make-2.7.0/local/include -I/nix/store/c7vm4sb539qnffqz3i78a7jdiass17d7-gnustep-make-2.7.0/local/include -I/nix/store/c7vm4sb539qnffqz3i78a7jdiass17d7-gnustep-make-2.7.0/include -L/nix/store/c7vm4sb539qnffqz3i78a7jdiass17d7-gnustep-make-2.7.0/local/lib -L/nix/store/c7vm4sb539qnffqz3i78a7jdiass17d7-gnustep-make-2.7.0/local/lib -L/nix/store/c7vm4sb539qnffqz3i78a7jdiass17d7-gnustep-make-2.7.0/lib conftest.c >&5
/nix/store/py44bcdf8lf70px3ma0j77h400abb4w9-binutils-2.31.1/bin/ld: symbol lookup error: /nix/store/py44bcdf8lf70px3ma0j77h400abb4w9-binutils-2.31.1/bin/ld: undefined symbol: xmemdup
clang-7: error: unable to execute command: No such file or directory
clang-7: error: linker command failed due to signal (use -v to see invocation)
configure:4471: $? = 255
configure:4509: result: no

[LnL7]

This traces back to the gcc9 update.

[matthewbauer]

addressed in https://github.com/NixOS/nixpkgs/pull/77336

[domenkozar]

gnustep-base still doesn't build for me on master (seems like it's using clang?)

[matthewbauer]

Ugh looks like it just worked on my machine.

[LnL7]

The nixos channels are still updating, what's the reason to block on this? According to the pr only 10 builds are impacted by it.

[flokli]

gnustep.base indeed tries to use clang:

configure:4149: checking for gcc
configure:4176: result: clang
configure:4405: checking for C compiler version
configure:4414: clang --version >&5
clang version 7.1.0 (tags/RELEASE_710/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /nix/store/50w29ymhbg9bj5xwwac4dcg0r2pjbyra-clang-7.1.0/bin
configure:4425: $? = 0
configure:4414: clang -v >&5
clang version 7.1.0 (tags/RELEASE_710/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /nix/store/50w29ymhbg9bj5xwwac4dcg0r2pjbyra-clang-7.1.0/bin
configure:4425: $? = 0
configure:4414: clang -V >&5
clang-7: error: unsupported option '-V -B/nix/store/hbws34yvfjqmawcc1g2q94gig0lh1vsw-clang-7.1.0-lib/lib'
clang-7: error: no input files
configure:4425: $? = 1
configure:4414: clang -qversion >&5
clang-7: error: unknown argument '-qversion', did you mean '--version'?
clang-7: error: no input files
configure:4425: $? = 1
configure:4445: checking whether the C compiler works
configure:4467: clang   -I/nix/store/d416yl3g81cfp4s40sgzy5i4vkqc2ikb-gnustep-make-2.7.0/local/include -I/nix/store/d416yl3g81cfp4s40sgzy5i4vkqc2ikb-gnustep-make-2.7.0/local/include -I/nix/store/d416yl3g81cfp4s40sgzy5i4vkqc2ikb-gnustep-make-2.7.0/include  -L/nix/store/d416yl3g81cfp4s40sgzy5i4vkqc2ikb-gnustep-make-2.7.0/local/lib -L/nix/store/d416yl3g81cfp4s40sgzy5i4vkqc2ikb-gnustep-make-2.7.0/local/lib -L/nix/store/d416yl3g81cfp4s40sgzy5i4vkqc2ikb-gnustep-make-2.7.0/lib conftest.c  >&5
/nix/store/5nxyf0yn836j0acm82cz3g50d4glk5df-binutils-2.31.1/bin/ld: symbol lookup error: /nix/store/5nxyf0yn836j0acm82cz3g50d4glk5df-binutils-2.31.1/bin/ld: undefined symbol: xmemdup
clang-7: error: unable to execute command: No such file or directory
clang-7: error: linker command failed due to signal (use -v to see invocation)
configure:4471: $? = 255
configure:4509: result: no

I don't really understand why, but if it's not really easily fixable, it probably shouldn't block channel advancement.

[vcunat]

It blocks the nixpkgs channel through unar: https://hydra.nixos.org/job/nixpkgs/trunk/unstable#tabs-constituents

[domenkozar]

@matthewbauer do you remember why you added unar as a blocking job in dc34d82a28bdc955142143fde8285241047a03e8?

[Taneb]

gnustep.base has always tried to use clang, and before the GCC upgrade it succeeded. This is I believe correct, and indeed it fails to build with GCC.

[LnL7]

Yeah this broke with the gcc9 update. It uses clang but that's not the main problem, eg. gnustep-make which also uses the clangStdenv works fine.

@vcunat Yeah, my question was why should unar block the channel.

[multun]

I think I found something: the error occurs because ld doesn't load the correct version of libbfd.
The following error message is actually from the dynamic linker (ld.so) trying to load the static linker (ld):

/nix/store/5nxyf0yn836j0acm82cz3g50d4glk5df-binutils-2.31.1/bin/ld: symbol lookup error: /nix/store/5nxyf0yn836j0acm82cz3g50d4glk5df-binutils-2.31.1/bin/ld: undefined symbol: xmemdup

I used LD_DEBUG=symbols to trace what the linker did to find the symbol, and found out that /nix/store/qdmq411j36459sfqjm691451pipzwv73-libbfd-2.31.1/lib/libbfd-2.31.1.so doesn't have xmemdup, but /nix/store/5nxyf0yn836j0acm82cz3g50d4glk5df-binutils-2.31.1/lib/libbfd-2.31.1.so has. ld loads the one from the libbfd package because of LD_LIBRARY_PATH taking precedence over rpath.

@orivej @edolstra @matthewbauer do you think this analysis is correct? do you have a fix in mind?

[vcunat]

So, no demand to return unar to the channel-blocking set?

[matthewbauer]

So, no demand to return unar to the channel-blocking set?

It's probably okay to leave off, although I don't think it would hurt either way.