[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shared library from smaller pieces

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:

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.


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.

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


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

Vlad Skvortsov, address@hidden, address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]