DirectFB 0.9.15 emerge fails -> Attempts to link against non-existant/old
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
core/libdirectfb_core.la -ldl -lpthread
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
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
gcc: /usr/lib/libdirectfb.so: No such file or directory
make: *** [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
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.
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"
CFLAGS="-march=pentium4 -O3 -pipe"
CXXFLAGS="-march=pentium4 -O3 -pipe"
CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config
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
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?
i know there are quite a few, but it'll help if you have some time to do it.
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
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
(220.127.116.1120601, 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: *** [SDL_DirectFB_video.lo] Error 1
make: Leaving directory
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
Please excuse my verbosity, but I'd often rather give too much information than
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
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?
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 ?