On 6/14/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Alon Bar-Lev wrote on Sat, Jun 14, 2008 at 11:36:03AM CEST: > > > On 6/14/08, Ralf Wildenhues <[EMAIL PROTECTED]> 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. Alon. _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool