[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shared library from smaller pieces
Re: shared library from smaller pieces
Fri, 09 Dec 2005 14:46:46 -0800
Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6a) Gecko/20031207
Ralf Wildenhues wrote:
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.
* 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.
But recently, when I've built the shared library inside my project, it
referenced the third-party shared library, instead of including its
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. 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.
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
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.
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
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
 At least on some systems, you will have some sort of nasty trouble.
Vlad Skvortsov, address@hidden, address@hidden
Re: shared library from smaller pieces, Andreas Schwab, 2005/12/04
- shared library from smaller pieces, Vlad Skvortsov, 2005/12/04
- Re: shared library from smaller pieces, Ralf Wildenhues, 2005/12/04
- Re: shared library from smaller pieces, Vlad Skvortsov, 2005/12/04
- Re: shared library from smaller pieces, Ralf Wildenhues, 2005/12/05
- Re: shared library from smaller pieces, Vlad Skvortsov, 2005/12/06
- Re: shared library from smaller pieces, Ralf Wildenhues, 2005/12/07
- Re: shared library from smaller pieces,
Vlad Skvortsov <=
- Re: shared library from smaller pieces, Ralf Wildenhues, 2005/12/12
- Re: shared library from smaller pieces, Vlad Skvortsov, 2005/12/15
- Re: shared library from smaller pieces, Ralf Wildenhues, 2005/12/16
- Re: shared library from smaller pieces, Vlad Skvortsov, 2005/12/20