| Summary: | Linking is braindamage, apps break on upgrade | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | John Richard Moser <nigelenki> |
| Component: | Current packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | major | CC: | avenj, mr_bones_ |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
We can't patch every Makefile in Portage to link elsewhere. I realize that. Notice the last paragraph/sentence of the commnent. It's just frustrating is all. You could TRY to patch major ones once in a while (especially wget) that can potentially waste the core system, and ask the developers to please take the patches. If Python or wget goes out from underneath you, you need to mess with a rescue package for portage. If bzip2 or tar goes (that probably wouldn't happen. . .) you're screwed. But yes, you are right. It's too much work to fix other peoples' stuff constantly, and it's not really your responsibility. Why don't you submit some patches instead of just telling us about it? Technical question here. Most of this stuff is linked by `gcc -lfoo -lbar -lbaz biz.o qux.o qax.o -o foobar`, right? Would that make this a binutils issue, rather than a makefile issue? I could believe that ld would resolve symlinks one level, or something. If this is true, then it'd be a binutils problem, in which case I should figure out who the heck puts those out and go bug them. I'll leave this as resolved cantfix for now. I'm not taking up any coding project to resolve this. |
I don't know what genious came up with the set-up we have, but things work kind of like this in general: lrwxrwxrwx 1 root root 11 /usr/lib/libssl.so -> libssl.so.0 lrwxrwxrwx 1 root root 15 /usr/lib/libssl.so.0 -> libssl.so.0.9.7 -r-xr-xr-x 1 root root 193064 /usr/lib/libssl.so.0.9.7 Notice how libssl.so points at libssl.so.0, and libssl.so.0 points at the real library. Now, occasionally these things go up in version, i.e. upgrades/updates. In theory, the applications don't care, because of the symlinks to the real library. This is not a fact. Things break. For example, updating gnome and causing libgucharmap.so.3 to becom libgucharmap.so.4 breaks abiword until you relink abiword (by remerging it) Interestingly enough, libgucharmap.so.4 points at libgucharmap.so.4.0.3, so is a symlink itself. MORE interestingly. linking libgucharmap.so.4 to libgucharmap.so.3 fixes abiword without a recompile. A lot of applications are linked to some .so.* libraries, like this big one: bluefox@icebox bluefox $ ldd /usr/bin/gimp-2.0 libgimpwidgets-2.0.so.0 => /usr/lib/libgimpwidgets-2.0.so.0 (0x4002d000) libgimpmodule-2.0.so.0 => /usr/lib/libgimpmodule-2.0.so.0 (0x400f5000) libgimpcolor-2.0.so.0 => /usr/lib/libgimpcolor-2.0.so.0 (0x400fa000) libgimpthumb-2.0.so.0 => /usr/lib/libgimpthumb-2.0.so.0 (0x40102000) libgimpmath-2.0.so.0 => /usr/lib/libgimpmath-2.0.so.0 (0x40108000) libgimpbase-2.0.so.0 => /usr/lib/libgimpbase-2.0.so.0 (0x4010e000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x40119000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x403c1000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x40432000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x4044c000) libm.so.6 => /lib/libm.so.6 (0x40460000) libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x40482000) libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x40488000) libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0x40493000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x404aa000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x404d0000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x40505000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x4053c000) libdl.so.2 => /lib/libdl.so.2 (0x40541000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x40544000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x405be000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x405e7000) libz.so.1 => /lib/libz.so.1 (0x40658000) libc.so.6 => /lib/libc.so.6 (0x40669000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40796000) libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x4087a000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x4087e000) libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0x40887000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4088a000) libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x4089c000) libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x408b2000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x408bb000) You do realize that it would probably work to link to the .so, and that things wouldn't break on upgrades, right? Like wget, when libssl is updated. Admittedly, it appears some things endure upgrades. It may though be that the upgrades don't change the major/minor that is in the symlink, and thus doesn't disrupt the ld.so.cache and dl stuff. bluefox@icebox bluefox $ ldd /usr/bin/wget libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x4002d000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x4005c000) libdl.so.2 => /lib/libdl.so.2 (0x40160000) libc.so.6 => /lib/libc.so.6 (0x40163000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) THIS ONE doesn't have that luxury; it breaks as soon as some idiot updates libssl. This is probably more of a problem for either autoconf or the programmers.