[Evolution] Re: .la files

Oystein Gisnas oystein at gisnas.net
Tue Jun 13 15:18:43 UTC 2006


tir, 13,.06.2006 kl. 16.55 +0200, skrev Josselin Mouette:
> Le lundi 12 juin 2006 à 18:37 +0200, Øystein Gisnås a écrit :
> > The symptoms can be seen when building something that depends on
> > evolution, for example evolution-exchange. Compile and linking succeed,
> > but the binaries that linked
> > against /usr/lib/evolution/2.6/libeutil.so.0.0.0
> > and /usr/lib/evolution/2.6/libevolution-addressbook-a11y.so.0.0.0 cannot
> > resolve those libraries, because RPATH is missing (can be seen with
> > objdump -p evolution-exchange-storage).
> > 
> > I have two questions. First, is it OK that another package links against
> > a library that is not in /usr/lib?
> 
> I don't think it's a good idea, no.
> 
> > Second, if the location of the libs
> > is OK, how can I make libtool put RPATH into evolution-exchange-storage
> > and other binaries linked against the two troublesome libraries? Is it a
> > bug in libtool, or must one set a flag to force RPATH in Makefile.am or
> > something?
> 
> Another option is to put the libraries in /usr/lib and to use libtool's
> -release flag, so that they are called libeutil-2.6.so.0.0.0 and so on.
> Then, it makes sense to put them in a separate library package (like
> libevolution-2.6-0).

The problem is then, of course, that upstream should be convinced to
reach a good long-term solution. There are 22 different libraries, and
something tell me it's gonna be a bit difficult.

As an interim solution I chose to explicitly tell each binary that links
against these libraries which RPATH to use. The good news is that .la
files then can be removed from evolution again.

My best suggestion for a long term solution is to pkg-config the private
libraries with "ldflags=-Wl,-R/usr/lib/evolution/2.6", and try to push
that through upstream.

-Øystein



More information about the Pkg-evolution-maintainers mailing list