Re: shared library from smaller pieces

[Ralf Wildenhues]

Hi Vlad,

* Vlad Skvortsov wrote on Fri, Dec 09, 2005 at 11:46:46PM CET:
>
> Ok, I believe I have to explain more here. My product is deemed to be 
> self-contained: no dependencies on external shared libraries, nothing. I 
> build all my [C] applications static. However, recently a need has 
> arised to write a Perl script and include it into the distribution. This 
> script needs some functionality from my core libraries. So I have to 
> build a shared module that my Perl script will load and use. I guarantee 
> that noone else will link against this shared module; if someone will, 
> it's not my problems, since I didn't intend to.
> 
> My application uses third-party library that is [deemed by its author to 
> be] built as shared. However, I want all my applications to link 
> statically against it and I want my shared module to include its 
> contents (so that the end user doesn't have to install this third-party 
> shared library).
> 
> Does it make the situation clearer?

Yes.  The answer is: I don't think this is possible.  This isn't even a
limitation of the autotools, but simply a limitation of most systems:
you can't portably get a shared library to end up being contained in an
archive, and the result be used correctly.  Somebody please correct me
if I'm wrong here, but I would not know that this is doable.  The only
exceptions I know where this *may* work are w32 and AIX, actually only
the latter I believe.

> As far as I understand, lib_LIBRARIES and lib_LTLIBRARIES would be 
> installed into [something like] /usr/local/lib.  The non-installed 
> libraries are created just for convenience during the build process of 
> the application.

Right.

> So
> 1) linking the application against any lib_LIBRARY and noinst_LIBRARY is 
> essentially adding objects from that library into the application;
> 2) linking the application against any lib_LTLIBRARY will insert 
> references into the binary; during runtime dunamic linking will be 
> performed.

More or less, yes.

> Does using noinst_LTLIBRATIES make sense at all?

It is useful to create one larger library from smaller pieces, for
example if you use a recursive Makefile structure and your object files
are created in several build directories: you could have each Makefile
create a convenience archive, and the final step would combine all of
these into a lib_LTLIBRARY.

So in this sense, it's merely a workaround for packages not using a
nonrecursive build.

> Or it is supposed to be used by noinst programs only during the
> package build (i.e. such as unit tests, etc)?

That may be another good use.  Although strictly speaking, you are to
include convenience archives only into libraries, not into programs.

Cheers,
Ralf