Change:
This blocks nixpkgs-unstable from advancing. cc
here. The relevant section seems to be: configure:4176: result: clang configure:4405: checking for C compiler version configure:4414: clang --version &5 clang version 7.1.0 (tags/RELEASE710/final) Target: x8664-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/RELEASE710/final) Target: x8664-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
This traces back to the gcc9 update.
addressed in
gnustep-base still doesn't build for me on master (seems like it's using clang?)
Ugh looks like it just worked on my machine.
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.
indeed tries to use clang: I don't really understand why, but if it's not really easily fixable, it probably shouldn't block channel advancement.
It blocks the nixpkgs channel through :
do you remember why you unar as a blocking job in ?
has always tried to use , and before the GCC upgrade it succeeded. This is I believe correct, and indeed it fails to build with GCC.
Yeah this broke with the gcc9 update. It uses clang but that's not the main problem, eg. which also uses the clangStdenv works fine. Yeah, my question was why should unar block the channel.
I think I found something: the error occurs because doesn't load the correct version of . The following error message is actually from the dynamic linker () trying to load the static linker (): I used to trace what the linker did to find the symbol, and found out that doesn't have xmemdup, but has. loads the one from the package because of LDLIBRARY_PATH taking precedence over rpath. do you think this analysis is correct? do you have a fix in mind?
So, no demand to return to the channel-blocking set?
It's probably okay to leave off, although I don't think it would hurt either way.

Discussion:
, cups , fetchurl , gmp, gnutls <del> , libffi, libbfd </del> <ins> , libffi, binutils-unwrapped </ins> , libjpeg, libtiff, libpng, giflib, libungif , libxml2, libxslt, libiconv , libobjc, libgcrypt

aspell audiofile cups gmp gnutls <del> libffi libbfd </del> <ins> libffi binutils-unwrapped </ins> libjpeg libtiff libpng giflib libungif libxml2 libxslt libiconv libobjc libgcrypt

]; patches = [ ./fixup-paths.patch ]; <del> # Bump to gcc9 has give missing xmemdup symbols. Need libiberty here # to resolve it, unclear why. See #76927 for more info NIX_LDFLAGS = "-liberty"; </del> meta = { description = "An implementation of AppKit and Foundation libraries of OPENSTEP and Cocoa"; };