DirectFB 0.9.15 emerge fails -> Attempts to link against non-existant/old /usr/lib/libdirectfb.so The error is as follows: /bin/sh ../libtool --mode=link gcc -D_REENTRANT -march=pentium4 -O3 -pipe -ffast-math -Wall -O3 -g -DFUSION_FAKE -lstdc++ -o libdirectfb.la -rpath /usr/lib -version-info 15:0:0 -release 0.9 directfb.lo idirectfb.lo interface.lo display/libdirectfb_display.la media/libdirectfb_media.la windows/libdirectfb_windows.la input/libdirectfb_input.la misc/libdirectfb_misc.la gfx/libdirectfb_gfx.la core/libdirectfb_core.la -ldl -lpthread mkdir .libs rm -fr .libs/libdirectfb.la .libs/libdirectfb.* .libs/libdirectfb-0.9.* (cd . && ln -s directfb.lo directfb.o) (cd . && ln -s idirectfb.lo idirectfb.o) (cd . && ln -s interface.lo interface.o) gcc -shared directfb.lo idirectfb.lo interface.lo -Wl,--whole-archive display/.libs/libdirectfb_display.al media/.libs/libdirectfb_media.al windows/.libs/libdirectfb_windows.al input/.libs/libdirectfb_input.al misc/.libs/libdirectfb_misc.al gfx/.libs/libdirectfb_gfx.al core/.libs/libdirectfb_core.al -Wl,--no-whole-archive -L/usr/X11R6/lib -lstdc++ -L/usr/lib /usr/lib/libSDL.so /usr/lib/libdirectfb.so -lXext -lvga /usr/lib/libaa.so -lslang -lm -lX11 -ldl -lpthread -Wl,-soname -Wl,libdirectfb-0.9.so.15 -o .libs/libdirectfb-0.9.so.15.0.0 gcc: /usr/lib/libdirectfb.so: No such file or directory make[3]: *** [libdirectfb.la] Error 1 As seen here, DirectFB is seeing "/usr/lib/libdirectfb.so" as a dependant lib, and linking to it, which causes the build to fail if no previous DirectFB is installed, or worse, causes it to link to an older version of DirectFB that is installed, creating recursive dependencies (which then break, when autoclean kills the older directfb install). I think I've figured out that the libtool script in the source package is what is listing this as a $deplib, but I've yet to figure out how to resolve the issue, without resorting to emering 0.9.12, then 0.9.15, and emerging 0.9.15 a second time (thus making it link to itself, rather than an older version).
I re-emerged and unemerge 0.9.12 again, and then tried 0.9.15, and got a similar problem, except now its saying ld: cannot find -ldirectfb Which essentially is the same thing as before. (s:/usr/lib/libdirectfb.so:-ldirectfb: in the original log paste, no other changes [besides the error, which is seen here])
Jon, you'll love this one :P
hmmm, from what i can tell, the -ldirectfb is due to the including of /usr/lib/libSDL.la. i think this means that you once had directfb installed. while it was installed, you installed SDL which linked against it. at some point later you removed DirectFB (but /usr/lib/libSDL.la still references it). then when you try and re-install DirectFB, it tries to pull in the SDL stuff, which has a reference to directfb. 0.9.12 didn't use SDL, which is why it compiles. this is my best guess. if you think i'm wrong, i'm happy to look into it further. however, check /usr/lib/libSDL.la for a line like: dependency_libs=' -ldirectfb -lpthread -ldl -lm -L/usr/lib -lesd -laudiofile -lm -L/usr/X11R6/lib -lX11 -lXext -laa -ldl' if that line holds -ldirectfb, i'm reasonably sure my analysis above is on target. thanks.
As reasonable an assessment as that is, /usr/lib/libSDL.la does not contain -ldirectfb or any variant of it on the dependancy line, nor anywhere else within the file. libSDL.so does not even link against DirectFB according do an ldd. For the meantime I've simply downgraded to .12 and rebuilt all packages using DirectFB, but I'd like to be able to figure this out as well as I'm sure you would.
oh well, it was a try. can you do a: grep ldirectfb /usr/lib/*.la and post any interesting results?
No matches on ldirectfb, directfb, or any variation (besides the actual library names, of course)
i just emerged DirectFB on a vanilla stage3 chroot with everything in that ebuild's IUSE flag turned off. it emerged fine. can you post the results of: `emerge info`? thanks.
This is the emerge info for the system with the problem: Portage 2.0.46-r4 (default-x86-1.4, gcc-3.2.1, glibc-2.3.1-r2) ================================================================= System uname: 2.4.20-acpi-r9 i686 Mobile Intel(R) Celeron(R) CPU 1.80GHz USE="oss 3dnow crypt jpeg kde libg++ libwww mikmod nls pdflib qtmt xml2 gtkhtml gdbm berkdb aalib bonobo guile tcpd pam ssl python imlib motif mmx sse x86 X gtk gnome -alsa acpi apm -arts -3dfx avi cdr dvd encode -esd evo fbcon gif gpm java mbox mozilla moznomail moznoirc moznocompose mpeg ncurses oggvorbis opengl pcmcia pdfli perl png pnp qt qtnt quicktime readline samba sdl spell slang svga tcltk truetype xmms xv zlib -cups directfb" ARCH="x86" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe" CXXFLAGS="-march=pentium4 -O3 -pipe" ACCEPT_KEYWORDS="x86" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" MAKEOPTS="-j2" JDK_HOME="/opt/blackdown-jdk-1.3.1" JAVA_HOME="/opt/blackdown-jdk-1.3.1" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" GENTOO_MIRRORS="http://www.ibiblio.org/pub/Linux/distributions/gentoo" I've also tried a clean install of DirectFB 0.9.15 on my other systems, and have had no problems, but the laptop still links 0.9.15 to whatever version is installed, and complains if none is installed currently. My guess is it has something to do with the use flags.. So I've compared them between two systems The use flags that the laptop has that the other systems do not are: acpi, fbcon, pcmcia, pdflib, pnp, and sse
k, i'm at work, so i'll look at these flags when i get home. in the meantime, does this show anything interesting: find / -name \*.la | xargs grep directfb
The only things that match that grep are libaviplay, libdirectfb itself, things in /usr/lib/directfb-0.9.12/* (or .15 when thats installed), and a few transcode filters.
in your first post, you quoted the failing libtool command can you post the dependency_libs= line of the various lib*.la files in that command? display/libdirectfb_display.la media/libdirectfb_media.la windows/libdirectfb_windows.la input/libdirectfb_input.la misc/libdirectfb_misc.la gfx/libdirectfb_gfx.la core/libdirectfb_core.la i know there are quite a few, but it'll help if you have some time to do it. thanks!
Doing as suggested, the culprit .la file is from src/core/libdirectfb_core.la The dependency_libs= line is thus: dependency_libs=' -lstdc++ -L/usr/lib /usr/lib/libSDL.la -L/usr/X11R6/lib -laa -ldirectfb -lXext -lvga /usr/lib/libaa.la -lslang -lm -lX11 -ldl -lpthread ' From there I went ahead and double checked the referenced .la files and libs for what they are linked to.. Well, it seems I must be a fool, for /usr/lib/libSDL.la does indeed have -ldirectfb in the dependency_libs, although I'm quite certain that my previous checks returned naught of it, but it has not changed since Dec 7th according to its access time. Then I suppose, the problem is how to avoid this in the future? libSDL's ebuild uses the directfb use flag, which causes it to link to libdirectfb, but libdirectfb links to SDL, causing a circular link, or so I've determined. To test this theory, place directfb in your USE, compile directfb-0.9.12, then libsdl, and then directfb-0.9.15. Then run ldd on the resultant libdirectfb. You should then see that libdirectfb-0.9.15 is linked to libdirectfb-0.9.12 (which was likely unmerged after the 0,9.15 emerge, depending on how you did it.) However, if you use 0.9.12 the second time as well as the first, it does not attempt to link to itself, but this is because SDL is not linked in ebuilds before 0.9.14. I'm not quite sure you'd go about fixing this, as compiling directfb 0.9.15 (with libSDL unemerged at the time) works, but then compiling libSDL (1.2.4.20020601, latest marked stable) with the directfb USE flag causes the compile to fail with: SDL_DirectFB_video.c: In function `DirectFB_CreateDevice': SDL_DirectFB_video.c:105: warning: implicit declaration of function `memset' SDL_DirectFB_video.c: In function `DirectFB_VideoInit': SDL_DirectFB_video.c:332: warning: passing arg 2 of pointer to function makes pointer from integer without a cast SDL_DirectFB_video.c:332: too many arguments to function make[3]: *** [SDL_DirectFB_video.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/libsdl-1.2.4.20020601/work/SDL12/src/video/directfb' Of which that line is: ret = dfb->CreateEventBuffer (dfb, DICAPS_ALL, &eventbuffer); libSDL 1.2.5 however, compiled fine with libdirectfb 0.9.15. Thus the final solution as I see it: USE="directfb", emerge directfb 0.9.15, emerge libsdl 1.2.5, emerge directfb 0.9.15 again. Please excuse my verbosity, but I'd often rather give too much information than not enough.
k. looks like we're getting somewhere. i think i know what to look at now. thanks for the great digging!
hmmm, it seems that libsdl will ONLY link in DirectFB >= 0.9.14. are you really, really sure that you didn't have DirectFB-0.9.15 on the machine, then compile libsdl, then remove DirectFB? i just did the following: emerge unmerge libsdl DirectFB emerge /usr/portage/dev-libs/DirectFB/DirectFB-0.9.12.ebuild emerge libsdl the /usr/lib/libSDL.la at this point does not contain -ldirectfb. futher, although --enable-directfb-video is passed to the libsdl configure script, the script overrides using DirectFB to NO since it's <0.9.14. i'm not sure how to proceed as the sequence you described in your last post seems to work fine for me. what do you think?
ok, this is a legit bug. there should be some forthcoming features in portage to deal with this type of thing. for now i'm marking it as REMIND and will revisit it then. looks like the current solution is to emerge DirectFB twice (once before libsdl, and once after)
Isn't this bug in fact dup of bug #152405 ?
Or maybe rather BLOCKING/DEPENDING #152405 ?
