x86_64-pc-linux-gnu-gcc -o mgp -O2 -fno-strength-reduce -fno-strict-aliasing -L/usr/lib64 mgp.o draw.o parse.o plist.o globals.o x11.o font.o background.o scanner.o grammar.o postscript.o tfont.o embed.o unimap.o mng.o m17n.o strlcpy.o strlcat.o -L./image -lmgpimage -lm -L/usr/lib -lpng12 -lz -lm -L/usr/lib -lpng -L/usr/lib -Wl,-rpath,/usr/lib -lmng -L/usr/X11R6/lib -lXft -lX11 -lfreetype -lXrender -lfontconfig -lImlib -ljpeg -ltiff -lungif -lpng -lz -lm -lSM -lICE -lXext -lX11 -lgif -lXext -lX11 /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lungif collect2: ld returned 1 exit status make: *** [mgp] Error 1 !!! ERROR: app-office/magicpoint-1.11b failed. !!! Function src_compile, Line 68, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message.
Created attachment 62030 [details] 5391-magicpoint-1.11b.log
No, 1.11b does not depend on libungif. Re-emerging imlib will probably fix the error. <snip> MY_DEPEND="virtual/x11 gif? ( >=media-libs/giflib-4.0.1 ) imlib? ( media-libs/imlib ) </snip>
The issue was, a revdep-rebuild did not reinstalled imlib, and magicpoint uses the same -l flags that imlib used to compile. The solution was: # revdep-rebuild broken /usr/lib/imlib2/loaders/gif.so (requires libungif.so.4) (but it did not reinstalled imlib) # emerge =media-libs/imlib-1.9.14-r3 # emerge =app-office/magicpoint-1.11b And done... The problem (with revdep-rebuild) is related to this: $ equery belongs /usr/lib/imlib2/loaders/gif.so [ Searching for file(s) /usr/lib/imlib2/loaders/gif.so in *... ] $ equery belongs /usr/lib64/imlib2/loaders/gif.so [ Searching for file(s) /usr/lib64/imlib2/loaders/gif.so in *... ] media-libs/imlib2-1.2.0.007 (/usr/lib64/imlib2/loaders/gif.so) I think this is a know bug of revdep rebuild, should this bug marked as INVALED?
Looks like it's a duplicate of bug 37029... If so plese mark as such.
Which version of gentoolkit do you have installed?
app-portage/gentoolkit-0.2.1_pre3
What does the following command return: echo /usr/lib/imlib2/loaders/gif.so | sed 's/^/obj /' | (cd /var/db/pkg; grep -l -f - */*/CONTENTS) | sed s:/CONTENTS:: Please run revdep-rebuild --keep-temp --pretend and attach the file ~/.revdep-rebuild.0_env to the case
Created attachment 62111 [details] .revdep-rebuild.0_env % echo /usr/lib/imlib2/loaders/gif.so | sed 's/^/obj /' | (cd /var/db/pkg; grep -l -f - */*/CONTENTS) | sed s:/CONTENTS:: <nothing> If I use /usr/lib64 the output is: media-libs/imlib2-1.2.0.007 Also I'm having this problem: All prepared. Starting rebuild... emerge --oneshot --pretend =app-emulation/-MERGING-emul-linux-x86-gtklibs-2.1 =app-emulation/emul-linux-x86-gtk libs-2.1 =www-client/mozilla-firefox-bin-1.0.4 These are the packages that I would merge, in order: Calculating dependencies emerge: there are no ebuilds to satisfy "=app-emulation/-MERGING-emul-linux-x86-gtklibs-2.1"
Created attachment 62114 [details] .revdep-rebuild.0_env In order to reproduce the first bug (lib/lib64) I reinstalled libungif then reinstalled imlib2 and at last unmerged libungif... ------------ revdep-rebuild --keep-temp --pretend Configuring search environment for revdep-rebuild Checking reverse dependencies... Packages containing binaries and libraries broken by a package update will be emerged. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... broken /emul/linux/x86/usr/lib/gtk/themes/engines/libpixmap.so (requires libgdk_imlib.so.1) broken /usr/lib/imlib2/loaders/gif.so (requires libungif.so.4) broken /usr/lib32/nsbrowser/plugins/libnullplugin.so (requires libnspr4.so libplc4.so libplds4.so libxpcom.so) done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds) Evaluating package order... Warning: Failed to resolve package order. Will merge in "random" order! Possible reasons: - An ebuild is no longer in the portage tree. - An ebuild is masked, use /etc/portage/packages.keyword and/or /etc/portage/package.unmask to unmask it ..... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild... emerge --oneshot --pretend =app-emulation/-MERGING-emul-linux-x86-gtklibs-2.1 =app-emulation/emul-linux-x86-gtklibs-2.1 =www-client/mozilla-firefox-bin-1.0.4
Let's fix one thing at a time. The first thing that I'm seeing is that revdep-rebuild isn't picking up the lib64 directory. What does ls -ld /usr/lib64 show? Secondly, what is the result of running: env SEARCH_DIRS="/usr/lib64" revdep-rebuild --keep-temp --pretend For the second issue, what does the following show? cd /var/db/pkg grep -l MERGING */*/*CONTENTS
The '=app-emulation/-MERGING-emul-linux-x86-gtklibs-2.1' problem was an incomplete merge: INCOMPLETE MERGE: /var/db/pkg/app-emulation/-MERGING-emul-linux-x86-gtklibs-2.1 Caused most probably by a ^C when testing revdep-rebuild. So now its fixed. I removed that dir, unmerged emul-linux-x86-gtklib, and then reemerged.
> revdep-rebuild isn't picking up the lib64 directory. That's the problem, because it's a symlink and readlink are removing it: 94 SEARCH_DIRS="$(echo $SEARCH_DIRS $(readlink -f $i))" > What does ls -ld /usr/lib64 show? $ ls -ld /usr/lib64 lrwxrwxrwx 1 root root 3 Apr 17 16:15 /usr/lib64 -> lib > Secondly, what is the result of running: > env SEARCH_DIRS="/usr/lib64" revdep-rebuild --keep-temp --pretend Exaclty the same: ... Checking dynamic linking consistency... broken /emul/linux/x86/usr/lib/gtk/themes/engines/libpixmap.so (requires libgdk_imlib.so.1) broken /usr/lib/imlib2/loaders/gif.so (requires libungif.so.4) ... Calculating dependencies ...done! [ebuild R ] app-emulation/emul-linux-x86-gtklibs-2.1 [ebuild R ] www-client/mozilla-firefox-bin-1.0.4 > > For the second issue, what does the following show? My fault by hitting ^C whenever I dont have to do it :P, fixed, see Comment #11
Created attachment 62136 [details, diff] revdep-rebuild.patch I hope it helps. This patch resolves the problem and also contains little enhancements. Changelog * $PRELIMINARY_SEARCH_DIRS_MASK also incrementes with $MULTILIB_STRICT_DIRS * $SEARCH_DIRS_MASK its now an array * Removes duplicated items on $SEARCH_DIRS * Apply SEARCH_DIRS_MASK to SEARCH_DIRS before we look (find) for shared objects. * Added SEARCH_DIRS_BEFOREMASK (self descriptive) * Fix Bug #97171 adding /lib64/ /usr/lib64/ directories to $SEARCH_DIRS when running an AMD64 multilib-symlink profile * Removed code that matchs SEARCH_DIR_MASK after the find
(In reply to comment #12) > $ ls -ld /usr/lib64 > lrwxrwxrwx 1 root root 3 Apr 17 16:15 /usr/lib64 -> lib In 2005.0, (/usr)/lib64 is a directory, and (/usr)/lib is a symlink to it, so sth is really wrong or you're still using 2004.3. if not, please correct this
Created attachment 62142 [details, diff] revdep-rebuild.lib64.patch Thanks for the patch, I will review it for use in future versions. In the meantime, would you be willing to revert back to the original revdep-rebuild, apply the attached patch, and retest?
Created attachment 62144 [details, diff] revdep-rebuild.patch The problem is with a not totally migrated 2004.3 -> 2004.5 which it a seems to be common situation on amd64. Thanks to Blubb to point the reversed symlink situation.
(In reply to comment #15) > Created an attachment (id=62142) [edit] > revdep-rebuild.lib64.patch > > Thanks for the patch, I just submitted Attachment #62144 [details, diff] :-) > I will review it for use in future versions. Thanks :-) I like the part to apply SEARCH_DIRS_MASK to SEARCH_DIRS before find. > meantime, would you be willing to revert back to the original revdep-rebuild, > apply the attached patch, and retest? Right now I fixed my symlink situation, but that was one of my first tests and -IIRC- it doesnt work beacause `find` doesn't follow symlinks (And is not a good idea to run find with the -L option). This is why in my patch are this: [[ -L /lib64 || -L /usr/lib64 ]] && SEARCH_DIRS="$(echo /lib64/ /usr/lib64/ $SEARCH_DIRS)" (Note the last/second slash, in order to 'treat it' like a directory and not like a symlink)
Actually find does follow the links, the line that I changed in my patch was reverting the change I put in for bug #93574. I would like to verify that reverting that fix, fixes this bug. This is a more critical bug to be fixed. Additionally, since I am trying to stabilize this version of revdep-rebuild, I am making as few changes as possible. I will definitely consider the work that you have done for versions after this one.
ls -lad lib* drwxr-xr-x 10 root root 4016 Jun 23 17:16 lib drwxr-xr-x 3 root root 1640 Jun 1 05:39 lib32 lrwxrwxrwx 1 root root 3 Jun 28 16:31 lib64 -> lib drwxr-xr-x 2 root root 72 Jan 12 16:58 libdirs $ find /lib64 /lib64 $ find /lib64/ /lib/ /lib/cpp /lib/tls ... > I would like to verify that > reverting that fix, fixes this bug. It doesnt. :( The patch makes that SEARCH_DIRS get expanded like that: SEARCH_DIRS="/bin /sbin /usr/bin /usr/sbin /lib /lib32 /lib64 /libdirs ..." instead of SEARCH_DIRS="/bin /sbin /usr/bin /usr/sbin /lib /lib32 /lib ... " But find then, receive symlinks as an argumenta and it doesnt follow it so the result is the same: Checking dynamic linking consistency... broken /emul/linux/x86/usr/lib/gtk/themes/engines/libpixmap.so (requires libgdk_imlib.so.1) broken /usr/lib/imlib2/loaders/gif.so (requires libungif.so.4) [ebuild R ] app-emulation/emul-linux-x86-gtklibs-2.1 [ebuild R ] www-client/mozilla-firefox-bin-1.0.4
Appending [[ -L /lib64 || -L /usr/lib64 ]] && SEARCH_DIRS="$(echo /lib64/ /usr/lib64/ $SEARCH_DIRS)" Fix the problem, but there is going to find duplicated entries (and also will look twice in the same directories) broken /emul/linux/x86/usr/lib/gtk/themes/engines/libpixmap.so (requires libgdk_imlib.so.1) broken /usr/lib/imlib2/loaders/gif.so (requires libungif.so.4) broken /usr/lib32/nsbrowser/plugins/libnullplugin.so (requires libnspr4.so libplc4.so libplds4.so libxpcom.so) broken /usr/lib64/imlib2/loaders/gif.so (requires libungif.so.4) This is why I apply SEARCH_MASK (with MULTILIB_STRICT_DIRS expanded inside) _before_ the find in order to avoid this.
Created attachment 62216 [details, diff] revdep-rebuild.lib64.patch Here is the patch for the version of revdep-rebuild that has been placed into subversion. Please verify the fix and I will release a new version of gentoolkit shortly.
gentoolkit-0.2.1_pre4 is now in the tree.
*** Bug 103068 has been marked as a duplicate of this bug. ***
*** Bug 105614 has been marked as a duplicate of this bug. ***
