[Top][All Lists]

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

Re: Shared library - static link specific dependency

From: Alon Bar-Lev
Subject: Re: Shared library - static link specific dependency
Date: Sat, 14 Jun 2008 13:01:39 +0300

On 6/14/08, Ralf Wildenhues <address@hidden> wrote:
> * Alon Bar-Lev wrote on Sat, Jun 14, 2008 at 11:36:03AM CEST:
> > On 6/14/08, Ralf Wildenhues <address@hidden> wrote:
>  > >  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 may not understand what you write.
>  >
>  > As far as I understand, if I have PKCS#11 provider (library) with
>  > OpenSSL linked within it, and application loads it, there is not
>  > symbol mixups, as the symbols of embedded OpenSSL implementation are
>  > not exposted to the application.
> How do you ensure that (portably)?
>  > And as the interface between
>  > application and the library does not share any OpenSSL related
>  > element, it should work perfectly even if the application load
>  > incompatible OpenSSL library.
> As I don't know your package, I assume this may be realized somehow.
>  My point is: it is not possible to realize this fully portably, but
>  what's more, on unixoid systems it typically requires both action on
>  your part (default to symbol hiding), and it requires that the library
>  in question (here: OpenSSL) not have some unique state that must not
>  exist more than once in the final loaded code.
>  Does that make sense?

You know much more than, so I take your word that it may add some issues.

Thank you for this discussion.

reply via email to

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