libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dependency_libs?


From: Andreas Volz
Subject: Re: dependency_libs?
Date: Tue, 2 May 2006 13:22:54 +0200

Am Sun, 30 Apr 2006 11:52:16 -0700 schrieb Russ Allbery:

> Andreas Volz <address@hidden> writes:
> 
> > I build my library with GNU autotools and link to it with the
> > pkg-config --uninstalled option without installing it. In this case
> > a la-file (libmhgui.la) is created. I've some problems to
> > understand how libtool generated the dependency_libs field. In my
> > package is a --with-x/--without-x option from AC_PATH_X.  But the
> > la-file has the X libraries in its dependency_libs field. So how
> > does libtool generate this field?
> 
> Well, you say that the correct field is:
> 
> > # Libraries that this one depends upon.
> > dependency_libs=' 
> > /home/andreas/src/MakeHuman/cvs/animorph/src/libanimorph.la
> > -l glut -lGLU -lGL -lpng 
> 
> I expect that one of glut, GLU, and GL depend on the X libraries, and
> hence when libtool resolves transitive dependencies through the .la
> files, it pulls in the other libraries.
> 
> This is one of the problems with .la files currently.  It doesn't
> have the correct semantics to distinguish between static builds (and
> builds on platforms with deficient shared library handling) where all
> transitive dependencies have to be pulled into the link line and
> shared builds on modern platforms where transitive dependencies do
> not have to be pulled in and in fact generally *shouldn't* since they
> make library migrations harder.
> 
> pkg-config does have this logic and some packages have started not
> installing libtool .la files and recommending that people just use
> pkg-config to get the right link lines to avoid this.  That being
> said, the addition of extra dependencies is generally only a problem
> if you're building OS packages and have to be careful about adding
> too many dependencies.  If you're just building software for local
> use, it doesn't really matter.

Yes, but in this special case it's important. I use a win32 cross
compiler environment and this put me into trouble by linking to X.

Now I found out that the X linking is transitive through the freeglut
library. 

# The name of the static archive.
old_library='libfreeglut.a'

# Libraries that this one depends upon.
dependency_libs=' -L/opt/xmingw/i386-mingw32msvc/lib -lm -lGL -lGLU
-lXext -lX11'
...

I compiled installed only the static .a library. I compiled it with 
--without-x and it works. So is the only solution to not install the
libfreeglut.la? I don't understand from where libtool gets the -lXext 
-lX11 flag. There're nearly no .la files in my cross compilers
library dir. 

Perhaps my cross compiler enviroment isn't sane. If I don't use
--without-x my hosts X installation is found:

...
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
...

I assume this shouldn't happen. May this be a problem. Any ideas how
to solve this?

regards
Andreas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]