Re: Shared library - static link specific dependency

[Alon Bar-Lev]

Thank you for explaining this.
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.

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.

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.

Alon.

On 6/14/08, Ralf Wildenhues <address@hidden> wrote:
> Hello Alon, and sorry for the delay,
>
>  * Alon Bar-Lev wrote on Fri, Jun 06, 2008 at 09:15:37AM CEST:
>
> > >  > I want to make a shared library without dependencies. I compile the
>  > >  > dependencies in PIC mode, so it should be compatible.
>
>
> > Let's say I have liba.la pointing to liba.so* and liba.a(pic)
>  > installed in my system. I am not building this right now.
>  > Now, I would like to create moduleb.so that use liba but I do not want
>  > to have external dependency of liba.so*.
>
>
> Ah, ok.  Libtool doesn't really support this.  Well, only with
>  convenience archives, but not with installed stuff.  Here's why:
>
>  The general idea is that you should not have multiple entities
>  of the same code in different libraries, as this can lead to
>  subtle and difficult-to-analyze bugs.  Either your libraries are
>  shared (and its dependencies are, too), or your libraries are
>  static, and their code will end up in the final program (but not
>  in other libraries depending on it).  This is how libtool handles
>  shared libraries and shared modules, and also how it handles
>  static libraries and dlpreopened modules.  Of course the latter
>  only work with libltdl.
>
>  This is also the reason why installing convenience archives is
>  discouraged: it makes it easy to end up with code being duplicated
>  into several libraries.
>
>  (I suppose you could hack around this by manually copying
>  libconvenience.la and $(LT_OBJDIR)/libconvenience.a into some installed
>  location, and use that later; but again, be warned).  Maybe libtool
>  should support this (I think it did at one point in the past), but add a
>  big fat warning sign.  Hmm.
>
>  Cheers,
>
> Ralf
>