libtool
[Top][All Lists]
Advanced

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

Re: Shared library - static link specific dependency


From: Ralf Wildenhues
Subject: Re: Shared library - static link specific dependency
Date: Sat, 14 Jun 2008 11:27:16 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

* Alon Bar-Lev wrote on Sat, Jun 14, 2008 at 11:08:47AM CEST:
> I still don't understand why the developer cannot make the decision if
> it is proper or not.
> The -static-libtool-libs can be used for this as-well. If it absent
> (default) current behavior apply, but if it is specify on shared
> library then it should behave consistently with executable.

But programs are (conceptually) different in this respect from
libraries: you cannot generate entities which are derived from
programs.  This means that, whether they incorporate some code
from a static library, or link against some shared library,
doesn't cause future breakage for files that haven't already
entered the dependency tree.

> It is usable when you want to provide a library to target with low
> space, and your library use a dependency and you don't want the whole
> .so be needed at target.

Understood.

> Or we have in OpenSC issue with Windows, we would like the PKCS#11
> provider (dll) to be without certain dependencies, so that it may be
> loaded to application with incompatible OpenSSL reference.

Understood as well.

These cases sound like small optimizations that have the potential to
break things later on for third-party packages using your libraries,
if they are not very careful.  That's the reason for making it hard to
realize in your packages.  Example:

I would like to create a program that links against your PKCS#11
provider DLL, and for some reason, I also need to link against OpenSSL
or some other library from which you have put code into the DLL.
If I understand your example above correctly, then I can get into
trouble with symbol mixups caused by that.  This would not happen,
had you linked against the OpenSSL/other DLL in the first place.

I hope this helps somehow.  I'm not sure how to make this any clearer.

Cheers,
Ralf




reply via email to

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