Re: [Evolution-hackers] libtool madness: creates *.so*T linked against the wrong libs

[Patrick Ohly <Patrick Ohly gmx de>]

On Thu, 2007-11-01 at 17:15 +0100, Patrick Ohly wrote:
> Hello,
> 
> I try to compile Evolution 2.12.x on Debian Etch, using Paul Smith's
> Makefile. I was successful once, but not anymore. The problem is that
> "libtool --install" puts e.g. a libebook.so into my installation
> directory which was linked against the system's libcamel and not the one
> >from Evolution 2.12.x.
> 
> I traced it down to the install step:
> 
> patrick gollum(/scratch/evo-src/evolution-data-server/addressbook/libebook)$ rm .libs/libebook-1.2.so.9.1.0T
> patrick gollum(/scratch/evo-src/evolution-data-server/addressbook/libebook)$ /bin/sh ../../libtool --mode=install /usr/bin/install -c  'libebook-1.2.la' '/usr/local/evo-svn/lib/libebook-1.2.la'
> libtool: install: warning: relinking `libebook-1.2.la'
> (cd /scratch/evo-src/evolution-data-server/addressbook/libebook; /bin/sh ../../libtool  --mode=relink gcc -g -Wall -Wmissing-prototypes -Wno-sign-compare -o libebook-1.2.la -rpath /usr/local/evo-svn/lib -version-info 10:0:1 Evolution-DataServer-Addressbook-common.lo Evolution-DataServer-Addressbook-skels.lo Evolution-DataServer-Addressbook-stubs.lo e-address-western.lo e-book-listener.lo e-book-query.lo e-book-view-listener.lo e-book-view.lo e-book.lo e-contact.lo e-destination.lo e-name-western.lo e-vcard.lo -pthread -L/home/patrick/evo-svn/gtk+2.0/lib -lxml2 -lgnome-2 -lpopt -lgnomevfs-2 -lbonobo-2 -lgconf-2 -lgobject-2.0 -lbonobo-activation -lORBit-2 -lm -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 ../../camel/libcamel-1.2.la ../../libedataserver/libedataserver-1.2.la )
> gcc -shared  .libs/Evolution-DataServer-Addressbook-common.o .libs/Evolution-DataServer-Addressbook-skels.o .libs/Evolution-DataServer-Addressbook-stubs.o .libs/e-address-western.o .libs/e-book-listener.o .libs/e-book-query.o .libs/e-book-view-listener.o .libs/e-book-view.o .libs/e-book.o .libs/e-contact.o .libs/e-destination.o .libs/e-name-western.o .libs/e-vcard.o  -Wl,--rpath -Wl,/home/patrick/evo-svn/gtk+2.0/lib -Wl,--rpath -Wl,/usr/local/evo-svn/lib -L/home/patrick/evo-svn/gtk+2.0/lib -L/usr/lib -lxml2 -lgnome-2 -lpopt -lgnomevfs-2 -lbonobo-2 -lgconf-2 -lgobject-2.0 -lbonobo-activation -lORBit-2 -lm -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 -L/usr/local/evo-svn/lib -lcamel-1.2 -ledataserver-1.2  -pthread -Wl,-soname -Wl,libebook-1.2.so.9 -o .libs/libebook-1.2.so.9.1.0
[...]

I found that libtool shuffles the libs around:

44512: gcc -shared .libs/Evolution-DataServer-Addressbook-common.o .libs/Evolution-DataServer-Addressbook-skels.o .libs/Evolution-DataServer-Addressbook-stubs.o .libs/e-address-western.o .libs/e-book-listener.o .libs/e-book-query.o .libs/e-book-view-listener.o .libs/e-book-view.o .libs/e-book.o .libs/e-contact.o .libs/e-destination.o .libs/e-name-western.o .libs/e-vcard.o -Wl,--rpath -Wl,/home/patrick/evo-svn/gtk+2.0/lib -Wl,--rpath -Wl,/usr/local/evo-svn/lib -L/home/patrick/evo-svn/gtk+2.0/lib -L/usr/lib -lxml2 -lgnome-2 -lpopt -lgnomevfs-2 -lbonobo-2 -lgconf-2 -lgobject-2.0 -lbonobo-activation -lORBit-2 -lm -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 -L/usr/local/evo-svn/lib -lcamel-1.2 -ledataserver-1.2 -pthread -Wl,-soname -Wl,libebook-1.2.so.9 -o .libs/libebook-1.2.so.9.1.0
4523: IFS=' 	
'
4526: test relink = relink
4527: eval '(cd $output_objdir && $rm ${realname}T && $mv $realname ${realname}T && $mv "$realname"U $realname)'
44527: cd .libs
44527: rm -f libebook-1.2.so.9.1.0T
44527: mv -f libebook-1.2.so.9.1.0 libebook-1.2.so.9.1.0T
44527: mv -f libebook-1.2.so.9.1.0U libebook-1.2.so.9.1.0
4529: test -n ''
4536: exit 0

So originally the library was compiled okay, but during the "relinking"
step a "-L/usr/local/evo-svn/lib" is missing in the gcc invocation
(-Wl,-rpath for that path is present!) and the wrong libcamel is picked
up.

> Before I start to dissect the "libtool" script (no, please, please,
> spare me), does this look familiar to anyone?

The questions now are: why is the relinking necessary and why does it go
wrong?

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/