Ticket #1157 (new defect)

Opened 6 years ago

Last modified 4 years ago

cave fix-linkage --library doesn't work with absolute paths

Reported by: cjm Owned by:
Priority: MinorRelease Milestone:
Component: clients/cave Version: 0.60.4
Keywords: Cc:
Blocked By: Blocking:
Distribution: Gentoo

Description

I upgraded sys-libs/readline on Gentoo. It warned me

*** Old versions of installed libraries were detected on your system.
*** In order to avoid breaking packages that depend on these old libs,
*** the libraries are not being removed. You need to run revdep-rebuild
*** in order to remove these old dependencies. If you do not have this
*** helper program, simply emerge the 'gentoolkit' package.
*** 
*** # revdep-rebuild --library '/lib/libhistory.so.5'
*** # revdep-rebuild --library '/lib/libreadline.so.5'

So I did:

# cave fix-linkage --library '/lib/libhistory.so.5' --library '/lib/libreadline.so.5'
Searching: 12 directories, 85127 files

No packages that depend on /lib/libhistory.so.5, /lib/libreadline.so.5 found

But I was suspicious, so I tried:

cave fix-linkage --library 'libhistory.so.5' --library 'libreadline.so.5'

That also searched 12 directories and 85127 files, but it found 7 packages that needed to be rebuilt because they were linked to the outdated libraries.

This is a big deal because Gentoo ebuilds print revdep-rebuild commands using absolute paths (as shown above). If you forget to remove the paths, then packages won't get rebuilt properly. Even if you remember to remove the paths, it's still a hassle to have to do it.

Perhaps fix-linkage should just strip paths from --library arguments? I'm not sure there's much use for them. At the very least, the manpage for fix-linkage needs a big warning message reminding people not to use absolute paths, but I think that's just asking for people to make mistakes.

Change History

comment:1 Changed 6 years ago by ciaranm

Don't have time to look at this properly for a few weeks... But in the mean time... What if you use /lib32 or /lib64 rather than /lib?

comment:2 Changed 6 years ago by cjm

That doesn't work either, and I don't know why it would, since I don't have /lib32 or /lib64 directories. /lib/libreadline.so.5 is the correct absolute path of the library.

comment:3 Changed 6 years ago by ciaranm

I've put in a warning for now. Apparently fixing this properly is going to be fiddly.

comment:4 follow-up: ↓ 5 Changed 6 years ago by eyoung100

Also happening with the dev-libs/icu update from 4.6 to 4.8. fix-linkage missed gettext and libxml2 which breaks all properly detected packages marked for rebuild by fix-linkage:

Fix-linkage reports 14 packages, one of which is paludis (xmlrepositotythingys iirc, which is linked to libxml2. libxml2 is linked to gettext, because gettext is compiled with nls and nls uses icu)

Revdep-rebuild reports the 14 that fix-linkage got plus the 2 it missed.

Steps to reproduce:

  1. Update dev-libs/icu to 4.8, which is now stable
  2. Run cave fix linkage, paludis starts printing elike warnings similar to (xmlrepositorythingys.so - cannot find link to libicu*.so.46, no such file or directory)
  3. Trying to compile paludis by hand results in Error 137 during the document creation phase because libxml cannot convert the documents due to a missing libicu*.so.46

Only fix as of now is to eselect package-manager set portage && . /etc/profile && revdep-rebuild

comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6 Changed 6 years ago by dleverton

Replying to eyoung100:

Also happening with the dev-libs/icu update from 4.6 to 4.8. fix-linkage missed gettext and libxml2 which breaks all properly detected packages marked for rebuild by fix-linkage:

Are you sure that's related? This ticket's for the --library option only working with the library filename (more precisely SONAME), for when you want to force it to rebuild packages linked to a particular library rather than whichever libraries happen to be missing.

I also don't see anything obviously unusual about how getext and libxml2 link to ICU - can you provide --log-level debug output (probably on a new ticket), or have you already done the rebuild?

comment:6 in reply to: ↑ 5 Changed 6 years ago by eyoung100

Replying to dleverton:

Replying to eyoung100:

Also happening with the dev-libs/icu update from 4.6 to 4.8. fix-linkage missed gettext and libxml2 which breaks all properly detected packages marked for rebuild by fix-linkage:

Are you sure that's related? This ticket's for the --library option only working with the library filename (more precisely SONAME), for when you want to force it to rebuild packages linked to a particular library rather than whichever libraries happen to be missing.

I also don't see anything obviously unusual about how getext and libxml2 link to ICU - can you provide --log-level debug output (probably on a new ticket), or have you already done the rebuild?

I already did the rebuild, but I can recreate the scenario by masking >=dev-libs/icu-4.8 then rebuilding 4.6 and do it all over again i never clear out my log directory tho so i can add a log, of the failed build...

Google for the gentoo xpat update bug, specifically this post:  http://forums.gentoo.org/viewtopic-t-575655.html

Same type of behaviour, except different library...

Last edited 6 years ago by eyoung100 (previous) (diff)

comment:7 follow-up: ↓ 8 Changed 4 years ago by ff2000

Had this issue yesterday. With /usr/lib64/libmpc.so.2 and /lib64/libudev.so.0. cave fix-linkage --library did NOT find any broken package so I removed those libraries. Of course both were used -> I now had a broken compiler... But I was lucky - another compatible machine still had libmpc.so.2 around. Copied it over and cc was fine, again.

Would be really nice if paludis would not break my system when used as suggested in ebuilds (keep compatibility with default package manager).

comment:8 in reply to: ↑ 7 Changed 4 years ago by dleverton

Replying to ff2000:

Had this issue yesterday. With /usr/lib64/libmpc.so.2 and /lib64/libudev.so.0. cave fix-linkage --library did NOT find any broken package so I removed those libraries. Of course both were used -> I now had a broken compiler... But I was lucky - another compatible machine still had libmpc.so.2 around. Copied it over and cc was fine, again.

Would be really nice if paludis would not break my system when used as suggested in ebuilds (keep compatibility with default package manager).

That's unfortunate. :-( I thought we had a workaround, but it only prints a warning if you give a full path, which could be missed. I extended it in d69251ac so it should be able to handle this a bit better.

Note: See TracTickets for help on using tickets.