| 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:03 |
|---|---|---|
| ubottu | bug 941826 in python-qt4 (Ubuntu) "PyQt cannot compile shaders with Ubuntu's Nvidia drivers" [Undecided,Confirmed] https://launchpad.net/bugs/941826 | 04:03 |
| RAOF | That bug title promises much! | 04:25 |
| ScottK | I'm pretty convinced it's not PyQt's fault, but ICBW. | 04:27 |
| RAOF | Yeah, it's not PyQt's fault. | 04:28 |
| ScottK | Great. I can relax then. | 04:29 |
| * ScottK was not looking forward to convincing a somewhat grumpy upstream to care. | 04:29 | |
| 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:31 |
| RAOF | My, nvidia-331's postinst is pretty big! | 04:32 |
| RAOF | Hm. On first inspection, I don't see how that happens. | 04:35 |
| RAOF | Anyway; retitled, and invalidated the Qt* tasks. It'll be one of nvidia-331 or libgl1-mesa-dev's fault. | 04:44 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| RAOF | There's no reason /usr/lib/libGL.so can't be an alternative. | 07:44 |
| tjaalton | then there's multiarch :) | 07:44 |
| 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:45 |
| RAOF | The linker doesn't use ldconfig | 07:46 |
| 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. | 07:47 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:07 |
| 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:08 |
| 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:09 |
| pwuertz | Thanks for explaining! I really didn't know how exactly the linker did its job ;) | 08:10 |
| pwuertz | I.e. not involving ldconf | 08:11 |
| 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:14 |
| 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 | 08:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!