I've found two issues. First one being /opt library upgrades. i.e. !!! existing preserved libs: >>> package: app-text/acroread-8.1.2-r1 * - /opt/Acrobat7/Reader/intellinux/lib/libcrypto.so.0.9.6 * - /opt/Acrobat7/Reader/intellinux/lib/libssl.so.0.9.6 It's a binary only pkg and nothing is linked to it. /opt should probably be excluded from preserved-libs The second issue: >>> package: gnome-base/gnome-applets-2.22.0 * - /usr/lib64/libgweather.so.0 * - /usr/lib64/libgweather.so.0.0.0 The above files used to be owned by gnome-base/gnome-applets-2.20 but then gnome-applets-2.22 broke it out into it's own package called dev-libs/libgweather. The .so versions stayed the same, the library just migrated from 1 package to another. No matter how many times you emerge @preserved-libs, it won't get rid of that msg.
(In reply to comment #0) > !!! existing preserved libs: > >>> package: app-text/acroread-8.1.2-r1 > * - /opt/Acrobat7/Reader/intellinux/lib/libcrypto.so.0.9.6 > * - /opt/Acrobat7/Reader/intellinux/lib/libssl.so.0.9.6 > > It's a binary only pkg and nothing is linked to it. Post the output of 'emerge -ptv @preserved-rebuild'.
These libraries are installed by the acroread package. The 7.x series of the package installed openssl 0.9.6 while the 8.x series uses 0.9.7. The libraries are specifically provided as shared objects so that security upgrades are easy, rather then requiring a whole new package. There is NOTHING that links to these. In fact, NOTHING should link to libs in /opt other then the package itself.
Guess we should not preserve libs if a copy exists in one of the standard library dirs. Ignoring just /opt completely is wrong IMO as we want to ignore internal libraries, which may very well exist outside /opt and there might be "real" libs inside /opt (plus I really hate such special cases).
(In reply to comment #3) > we want to ignore internal libraries So you didn't fix Bug #205531 properly?
(In reply to comment #4) > (In reply to comment #3) > > we want to ignore internal libraries > > So you didn't fix Bug #205531 properly? That's the opposite issue.
The issue with internal libs should be fixed in SVN, still have to look into the gweather problem.
I'm wondering if the fix you made in r9728 isn't a guarantee that no lib is ever preserved at all. If you find lib in any of the library paths (almost any), you remove the lib from the candidate list. However, this is done prior to unmerging the old package, so the lib is always installed in the system, isn't it?
The commit actually breaks subversion/neon preserve libs stuff.
(In reply to comment #7) > I'm wondering if the fix you made in r9728 isn't a guarantee that no lib is > ever preserved at all. > > If you find lib in any of the library paths (almost any), you remove the lib > from the candidate list. However, this is done prior to unmerging the old > package, so the lib is always installed in the system, isn't it? It was fixed in r9862.
It wasn't fixed at all, but I managed to understand genone's thoughts on this issue, and he figured he had to take the thing back to the drawing board. That said, I recently bumped on some horrible "internal version dependencies" in ELF objects (other thing than soname and versions there), and I think this makes the entire scene for ELF systems even worse/harder.
does it still happen ? we are now at r33 ... if no, please close.
I just tried this on acroread, and it doesn't occur any more. I recall something was changed to here, so it may be very well this bug has been fixed.
This should be fixed in 2.2.0_alpha34 (among many other preserve-libs fixes, including bug 286714). Please re-open if you can still reproduce it.
I have a similar problem with google-talkplugin: !!! existing preserved libs: >>> package: media-libs/libpng-1.4.5 * - /usr/lib/libpng12.so.0 * used by /opt/google/talkplugin/libnpgtpo3dautoplugin.so (www-plugins/google-talkplugin-2.0.6.0) Use emerge @preserved-rebuild to rebuild packages using these libraries google-talkplugin is a binary package and has a hard dependency on libpng:1.2.
(In reply to comment #14) Thanks for confirming. I was thinking of the second issue when I closed this. (In reply to comment #0) > The second issue: > > >>> package: gnome-base/gnome-applets-2.22.0 > * - /usr/lib64/libgweather.so.0 > * - /usr/lib64/libgweather.so.0.0.0 > > The above files used to be owned by gnome-base/gnome-applets-2.20 but then > gnome-applets-2.22 broke it out into it's own package called > dev-libs/libgweather. The .so versions stayed the same, the library just > migrated from 1 package to another. No matter how many times you emerge > @preserved-libs, it won't get rid of that msg. Hopefully this second issue got fixed in 2.2.0_alpha34.
*** Bug 382921 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > I have a similar problem with google-talkplugin: > > !!! existing preserved libs: > >>> package: media-libs/libpng-1.4.5 > * - /usr/lib/libpng12.so.0 > * used by /opt/google/talkplugin/libnpgtpo3dautoplugin.so > (www-plugins/google-talkplugin-2.0.6.0) > Use emerge @preserved-rebuild to rebuild packages using these libraries > > google-talkplugin is a binary package and has a hard dependency on libpng:1.2. It's back: !!! existing preserved libs: >>> package: media-libs/libpng-1.5.5 * - /usr/lib/libpng12.so.0 * used by /opt/google/talkplugin/libnpgtpo3dautoplugin.so (www-plugins/google-talkplugin-2.5.6.0) >>> package: media-libs/libpng-1.2.46 * - /usr/lib/libpng12.so.0 * used by /opt/google/talkplugin/libnpgtpo3dautoplugin.so (www-plugins/google-talkplugin-2.5.6.0)
just for clarity, what do scanelf --needed /opt/google/talkplugin/libnpgtpo3dautoplugin.so scanelf --rpath /opt/google/talkplugin/libnpgtpo3dautoplugin.so return?
(In reply to comment #18) > just for clarity, what do > > scanelf --needed /opt/google/talkplugin/libnpgtpo3dautoplugin.so > scanelf --rpath /opt/google/talkplugin/libnpgtpo3dautoplugin.so > > return? $ scanelf --needed /opt/google/talkplugin/libnpgtpo3dautoplugin.so TYPE NEEDED FILE ET_DYN libGL.so.1,libpthread.so.0,libCgGL.so,libdl.so.2,librt.so.1,libXt.so.6,libCg.so,libX11.so.6,libcairo.so.2,libpng12.so.0,libgtk-x11-2.0.so.0,libgdk-x11-2.0.so.0,libm.so.6,libfreetype.so.6,libfontconfig.so.1,libgobject-2.0.so.0,libglib-2.0.so.0,libstdc++.so.6,libgcc_s.so.1,libc.so.6 /opt/google/talkplugin/libnpgtpo3dautoplugin.so $ scanelf --rpath /opt/google/talkplugin/libnpgtpo3dautoplugin.so TYPE RPATH FILE ET_DYN /opt/google/talkplugin/lib /opt/google/talkplugin/libnpgtpo3dautoplugin.so
It preserves libpng12.so because either it doesn't use the rpath information from the object that references it, or it doesn't use it correctly.
I think LinkageMapELF should follow the MachO approach from LinkageMapMachO to use absolute paths to the libraries, instead of relying on the search path. Because only libpng12.so is stored as needed entry, and not /opt/google/talkplugin/lib/libpng12.so, the system has a problem next time it reevaluates the "preserved-libs", simply because it doesn't have the rpath information from the original consumer any more (and has to rely on the general search path). Could do this in NEEDED.ELF.3 (to store the full resolved paths to the libs) and updates to the LinkageMapELF code (basically to match the LinkageMapMachO one).
(In reply to comment #21) > Because only libpng12.so is stored as needed entry, and not > /opt/google/talkplugin/lib/libpng12.so, the system has a problem next time it > reevaluates the "preserved-libs", simply because it doesn't have the rpath > information from the original consumer any more (and has to rely on the general > search path). Isn't the the "rpath information from the original consumer" stored in /var/db/pkg/www-plugins/google-talkplugin-2.5.6.0/NEEDED.ELF.2 though? Thought that LinkageMapELF would already account for that when calculating the consumers of libpng12.so. If it's not working for some reason, shouldn't the data from NEEDED.ELF.2 be sufficient to fix it?
Reading from your comment, I think it should indeed be the case to deduce it. I don't know what I was thinking. Still, I think it simplifies when the registry wouldn't recompute the object's path all the time (and it does wrongly, obvious from this bug).
(In reply to comment #23) > Still, I think it simplifies when the registry wouldn't recompute the object's > path all the time (and it does wrongly, obvious from this bug). Actually, I think it works correctly. My local install of www-plugins/google-talkplugin-2.5.6.0 provides the following files: /usr/share/doc/google-talkplugin-2.5.6.0/changelog.Debian.bz2 /usr/lib/nsbrowser/plugins/libnpgoogletalk.so /usr/lib/nsbrowser/plugins/libnpgtpo3dautoplugin.so /opt/google/talkplugin/GoogleTalkPlugin /opt/google/talkplugin/libnpgoogletalk.so /opt/google/talkplugin/libnpgtpo3dautoplugin.so So, the package actually doesn't install a libpng12.so.0 in the /opt/google/talkplugin/lib rpath that we're talking about. Therefore, the package has a missing dependency on media-libs/libpng:1.2 and having media-libs/libpng:1.2 installed is supposed to prevent the library preservation shown in comment #14. So, I think that the real cause of the problem shown in comment #14 is due to some interaction between media-libs/libpng-1.5.5 and media-libs/libpng-1.2.x ebuilds, which causes the libpng12.so.0 to be owned by media-libs/libpng-1.5.5 when it should really be owned by media-libs/libpng-1.2.x. Maybe it has something to do with the preserve_old_lib call in the libpng-1.5.5 ebuild...
(In reply to comment #24) > Maybe it has something to do with the preserve_old_lib call in the libpng-1.5.5 > ebuild... Well, that preserve_old_lib call is for libpng14.so.0, so apparently that's not the issue. So, it seems that the problem is instead related to this slotmove: $PORTDIR/profiles/updates/2Q-2010:slotmove <=media-libs/libpng-1.2.43 1.2 0 If the user has media-libs/libpng-1.2.x installed in SLOT 0, then it triggers preserve-libs when upgrading to newer media-libs/libpng-1.5.5 which is also in SLOT 0. So, we need to find out why that library is preserved, and why having media-libs/libpng:1.2 installed doesn't resolve it.
(In reply to comment #25) > (In reply to comment #24) > > Maybe it has something to do with the preserve_old_lib call in the libpng-1.5.5 > > ebuild... > Well, that preserve_old_lib call is for libpng14.so.0, so apparently that's not > the issue. So, it seems that the problem is instead related to this slotmove: > > $PORTDIR/profiles/updates/2Q-2010:slotmove <=media-libs/libpng-1.2.43 1.2 0 > > If the user has media-libs/libpng-1.2.x installed in SLOT 0, then it triggers > preserve-libs when upgrading to newer media-libs/libpng-1.5.5 which is also in > SLOT 0. So, we need to find out why that library is preserved, and why having > media-libs/libpng:1.2 installed doesn't resolve it. It must have something to do with slot move. On another machine everything is fine. google-talkplugin pulls in libpng:1.2 as deps and there is no existing preserved lib. In contrast, this machine hasn't been updated for 3 months and the problem came up after updating to libpng-1.5.
*** Bug 265372 has been marked as a duplicate of this bug. ***
*** Bug 493018 has been marked as a duplicate of this bug. ***
*** Bug 493848 has been marked as a duplicate of this bug. ***
So I think after reading through this we can confirm this is fixed correct Portage team?
There are binary packages that are shipped with bundled libs, reference a needed library and then at runtime they can decide to use the bundled lib or the system one. For example, vmware-workstation $ scanelf --needed /opt/vmware/lib/vmware/lib/libvmware-gksu.so/libvmware-gksu.so TYPE NEEDED FILE ET_DYN libgksu2.so.0,libutil.so.1,libc.so.6 /opt/vmware/lib/vmware/lib/libvmware-gksu.so/libvmware-gksu.so $ scanelf --rpath /opt/vmware/lib/vmware/lib/libvmware-gksu.so/libvmware-gksu.so TYPE RPATH FILE ET_DYN - /opt/vmware/lib/vmware/lib/libvmware-gksu.so/libvmware-gksu.so The libgksu2.so.0 is usually bundled as /opt/vmware/lib/vmware/lib/libgksu2.so.0/libgksu2.so.0 and it's usually loaded before the system lib. When portage builds the list of libs related to the preserved-libs feature, it doesn't know about the bundled lib and for this reason it maps /opt/vmware/lib/vmware/lib/libvmware-gksu.so/libvmware-gksu.so with /usr/lib64/libgksu2.so.0 even if vmware effectively uses the bundled lib in /opt/vmware/lib/vmware/lib/libgksu2.so.0/libgksu2.so.0. This means that when x11-libs/libgksu was already installed in the system but not listed as dep for vmware-workstation, the preserved-libs mechanism in anyway triggered: !!! existing preserved libs: >>> package: x11-libs/libgksu-2.0.12-r2 * - /usr/lib64/libgksu2.so.0 * - /usr/lib64/libgksu2.so.0.0.2 * used by /opt/vmware/lib/vmware/lib/libvmware-gksu.so/libvmware-gksu.so (app-emulation/vmware-workstation-12.1.0.3272444-r1)
(In reply to Fabio Rossi from comment #31) > The libgksu2.so.0 is usually bundled as > /opt/vmware/lib/vmware/lib/libgksu2.so.0/libgksu2.so.0 and it's usually > loaded before the system lib. When portage builds the list of libs related > to the preserved-libs feature, it doesn't know about the bundled lib and for > this reason it maps > /opt/vmware/lib/vmware/lib/libvmware-gksu.so/libvmware-gksu.so with > /usr/lib64/libgksu2.so.0 even if vmware effectively uses the bundled lib in > /opt/vmware/lib/vmware/lib/libgksu2.so.0/libgksu2.so.0. The ebuild should use patchelf --set-rpath to properly configure library resolution. For example, see bug 265372, comment #16. This is the proper way to communicate the necessary information to both the linker and portage.
(In reply to Zac Medico from comment #32) > The ebuild should use patchelf --set-rpath to properly configure library > resolution. For example, see bug 265372, comment #16. This is the proper way > to communicate the necessary information to both the linker and portage. I'll try doing some experiments, the problem is that the bundled libs are not installed in a single folder but in a tree structure like this: /opt/vmware/lib/vmware/lib/ | +--- libsoname1.so.0/libsoname1.so.0 | +--- libsoname2.so.0/libsoname2.so.0 | \--- libsoname3.so.0/libsoname3.so.0 so a single call to patchelf --set-rpath should not work. I must see if vmware is using dlopen() at runtime, in that case probably --remove-needed is a better solution for bundled libs because they are not shared with other packages
(In reply to Fabio Rossi from comment #33) > (In reply to Zac Medico from comment #32) > > > The ebuild should use patchelf --set-rpath to properly configure library > > resolution. For example, see bug 265372, comment #16. This is the proper way > > to communicate the necessary information to both the linker and portage. > > I'll try doing some experiments, the problem is that the bundled libs are > not installed in a single folder but in a tree structure like this: > > /opt/vmware/lib/vmware/lib/ > | > +--- libsoname1.so.0/libsoname1.so.0 > | > +--- libsoname2.so.0/libsoname2.so.0 > | > \--- libsoname3.so.0/libsoname3.so.0 > > so a single call to patchelf --set-rpath should not work. You should be able to add multiple paths separated by colons. These paths can be relative to $ORIGIN, like $ORIGIN/libsoname1.so.0:$ORIGIN/libsoname2.so.0 and so on. > I must see if > vmware is using dlopen() at runtime, in that case probably --remove-needed > is a better solution for bundled libs because they are not shared with other > packages Yes, could be.
*** Bug 583208 has been marked as a duplicate of this bug. ***
