[Top][All Lists]

[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:41:15 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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


reply via email to

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