"Johnny C. Lam" wrote:
> 
> Nick Hudson <nick@nthcliff.demon.co.uk> writes:
> >
> > "Johnny C. Lam" wrote:
> > >
> > > Create _pic.a libraries needed by forthcoming xerces-p package.
> > > XXX This uses libtool internals!
> > > Requested in private mail by Emmanuel Dreyfus <p99dreyf@criens.u-psud.fr>.
> >
> > Which reminds me...
> >
> > Why do you need it to be called _pic.a? Can't you just use the normal .a
> > library created by libtool - all the objects are compiled with -fPIC
> > -DPIC which is what you are after, right?. Unless I don't understand
> > what you are trying to do - which is, of course, very likely.
> 
> My understanding of how libtool currently works is as follows.  First,
> libtool generates a directory .libs.  Then during compilation, it
> generates an object file compiled with PIC flags in ./.libs/foo.o and
> an object file compiled without PIC flags in ./foo.o.  Then during
> linking, a shared library libfoo.so is created from ./.libs/*.o and a
> static library libfoo.a is created from ./*.o.  So libfoo.a is
> composed of objects compiled _without_ the PIC flags.

You're right if you specify the -rpath flag to libtool. If you don't get
a library of the -fPIC objects.

$ libtool --mode=compile cc -c foo.c
cc -c foo.c  -fPIC -DPIC -o .libs/foo.o
cc -c foo.c -o foo.o >/dev/null 2>&1
$
$ libtool --mode=link cc -o libl1_pic.la foo.lo
rm -fr  .libs/libl1_pic.a .libs/libl1_pic.la
ar cru .libs/libl1_pic.a .libs/foo.o
ranlib .libs/libl1_pic.a
creating libl1_pic.la
(cd .libs && rm -f libl1_pic.la && ln -s ../libl1_pic.la libl1_pic.la)

Nick
ps. Still don't understand why you can't use the shared library. I must
read your email again...
-- 
aka skrll@netbsd.org, skrll@excite.co.uk