Re: Installing convenience libraries

[Ralf Wildenhues]

Hello Akim,

* Akim Demaille wrote on Fri, Sep 29, 2006 at 12:05:39PM CEST:
> >>> "Ralf" == Ralf Wildenhues <address@hidden> writes:
>  >
>  > Convenience archives are not intended to be installed.
> 
> This is a quote from the documentation:
> 
>    You can even install a convenience library using GNU Libtool,
>    though you probably don't want to and hence GNU Automake doesn't
>    allow you to do so.
> 
> I guess it should read "static" instead of "convenience", in
> particular since the example seems to refer to a plain library
> (it uses .a):

Actually, I think it really means "convenience archives".  And I think
it stems from a time when convenience archives were not named *.la.  And
this still works, so you can use it as a workaround as long as things
don't work with libconv.la.  (The only system it won't work on then is
w32 with MSVC with the LIB archiver instead of ar.)

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).

I'm not sure whether I want to classify any of these as bug (except the
documentation one).  I'm very reluctant to make installability for
convenience archives too easy for users, for fear of the scenarios
stated.

>  > Why?  Because that breaks dependency analysis, and it's not clean style.
>  > The former could be fixed in Libtool, but the latter leads to problems
>  > such as these scenarios:
> 
> My scenario is really different from yours

Hehe.  I knew it, I should've written this instead:

| (This is a practical assumption in free software environments [...])

;-)

> 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?

>  > (This is a practical assumption, since, if all libraries were from
>  > the same package or tree of packages, you wouldn't have the need to
>  > install libconv in the first place.)
> 
> Yes, I do.  Or maybe not: that seems like the best means to provide
> the libcore to libfull developers.

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

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).

>  > Maybe you rather want to use an installable static library?
>  >   libtool ---mode=link $CC ... -static -rpath /install/path \
>  >           -o libfoo.la foo.lo ...
> 
> But then, I wouldn't have a self-contained libfull, would I?

No, you wouldn't.

Cheers,
Ralf