<LnL>
I update CF to 10.10 when those sources where released, but that was quite a while ago
<LnL>
updated*
<peel[m]>
ah, I wasn't following the progress. guess that xcode 8 toolchain is present then. will try to get that working.
<LnL>
when did you write that initial expression
<LnL>
I can't remember
<peel[m]>
hmm, somewhere around may last year
<LnL>
yeah, looking at the nix-darwin pr I'm pretty sure that's after the 10.10 stuff
<peel[m]>
I'd gladly fix that so people can just grab it from nixpkgs. though substituteInPlace with local clang and LDFLAGS with local libraries is way too ugly
<LnL>
yeah, perhaps you could open an issue requesting 10.10 support
<peel[m]>
the weirdest thing is that it would successfully compile with both local and nix clang with BUILD_FLAGS=-std=c99 -O3 though nix clang compiled one would crash on me with 'Abort trap: 6'. clang/llvm is terra incognita for me but looks like some optimisations on nix clang make it go bananas
<LnL>
what about without -O
<peel[m]>
the same exception
<LnL>
can you gist the output with DYLD_PRINT_RPATHS=1 DYLD_PRINT_LIBRARIES=1
<peel[m]>
ah, I guess that was an issue on the application side. updated to newer rev fixed that. it still fails on runtime with nix clang though.
<peel[m]>
but builds fine. just throws the Abort trap: 6 before blowing up. My clang fu is crap at this point.
<LnL>
I'm wondering if it's linked in a weird way, if it tries to use both the pure CF and the system CoreFoundation framework you can get segfaults for example
<LnL>
starting it with those DYLD_* variables should indicate if that's the case
<LnL>
starting with DYLD_FRAMEWORKS_PATH=/System/Library/Frameworks would fix the segfault if that's the case
<peel[m]>
Looks like it crashes due to stack overflow
<peel[m]>
does that indicate global impure libraries being used?
<LnL>
hmm, only our libsystem wrapper
<Biappi>
is there a way to get nix on osx, using the base libraries of the system, i.e. treating the os as a "pure base"? i thought there was a discussion like this in the past, but i don't remember the outcome
<LnL>
what libraries are you thinking of
philr has quit [Quit: WeeChat 2.0.1]
<angerman>
nix-drawin is pretty good these days.
<Biappi>
LnL: libsystem for once
<Biappi>
LnL: i mean, i've noticed that when i install stuff from nix, there are quite some libs fetcehd from opensource.apple.com and recompiled
<Biappi>
i would like to avoid that, and use the os
<LnL>
libSystem isn't available on opensource.apple.com
<Biappi>
yeah, you mentioned a wrapper for it
<peel[m]>
LnL: btw, the nix-build installer for nix-darwin is a fantastic idea!
<LnL>
it's not my idea :)
<LnL>
Biappi: I'm still not sure what you're looking for, the reexport wrapper doesn't matter unless you get errors about missing libc symbols
<Biappi>
i want to be sure that any software nix compiles will get linked with the base os libs, and not nix checkouts of those (but my assumption that nix-darwin actually gets libraries from opensource.apple.com and recompiles them might be wrong)
<angerman>
Biappi: I think I've seen nix try to compile and link against those libs. But that only happend when the host wasn't darwin, I think.
<LnL>
well yes, but those are pure and completely unrelated to whatever impure versions might be installed by the system
<Biappi>
but isn't the base os "pure"? it's got a build version number, and it's signed by the manufacturer, so a released version will always be that one
<LnL>
no, minor updates will change those
<LnL>
there's no reason to handle those in a special way, it work the same way as other dependencies that are not available by default
<Biappi>
well, my point in treating those differently is because they're not dependencies, that's the deployment target, but this is discussing the sex of the angels, if nix doesn't make the distinction, it doesn't
<dtz>
could someone do a quick build test for gnujump? haha https://github.com/NixOS/nixpkgs/pull/35494#issuecomment-369933236 (if it builds and you feel compelled to try to run it that'd be swell but just building would be useful, not sure what happened w/the borg builder)
<LnL>
we've had issues SDL-config on hydra before
<LnL>
if it's back we should fix that or disable the build otherwise it blocks one of the macs for ~10h with every rebuild
<dtz>
oh what it actually hangs on SDL-config?? haha well good to know
<LnL>
dtz: //github.com/NixOS/nixpkgs/pull/31509
<dtz>
ah, t
<dtz>
*ty
manveru has quit [Read error: Connection reset by peer]
manveru has joined #nix-darwin
{`-`} has joined #nix-darwin
jtojnar has joined #nix-darwin
<disasm>
Biappi: that's by design, we don't treat the OS as pure. nix on darwin a little over a year ago or so used to link against base os libraries. It was a nightmare.
disasm has quit [Ping timeout: 256 seconds]
disasm has joined #nix-darwin
<johnw>
is anyone running a hydra to compare sandbox darwin builds to non-sandbox builds?
<LnL>
most likely not, build-remote doesn't work in combination with sandboxing on darwin
<johnw>
how do I enable it with nix-darwin?
<johnw>
I'd like to see how much breaks
<LnL>
nix.useSandbox
<johnw>
that seems straightforward enough
<LnL>
but you'll have to disable your distributed builds setup to use it
<johnw>
yeah, I stopped using that anyway
<johnw>
it was too annoying
<LnL>
howso?
<johnw>
nix-build -K had no effect
<johnw>
and C-c had no effect
<johnw>
in fact, it became supremely hard to actually get builds to stop
<LnL>
ah
<LnL>
shlevy's recent fixes might have improved ctrl-c, not sure
<shlevy>
C-c should be better now yeah
<LnL>
also with the build hook or just locally?
<johnw>
well, my entire darwin environment works with sandbox = true
<johnw>
that's a good sign
<johnw>
(or at laest, of the things that rebuilt)
peacememories has joined #nix-darwin
<LnL>
qtbase is the only thing I know of after all of the stuff we fixed during nixcon
<LnL>
but new impurities might have been introduced since
peacememories has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<johnw>
http-client-tls just failed for me, which causes pandoc to fail
<johnw>
want to try: nix-build '<darwin>' -A pkgs.haskellPackages.pandoc?
<johnw>
(or maybe it's just pkgs.pandoc)
peacememories has joined #nix-darwin
<johnw>
the error I get is:
<johnw>
ld: file not found: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
<johnw>
clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)
<LnL>
I don't see any frameworks in the expression
<LnL>
so it should be using the pure CF
peacememories has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<LnL>
peel[m]: skhd seems to work fine at first glance
<johnw>
LnL: other Haskell failures: hours, conduit-extra
sonarpulse has joined #nix-darwin
<johnw>
again, missing frameworks
<johnw>
so, "should be using the pure CF", why isn't it?
<LnL>
dunno :)
<johnw>
copumpkin: bat signal
<johnw>
lots of Emacs packages are dying with the identical framework error
<johnw>
>10 of them, all either the same ld failure, or this: dyld: Library not loaded: /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit