Re: Installing convenience libraries

[Akim Demaille]

>>> "Ralf" == Ralf Wildenhues <address@hidden> writes:

Thanks Ralf,

 > (The only system it won't work on then is w32 with MSVC with the
 > LIB archiver instead of ar.)

Bummer.  But I'm not surprised :)

 > Hmm.  By default the
 >   libtool --mode=link $CC -o liba.a a.lo

 > will choose the non-PIC object though; so you will have to put
 > -prefer-pic into compile mode flags, or --tag=disable-static in compile
 > mode flags before --mode=compile.  (The latter avoids double
 > compilation).

Thanks for the details!

 > I'm very reluctant to make installability for convenience archives
 > too easy for users, for fear of the scenarios stated.

I can afford a --yeah-I-want-to-install-a-convenience-library :)


 >> Say you have a company that ships libfull which is composed of
 >> a libcore and extra stuff.  Only few people have access to the sources
 >> of libcore, but libcore is installed on developer stations so that
 >> they can work on the extra-sources to put into libfull (which includes
 >> libcore).  libfull is provided to the clients, and it should be
 >> self-contained.
 >> 
 >> Isn't what libtool convenience libraries are tailored to do?

 > Sure they may be useful in this setting.  But I still don't understand
 > why you just don't simply make libcore be an ordinary shared library?
 > Is that because of relocatability issues?

Eventually we sure will use shared libraries, but as of today, it
seems simpler to first deal with only static libraries.  Besides, my
real problem is making an archive self-contained.  Unless you are
saying that if I had a "shared" libcore (the convenience one) I could
link it directly inside libfull.so?

 > I agree that in this case it may be a practical one.  Another one
 > may be to create a relocatable object that contains all the other
 > ones, i.e., do partial linking
 >
 >   ld -r -o liballofit.o obj1.o obj2.o

That's nice!  I wasn't aware of this feature.  I must say that I don't
know enough on object files to tell what the difference is with a
genuine library.  The toc I guess. I'll do my homework and look for
information on the Internet :)

 > Libtool advertises to do this portably, but that functionality still
 > has (old) bugs.  Also since it's not so often used, GNU binutils ld
 > has bugs with it on some systems (MinGW at least, IIRC).

Guess what: that's one of the targets :(