Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 12468 - DirectFB 0.9.15 emerge fails -> Attempts to link against non-existant/old /usr/lib/
Summary: DirectFB 0.9.15 emerge fails -> Attempts to link against non-existant/old /us...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: x86 Linux
: High major (vote)
Assignee: Jonathan Nall
Depends on:
Reported: 2002-12-19 23:56 UTC by Eric Andresen
Modified: 2007-02-08 20:56 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Eric Andresen 2002-12-19 23:56:26 UTC
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 -rpath
/usr/lib -version-info 15:0:0              -release 0.9                        
                    directfb.lo idirectfb.lo interface.lo
display/           media/            
 windows/          input/            
 misc/                gfx/
core/ -ldl -lpthread
mkdir .libs
rm -fr .libs/ .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/ media/.libs/
windows/.libs/ input/.libs/
misc/.libs/ gfx/.libs/
core/.libs/ -Wl,--no-whole-archive  -L/usr/X11R6/lib -lstdc++
-L/usr/lib /usr/lib/ /usr/lib/ -lXext -lvga
/usr/lib/ -lslang -lm -lX11 -ldl -lpthread  -Wl,-soname
-Wl, -o
gcc: /usr/lib/ No such file or directory
make[3]: *** [] Error 1

As seen here, DirectFB is seeing "/usr/lib/" 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).
Comment 1 Eric Andresen 2002-12-20 00:12:48 UTC
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/ in the original log paste, no other
changes [besides the error, which is seen here])
Comment 2 Seemant Kulleen (RETIRED) gentoo-dev 2002-12-20 00:55:20 UTC
Jon, you'll love this one :P
Comment 3 Jonathan Nall 2002-12-31 07:48:51 UTC
from what i can tell, the -ldirectfb is due to the including of
/usr/lib/ 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/ 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/ 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. 

Comment 4 Eric Andresen 2002-12-31 11:19:32 UTC
As reasonable an assessment as that is, /usr/lib/ does not contain
-ldirectfb or any variant of it on the dependancy line, nor anywhere else within
the file. 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.
Comment 5 Jonathan Nall 2002-12-31 11:36:37 UTC
oh well, it was a try.

can you do a:
grep ldirectfb /usr/lib/*.la

and post any interesting results?

Comment 6 Eric Andresen 2002-12-31 14:59:34 UTC
No matches on ldirectfb, directfb, or any variation (besides the actual library
names, of course)
Comment 7 Jonathan Nall 2003-01-05 13:11:33 UTC
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.
Comment 8 Eric Andresen 2003-01-05 21:32:18 UTC
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
/usr/kde/2/share/config /usr/kde/3/share/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"

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

Comment 9 Jonathan Nall 2003-01-06 10:11:35 UTC
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
Comment 10 Eric Andresen 2003-01-06 12:10:47 UTC
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
Comment 11 Jonathan Nall 2003-01-06 15:26:10 UTC
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.
Comment 12 Eric Andresen 2003-01-06 20:25:53 UTC
Doing as suggested, the culprit .la file is from src/core/
The dependency_libs= line is thus:
dependency_libs=' -lstdc++ -L/usr/lib /usr/lib/ -L/usr/X11R6/lib -laa
-ldirectfb -lXext -lvga /usr/lib/ -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/ 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
(, 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
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.
Comment 13 Jonathan Nall 2003-01-06 20:59:01 UTC
k. looks like we're getting somewhere. i think i know what to look at now.
thanks for the great digging!
Comment 14 Jonathan Nall 2003-01-06 21:31:10 UTC
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/ 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?
Comment 15 Jonathan Nall 2003-01-10 08:56:04 UTC
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)
Comment 16 DEMAINE Benoît-Pierre, aka DoubleHP 2007-02-08 20:53:39 UTC
Isn't this bug in fact dup of bug #152405 ?
Comment 17 DEMAINE Benoît-Pierre, aka DoubleHP 2007-02-08 20:56:32 UTC
Or maybe rather BLOCKING/DEPENDING #152405 ?