[04:03] Would some X smart person (i.e. not me) have a look at Bug 941826 and tell me what package gets the blame? [04:03] bug 941826 in python-qt4 (Ubuntu) "PyQt cannot compile shaders with Ubuntu's Nvidia drivers" [Undecided,Confirmed] https://launchpad.net/bugs/941826 [04:25] That bug title promises much! [04:27] I'm pretty convinced it's not PyQt's fault, but ICBW. [04:28] Yeah, it's not PyQt's fault. [04:29] Great. I can relax then. [04:29] * ScottK was not looking forward to convincing a somewhat grumpy upstream to care. [04:31] Would you please comment in the bug (if you didn't). [04:31] Just wrangling the bug stati now. [04:31] Thanks. [04:32] My, nvidia-331's postinst is pretty big! [04:35] Hm. On first inspection, I don't see how that happens. [04:44] Anyway; retitled, and invalidated the Qt* tasks. It'll be one of nvidia-331 or libgl1-mesa-dev's fault. [07:34] 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] pwuertz: eh, of course it defaults to mesa since the package installs it [07:35] Since /usr/lib/x86_64-linux-gnu has precedence over anything else [07:35] if some other pkg wants something else, then it needs to provide the solution [07:36] 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] 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] 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] sure there is, divert the link [07:38] but it is owned by the package.. you cannot override it, can you? [07:38] but diversions come with other problems, which is why they got replaced by this [07:38] google dpkg diversion [07:38] man dpkg-divert [07:38] if 2 packages claim ownership over the same file the package management reports a conflict, doesnt it? [07:38] no [07:38] not if the other one diverts it [07:40] 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] its a mistake [07:40] so what is it? [07:40] you don't see libGL.so.1 in the global lib directory, do you? [07:41] We really should have a /usr/lib/libGL.so, too. [07:41] pwuertz: no, because that was moved under mesa exactly to cater the blobs [07:42] i don't know what "cater the blobs" means [07:42] hmm ok now I see, so .so should be moved too? [07:42] pwuertz: it's a diff to debian [07:42] we ship the libs under mesa/ [07:42] Well, I don't think we *can* move the .so [07:42] so that the ldconf dance works [07:43] RAOF: ah right [07:43] Because you need the linker to be able to resolve it, and that doesn't care about ld.so [07:43] so there you go, diversions then? [07:43] I guess so :/ [07:43] Actually... [07:43] Alternatives! [07:44] There's no reason /usr/lib/libGL.so can't be an alternative. [07:44] then there's multiarch :) [07:45] Yeah, we'd obviously have /usr/lib/$arch_triple/libGL.so being an alternative. [07:45] And I guess we can ignore the /usr/lib/libGL.so requirement of the Linux OpenGL ABI :) [07:45] 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] The linker doesn't use ldconfig [07:47] The dynamic loader (ld.so) does, but the linker is totally separate. [07:47] The linker just looks for lib$foo.so in a bunch of hardcoded paths. [08:03] 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] RAOF: I had no idea :) [08:04] 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] (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] ldd does the same sort of lookup as ld.so [08:07] 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] 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] thats why i said hypothetically ^^ [08:09] Well, and the linker actually only resolves symbols on first use, too. [08:09] 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] I see [08:10] Thanks for explaining! I really didn't know how exactly the linker did its job ;) [08:11] I.e. not involving ldconf [08:14] 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] 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] No other actions required