|
From: | Vlad Skvortsov |
Subject: | Re: shared library from smaller pieces |
Date: | Fri, 09 Dec 2005 14:46:46 -0800 |
User-agent: | 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.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.
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
[Prev in Thread] | Current Thread | [Next in Thread] |