After a rewrite the port for revdep-rebuild doesn't work for the prefixed portage. I put some notes together regarding what revdep-rebuild does and where the approach has to differ on some platforms and will attach patches for Darwin. I did that as a notepad for myself and because I felt a lack of documentation for the next time, revdep-rebuild get's rewritten (sorry for the messy website): http://www.miriup.de/index.php?option=com_content&view=section&layout=blog&id=2 Some other bugs touching the same issue, among them #244599 and #250612.
Created attachment 190527 [details, diff] Patch against gentoolkit-0.2.4.1-r00.1.ebuild Hunk 1 adds to new patches: - new-revdep-rebuild-prefix deals with @GENTOO_PORTAGE_EPREFIX@ for any system - new-revdep-rebuild-darwin adds modifications specific to Darwin Hunk 2 makes sure revdep-rebuild does not get deleted on Darwin.
Created attachment 190529 [details, diff] @GENTOO_PORTAGE_EPREFIX@ tags for filesystem locations ... I left /etc/ld.so.conf out on purpose.
Created attachment 190539 [details, diff] Patch with modifications specific to Darwin Hunk 1 figures out who is the root user early in the file. Hunk 2 checks which platform we're on and calls either the platform specific main_checks method or falls back on the default. Hunk 3 checks for the rootuser against the root ID from hunk 1 instead of 0 Hunk 4 changes from matching against 'root' to matching against the ID of the rootuser. Hunk 5 redirects the error message on Darwin, that /etc/ld.so.conf could not be found to /dev/null. ;) Hunk 6 contains the actual modification relevant to Darwin. First, the list of linked libs is determined through `otool -L`. The 'compatibility version' is taken into account. Then the location of each lib is checked whether it contains a library with the same compatibility version. On the web note I mentioned in the bug, there are two other checks mentioned that this patch does not implement: we do not take care of the presence of individual symbols and we also do not take care of two-level namespaces.
(In reply to comment #0) > http://www.miriup.de/index.php?option=com_content&view=section&layout=blog&id=2 http://www.miriup.de/index.php?option=com_content&view=article&id=15:porting-revdep-rebuild-to-gentoo-prefix&catid=2:gentoo-alt&Itemid=12 ... is the real link.
Created attachment 190673 [details, diff] @GENTOO_PORTAGE_EPREFIX@ tags for filesystem locations In file 190529 was a bug that prevented the properly collection of executable paths to search for. Here is the fix for it.
does this patch still apply on gentoolkit-0.2.4.4.ebuild?
By the way, we also have scanmacho these days that sometimes makes it easier to just pull a value out of a Mach-O object.
Created attachment 192270 [details, diff] Ebuild patch against 0.2.4.4 Sorry, didn't see this earlier. The patch still applies and revdep-rebuild still works as expected with the patch applied on my system.
BTW: The modification has possibly one bug, which I don't know how it should be properly addressed. I have some libraries on my system that link in files using @executable_path: user@host ~ $ otool -L /Gentoo/usr/lib/wine/cmd.exe.so /Gentoo/usr/lib/wine/cmd.exe.so: @executable_path/../lib/libwine.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.11) /Gentoo/usr/lib/gcc/i686-apple-darwin8/4.2.1/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) These files have been installed by custom ported ebuilds (that are not yet ready for publishing) and AFAIK this kind of links should not appear in a sane gentoo-prefix. Is that correct? Should revdep-rebuild consider this kind of links being broken or better resolve the @executable_path?
From an automation point of view, Gentoo Prefix can't use those. Portage currently ignores them, perhaps revdep-rebuild should do the same.
Created attachment 192288 [details, diff] Patch with modifications specific to Darwin I filtered out anything containing @executable_path. The scanmacho looks really attractive here, because I think it's possible to use it to replace the @executable_path just as the linker would do it in a single pipeline for MH_EXECUTABLE's. I leave that for the time when someone rewrote revdep-rebuild again from scratch. @executable_path seems to be meant to link libraries and frameworks within the same component and thus the uncovered scenario is minimal IMHO.
Created attachment 192756 [details, diff] Patch with modifications specific to Darwin Updated version of patch 192288. The "-L" option to select a particular broken library wasn't working.
Portage's preserve-libs superseedes revdep-rebuild on Darwin, sorry.
(In reply to comment #13) > Portage's preserve-libs superseedes revdep-rebuild on Darwin, sorry. I remember you said that back then already. But for some reason it didn't catch all the issues I had on my box.
