Advice on PIC issue

[Fabian Fagerholm]

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 <fabbe at paniq.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/attachments/20061109/43df019e/attachment-0001.pgp