[04:03] <ScottK> Would some X smart person (i.e. not me) have a look at Bug 941826 and tell me what package gets the blame?
[04:25] <RAOF> That bug title promises much!
[04:27] <ScottK> I'm pretty convinced it's not PyQt's fault, but ICBW.
[04:28] <RAOF> Yeah, it's not PyQt's fault.
[04:29] <ScottK> Great. I can relax then.
[04:29]  * ScottK was not looking forward to convincing a somewhat grumpy upstream to care. 
[04:31] <ScottK> Would you please comment in the bug (if you didn't).
[04:31] <RAOF> Just wrangling the bug stati now.
[04:31] <ScottK> Thanks. 
[04:32] <RAOF> My, nvidia-331's postinst is pretty big!
[04:35] <RAOF> Hm. On first inspection, I don't see how that happens.
[04:44] <RAOF> Anyway; retitled, and invalidated the Qt* tasks. It'll be one of nvidia-331 or libgl1-mesa-dev's fault.
[07:34] <pwuertz> RAOF: I'd say the mesa package is to blame. The symlink /usr/lib/x86_64-linux-gnu/libGL.so shouldn't exist. It makes libGL.so always default to mesa instead of the choice made in /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf.
[07:35] <tjaalton> pwuertz: eh, of course it defaults to mesa since the package installs it
[07:35] <pwuertz> Since /usr/lib/x86_64-linux-gnu has precedence over anything else
[07:35] <tjaalton> if some other pkg wants something else, then it needs to provide the solution
[07:36] <pwuertz> tjaalton: the idea of the setup as i understand it is to have multiple libGL versions living peacefully next to each other, and you select the one you want to have as the default by linking the right /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf
[07:37] <tjaalton> well nvidia et al used to divert the files instead of relying on ldconfig priorities, and back then this wasn't a problem I guess
[07:37] <pwuertz> tjaalton: by just owning a symlink in the global lib directory you always claim to be the default libGL.so.. and there is nothing another package can do to prevent that
[07:37] <tjaalton> sure there is, divert the link
[07:38] <pwuertz> but it is owned by the package.. you cannot override it, can you?
[07:38] <tjaalton> but diversions come with other problems, which is why they got replaced by this
[07:38] <tjaalton> google dpkg diversion
[07:38] <tjaalton> man dpkg-divert
[07:38] <pwuertz> if 2 packages claim ownership over the same file the package management reports a conflict, doesnt it?
[07:38] <tjaalton> no
[07:38] <tjaalton> not if the other one diverts it
[07:40] <pwuertz> ok... lets put it in a different way.. there is already a mechanism in ubuntu to select the correct libGL instead of using the global lib directory.. why not just use that?
[07:40] <pwuertz> its a mistake
[07:40] <tjaalton> so what is it?
[07:40] <pwuertz> you don't see libGL.so.1 in the global lib directory, do you?
[07:41] <RAOF> We really should have a /usr/lib/libGL.so, too.
[07:41] <tjaalton> pwuertz: no, because that was moved under mesa exactly to cater the blobs
[07:42] <pwuertz> i don't know what "cater the blobs" means
[07:42] <tjaalton> hmm ok now I see, so .so should be moved too?
[07:42] <tjaalton> pwuertz: it's a diff to debian
[07:42] <tjaalton> we ship the libs under mesa/
[07:42] <RAOF> Well, I don't think we *can* move the .so
[07:42] <tjaalton> so that the ldconf dance works
[07:43] <tjaalton> RAOF: ah right
[07:43] <RAOF> Because you need the linker to be able to resolve it, and that doesn't care about ld.so
[07:43] <tjaalton> so there you go, diversions then?
[07:43] <RAOF> I guess so :/
[07:43] <RAOF> Actually...
[07:43] <RAOF> Alternatives!
[07:44] <RAOF> There's no reason /usr/lib/libGL.so can't be an alternative.
[07:44] <tjaalton> then there's multiarch :)
[07:45] <RAOF> Yeah, we'd obviously have /usr/lib/$arch_triple/libGL.so being an alternative.
[07:45] <RAOF> And I guess we can ignore the /usr/lib/libGL.so requirement of the Linux OpenGL ABI :)
[07:45] <pwuertz> Wouldn't the linker just pick anything ldconfig is configured for? Or are you saying that there are some occasions where the linker just looks for /usr/lib/libXY.so without asking anyone else?
[07:46] <RAOF> The linker doesn't use ldconfig
[07:47] <RAOF> The dynamic loader (ld.so) does, but the linker is totally separate.
[07:47] <RAOF> The linker just looks for lib$foo.so in a bunch of hardcoded paths.
[08:03] <pwuertz> RAOF: Oh, so the linker dynamically links against mesa/libGL.so, then when you call ldd on the binary or run it it switches to the one suggested by ldconfig
[08:03] <pwuertz> RAOF: I had no idea :)
[08:04] <RAOF> The linker just encodes "this DSO needs symbols from libGL.so.1" in the binary; it's ld.so's job to take “libGL.so.1” and load it.
[08:05] <RAOF> (As in: the binary literally contains the string “libGL.so.1”, and the dynamic loader takes that string and goes “is there a library called libGL.so.1 in my search paths”)
[08:05] <RAOF> ldd does the same sort of lookup as ld.so
[08:07] <pwuertz> RAOF: yea, but the linker also checks if these symbols exist, so if I'd (hypothetically) expect it to successfully link to some functions only present in an alternative libGL.so it wouldn't succeed
[08:08] <RAOF> No, that's the point of the OpenGL ABI; the set of symbols exported from Mesa's libGL.so is exactly the same as the set of symbols exported from NVIDIA's libGL.so.
[08:08] <pwuertz> thats why i said hypothetically ^^
[08:09] <RAOF> Well, and the linker actually only resolves symbols on first use, too.
[08:09] <RAOF> So if the program never uses a symbol from libbar.so.1 then it's never resolved, even if your particular libbar.so.1 doesn't actually have that symbol.
[08:09] <pwuertz> I see
[08:10] <pwuertz> Thanks for explaining! I really didn't know how exactly the linker did its job ;)
[08:11] <pwuertz> I.e. not involving ldconf
[08:14] <pwuertz> RAOF: Ok, i got another idea.. do you know who is responsible for creating /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf ?
[08:16] <pwuertz> RAOF: Because the problem is also solved by prioritizing that file with a "0" prefix in the filename, thus dynamically loading the nvidia/libGL
[08:16] <pwuertz> No other actions required