Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<anttih_>
I'm trying to link against Foundation and AppKit frameworks but I'm getting an error. I have a nix-shell open where they both have been added and then I run a cabal build in there. I can see that they are used in the ghc command that cabal generates so I think at least cabal is configured correctly. The error I get is: `Undefined symbols for architecture x86_64: "_NSDefaultRunLoopMode", referenced from`.
<anttih_>
NSDefaultRunLoopMode is defined in Foundation so I think that is all that should be needed. Do you have any tips on how to debug this?
<anttih_>
This is only failing in the link phase, so the headers are found which tells me that I have the correct libraries available.
<anttih_>
I should add that I can successfully link when using `clang` directly instead of `cabal`.
<LnL>
what nixpkgs version is this?
<LnL>
this used to be a problem with our pure vs impure CoreFoundation but with #63381 all of those weird cases should pretty much be gone
<anttih_>
just yesterday updated to latest Nixpkgs-unstable
<anttih_>
hmm, seems that ghc/cabal is not adding all the libraries for the linker, that's the -F flag.
<anttih_>
so not sure this is a nix thing or not
<anttih_>
so running `clang` adds a whole bunch of libraries using -F but cabal does not.
<LnL>
cabal still runs clang/ld under the hood so that shouldn't matter
<LnL>
unless it's calling something else
<anttih_>
sure but it's not setting the flags
<LnL>
can you trace the commands?
<LnL>
it could be cabal is using the system or unwrapped ld somehow
<anttih_>
ah never mind you are correct, it's calling `ld` under the hood with the correct flags
<anttih_>
what on earth is going on here :(
<LnL>
but is it the same as the build environement?
<anttih_>
not sure how I can check that
<anttih_>
it's a huge command
<LnL>
we have the plain binary and then a wrapper which makes it aware of nix dependencies
<LnL>
eg. /nix/store/60hjqrb8dn47jrffgcdzn85bz3bzbp24-clang-wrapper-7.1.0/bin/ld vs /nix/store/qdv6dm1j1z2gll95cacw5656hs3isb62-cctools-binutils-darwin/bin/ld
<LnL>
and ofcorse there's also /usr/bin/ld which definitively won't work
<anttih_>
linker is `/nix/store/a76n8l1caynyyngdpnyihlrgyr9k9ilg-clang-wrapper-7.1.0/bin/ld`
<LnL>
and what does builtins.trace lib.version (...) give if you add it in the expression?
<LnL>
or are you sure no IFD shenanigans is going on that might be using an older nixpkgs
<anttih_>
20.03pre201327.6b0843d7e15
<anttih_>
there should not be anything weird going on, I even have a pinned nixpkgs
<anttih_>
could I be picking up the system version of Nixpkgs somehow even though I use a pinned one for this expression?
<anttih_>
I guess in that case I have much bigger problems :D
<anttih_>
wait, I run nix-channel --update and then nix-shell with the pinned Nixpkgs and now it's installing a bunch of stuff :(
<anttih_>
the build still fails though
<LnL>
do you have an expression I could reproduce with?
<anttih_>
Not right now
<anttih_>
it's interesting that even when just running the `clang` command by itself I need to add `-framework CoreFoundation` else I get the exact same error as with ghc
<anttih_>
and that missing symbol is supposed to be in `Foundation` not `CoreFoundation`
<anttih_>
Running `clang` using the system libraries without nix I don't have to provide the -framework flag at all
<anttih_>
I checked and the failing and the working command both use the same paths to the framework directories inside nix store