<bgamari>
Sonarpulse, how do we deal with pkgconfig calls?
<bgamari>
it's not clear to me whether a particular pkg-config refers to the host or the build machine
<gchristensen>
bgamari: grep nixpkgs for pkgconfig and you'll find copious examples, I forget how it is called but IIRC Sonarpulse fixed all of them a month ago or so
<bgamari>
hmm
infinisil has quit [(Quit: ZNC 1.6.5 - http://znc.in)]
infinisil has joined joined #nixos-dev
<clever>
bgamari: also handy, "git log --patch" and then /pkgconfig, that will search the diffs, most recent to oldest
<bgamari>
I still feel like I'm missing something
<bgamari>
it's still very much unclear to me how we determine that a particular pkgconfig call is asking for libraries for the build or host environment
<bgamari>
it seems like fd9c7eb2e8c1755b606cb0d7dab2ba0bb93e36ed and nearby commits are relevant
<Sonarpulse>
bgamari: we might need prefixed pkg-config wrapper
<Sonarpulse>
just like binutils wrapper
<Sonarpulse>
the sort of dependency pkg-config is will affect things
<bgamari>
right
<Sonarpulse>
but that's not sufficient
<bgamari>
right
<bgamari>
I think I'm running into this now
<Sonarpulse>
because stil one PKGCONFIG_PATH or whatever its called
orivej has quit [(Ping timeout: 260 seconds)]
<bgamari>
Sonarpulse, indeed it seems that pkg-config is quite broken for packages in nixpkgs.buildPackages
<bgamari>
PKGCONFIG_PATH doesn't appear to be set at all
mbrgm has quit [(Ping timeout: 240 seconds)]
mbrgm has joined joined #nixos-dev
<Sonarpulse>
bgamari: you mean when building buildPackages.foo
<Sonarpulse>
PKGCONFIG_PATH isn't set
<Sonarpulse>
or if there is only nativeBuildInputs, it isn't set?
<gchristensen>
but are any/most builders still emitting "has invalid {permissions,mtime}" or are all of them resolved of this issue?
<vcunat>
They are still emitting it.
<gchristensen>
ok, then my ping for Eelco to fix it stands?
<vcunat>
Probably. I didn't dig too deep, so I expect it's only needed to purge those machines and re-deploy from newer images, but it's possible there's still some other bug in nixpkgs causing this.
<Sonarpulse>
domenkozar: about to head to work, but wanted to let you know I think I now have something reasonably isolated to fix for mingw
<domenkozar>
Sonarpulse: to get mingw to compile or to get ghc to compile with mingw?
<simpson>
catern: Just to double-check, your use case is that you have an app which links against libcurl, and you want that app to grow Kerb support, yes?
ma27 has quit [(Ping timeout: 255 seconds)]
Dezgeg has quit [(Ping timeout: 246 seconds)]
<catern>
simpson: yes, assuming by "you have an app" you mean "there is an app already in existence in nixpkgs"
<catern>
and there are multiple apps
<simpson>
Well, I'm just double-checking that I understand what you want to accomplish. These kinds of across-the-system package inclusions are kind of gnarly because it's not clear where to put the flag which controls them outside of NixOS.
<catern>
basically there are a lot of apps that link against libcurl which could support Kerberos
Dezgeg has joined joined #nixos-dev
<simpson>
Yeah, but which ones do you need specifically? Would there ever be a reason to build them without Kerb?
<catern>
ah, you've caught me, I can't name them exactly since I don't know - the main one is the command line utility curl itself, but really I don't know what exactly my users will want to use
<simpson>
Oh. Well, I wasn't really expecting this.
<catern>
did you have some solution in mind?
<simpson>
Well, if there's some applications that clearly always want Kerb support, then we should figure out how to default them to having it enabled.
<simpson>
I literally don't know anything about your situation other than what you've said here and in the PR, y'know?
<catern>
Ah, sure
<catern>
I mean, my contention is that libcurl should be compiled with Kerb by default
<catern>
That would just solve the problem for everything
<catern>
But since that would grow the closure a fair bit, have fetchurl use a special more-minimal curl
<simpson>
Huh, but doesn't that require blessing a specific Kerb and SSL library?
ma27 has joined joined #nixos-dev
<catern>
Well, sure, but variability is what Nix is all about :) we already use "kerberos" as a generic kerb library
<catern>
and users can override "kerberos" to get a different Kerb library everywhere
<LnL>
I think there's a significant amount of packages that depend on libcurl so enabling it by default probably also impacts rebuilds/closure size
<LnL>
but that might be fine, not sure
<catern>
Right
<simpson>
The rebuilds aren't a problem. Just stage the change until the next time we need to bump curl's version.
<gchristensen>
there is a glibc mass rebuild coming soon anyway
<LnL>
my point is that every kerberos update will cause large rebuilds
<gchristensen>
true
<simpson>
LnL: Oh, good point.
<LnL>
might already be the case, just somethig to be aware of
<domenkozar>
LnL: can you remind me what outputs cycle for happy on macOS?
globin has quit [(Ping timeout: 240 seconds)]
<domenkozar>
LnL: I don't see out<->bin cycle
<LnL>
bin is prropagated by out so binaries are available by default
<LnL>
but the binary has rpath references to out
<domenkozar>
ah it's propagated
<domenkozar>
how does that work on linux O_O
<LnL>
we generally use absolute paths to link against libraries, but then we run into the mach-o limit pretty quickly
<domenkozar>
we could just statically link executable
<LnL>
yeah, not sure linux also uses rpath for everything AFAIK
<domenkozar>
for alex and happy that makes a lot of sense
<domenkozar>
I'll try that if it helps
<LnL>
unless that's not not the case for haskell stuff
<sphalerite>
OTT! I've just tried digging up my soname stuff again, but I'm stumped as to why it doesn't actually work
<clever>
LnL: one thing i have thought about to deal with that mach-o limit, put a directory in the same output as the binary, that is filled with symlinks for the libs?
<Sonarpulse>
clever: we have a solution for the limit
<Sonarpulse>
I was wondering if you were still working on that
<sphalerite>
well not really, just picked it up again about 15min ago
<sphalerite>
I just don't get why this would cause `/nix/store/l1ylb8p30y651wjwhkpbp6k1p2bxw5l9-binutils-2.28.1/bin/ld: /build/build/./gcc/liblto_plugin.so: error loading plugin: /nix/store/lbn4a70npi2v5czhvbbxap8cl32j04jd-glibc-2.26-75/lib/libc-2.26.so: symbol __tunable_get_val, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference`
<sphalerite>
My best guess is a patchelf bug, but… I don't understand enough of this low-level stuff to really know
<LnL>
domenkozar: oh didn't notice that, then the links creation isn't correct with a bin output
<LnL>
clever: that's what we already do
<clever>
ah, nice
<LnL>
but the limit is pretty conservative so you can still hit it when you have a lot of dependencies
<Sonarpulse>
sphalerite: hmmm
<sphalerite>
Sonarpulse: I'm going to try building it without the exclusions (i.e. remove the -not -name ld*, and the noAbsoluteSoname from all the derivations) and compare some nm outputs at the points of failure
<Sonarpulse>
sphalerite: it is interesting this has something to do with the loader itself
<Sonarpulse>
ld-linux-x86-64.so.2
<sphalerite>
Rebuilding… bootstraps are fuuuuuuun…
<Sonarpulse>
would it need to be the vanilla soname?
<sphalerite>
I don't think the soname should affect runtime at all
<Sonarpulse>
sphalerite: I guess I don't quite know the rules for resolving -lasdf against /foo/bar/asdf
<Sonarpulse>
if it's fine, then great
<sphalerite>
AFAIU that just searches all the -L paths. soname doesn't come into play until after the library has already been found, and is just used to generate the DT_NEEDED entry
<sphalerite>
AFAIU. I might be completely wrong.
<Sonarpulse>
sphalerite: that seems reasonable
<sphalerite>
Sonarpulse: completely unrelated, it amuses me how similar your online alias is conceptually to my dad's (soundray) :D
<Sonarpulse>
oh, hah
<Sonarpulse>
mine is from red alert; i feel like "sound ray" could be from a sequel
<sphalerite>
on the topic of linking again, I also don't get why a shared library can't be used in the same way as a static library
<Sonarpulse>
sphalerite: what do you mean by that?
<Sonarpulse>
-lasdf will happy resolve to either
<sphalerite>
I mean why a shared library can't be linked statically
<Sonarpulse>
it doesn't have enough relocations
<sphalerite>
that is, rather than putting in a reference to the shared library file, copy all the relevant code into the resulting binary
<Sonarpulse>
i mean one can sort of do it
<Sonarpulse>
I guess I sort of have done that
orivej_ has joined joined #nixos-dev
ciil_ has joined joined #nixos-dev
fgaz_ has joined joined #nixos-dev
<sphalerite>
aaaaaaaaaargh. I had a condition the wrong way round, now I have to start the whole bootstrap all over again :'(
<Sonarpulse>
sphalerite: :( you can try to hack in setup hook for just one drv though