Re: shared library from smaller pieces

[Vlad Skvortsov]

Ralf Wildenhues wrote:

> Hi Vlad,
>
> * Vlad Skvortsov wrote on Wed, Dec 07, 2005 at 06:02:21AM CET:
>  
>
> > And another question: I have a third-party library that I link my 
> > project against. That one is declared (by its author) to be shared. 
> > However, when I build that, I always end up with all both shared 
> > (.so/.dylib) and static (.a) versions of the library.
> >
> > So, when I link my project (all static), the static library is used.
> >    
>
> OK.
>
>  
>
> > But recently, when I've built the shared library inside my project, it 
> > referenced the third-party shared library, instead of including its 
> > contents.
> >    
>
> Well, isn't that what you want?
>
> Look: If somebody happens to link against both your library and the one
> whose code you'd like to also end up in your library, you'll have
> duplicate symbols[1].  So in general, this is not a good idea.
>
>  
>
> > Of course, if that third-party library was mine, I would just change it 
> > from lib_LTLIBRARIES to noinst_LIBRARIES; but that's not the case. What 
> > is the proper way to do that?
> >    
>
> I simply don't understand why you'd want that in the first place.
>  
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?

>  
>
> > What's the difference between noinst_LTLIBRARIES and lib_LIBRARIES?
> >
> > Probably, I'm just confusing shared/static and installed/non-installed 
> > library. I would be happy if you point me to the documentation that 
> > could educate me.
> >    
>
> Hmm, reading the neighboring chapters around the pointers I already gave
> you may help.  But you may have done that already.
>  
Yep.

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

Does using noinst_LTLIBRATIES make sense at all? Or it is supposed to be 
used by noinst programs only during the package build (i.e. such as unit 
tests, etc)?


> Cheers,
> Ralf
>
> [1] At least on some systems, you will have some sort of nasty trouble.
>  


--
Vlad Skvortsov, address@hidden, address@hidden