tags 397603 + pending thanks On Wed, 2006-11-08 at 13:03 -0200, Henrique de Moraes Holschuh wrote: > Usually, linking libs with non-pic code is a bug in the makefile, especially > when libtool is being used (libtool should be handling this fine, and if we > relibtoolize, it *really* should be handling it fine). When using libtool + > automake (1.9 or 1.10), it gets especially difficult to get it wrong :-)
Yeah! :) I can't reproduce this consistently on a vserver running on an amd64 box. It seems that just before submitting that bug, I was able to reproduce it, but now I can't reproduce it any more. That said, I want to try the suggestion below. On Wed, 2006-11-08 at 20:39 +0100, Andreas Metzler wrote: > Anybody for this - a phony target re-generating > proper ./libs/libsasldb.a? > > libsasldb.a: libsasldb.la $(SASL_DB_BACKEND_STATIC) > cd .libs && $(AR) cru $@ $(SASL_DB_BACKEND_STATIC) I think you've helped me see the problem :) The above is good, but I would do it the other way around, so to speak. The way I read sasldb/Makefile.am, the last rule is for generating the static version of libsasldb.a. If the idea is to put shared objects in .libs and static objects in ., then I'd propose the following patch: --- sasldb/Makefile.am (revision 133) +++ sasldb/Makefile.am (working copy) @@ -63,6 +63,6 @@ EXTRA_libsasldb_a_SOURCES = libsasldb.a: libsasldb.la $(SASL_DB_BACKEND_STATIC) - $(AR) cru .libs/$@ $(SASL_DB_BACKEND_STATIC) + $(AR) cru $@ $(SASL_DB_BACKEND_STATIC) This results in the following build log fragment (some warnings removed to make it easier to follow): x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../include -I/usr/include/mysql -I/usr/include/postgresql -I/usr/include -Wall -W -Wall -g -O2 -Wl,-z,defs -MT db_berkeley.lo -MD -MP -MF .deps/db_berkeley.Tpo -c db_berkeley.c -fPIC -DPIC -o .libs/db_berkeley.o x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../include -I/usr/include/mysql -I/usr/include/postgresql -I/usr/include -Wall -W -Wall -g -O2 -Wl,-z,defs -MT db_berkeley.lo -MD -MP -MF .deps/db_berkeley.Tpo -c db_berkeley.c -o db_berkeley.o >/dev/null 2>&1 /bin/sh ../libtool --tag=CC --mode=link x86_64-linux-gnu-gcc -Wall -W -Wall -g -O2 -Wl,-z,defs -o libsasldb.la allockey.lo db_berkeley.lo -lresolv ar cru .libs/libsasldb.a .libs/allockey.o .libs/db_berkeley.o ranlib .libs/libsasldb.a creating libsasldb.la (cd .libs && rm -f libsasldb.la && ln -s ../libsasldb.la libsasldb.la) ar cru libsasldb.a db_berkeley.o allockey.o So lines 1 and 2 create PIC and non-PIC versions, respectively. Line 4 creates an archive with PIC versions, and the last line creates an archive with non-PIC versions. Apparently libtool takes care of the PIC case, and the Makefile.am rule takes care of the non-PIC case. (?) I'm tagging this pending and committing the above with a Closes: line in the changelog. If it doesn't work (either when the buildds have run the next upload, or someone with an amd64/hppa box has tested this) we'll just reopen the bug. Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part