Thanks for the reply, Andreas.
> > > > > > > > 2: The dynamic library's internal openssl functions should not be > > > > externally visible. > > > > > > Not sure if this is possible. If the symbols are in there, someone with > > > dumpbin or some other tool will probably be able to find them. What are > > > you trying to do? Why is this requirement important? Also, are there any > > > legal/licensing ramifications of doing this? > > > > > > What problems are you running into? Can't compile dynlib? Can't link an > > > exe with dynlib? > > > > When I run the code, I get a dynamic library named dynlib out, and I > > can use it to link up an executable that uses the functions in there > > and it works fine, but I need to link in the openssl libraries as > > well. The executable doesn't link happily if it's not pointed to > > dynlib and the two static .lib openssl files. > > Can you post the exact errors? Or maybe even a small complete sample > project that reproduces this? When I try to link dynlib.dll into the executable, it complains about a whole load of unresolved external symbols. I recognize them; they're openssl symbols, and the problem goes away and links and runs just fine if I add libeay32.lib and ssleay32.lib as dependencies of the executable. > > > I've checked the legal and licensing issues, and it's ok for this > > situation. What I'm trying to do is make sure the openssl that my > > library uses is not going to conflict with anyone else's openssl > > already installed on the system. I don't want someone to link my > > library, and then call an openssl function and get the openssl I'm > > using. That's just in case they have a different one. > > So basically you want your dynamic lib not export any openssl > symbols, that should just work as long as your dynamic libs own exported > symbols don't reference anything from openssl. Looking around the cmake wiki and all sure made me think it would work great, but that's unfortunately not what I'm experiencing and I'm a little confused. And I'm not sure what you meant by that last sentence. The symbols I export do call openssl functions, but that's the reason I want to have openssl inside the dll I'm making; so it can be a standalone library without having to deal with hassles of users having different versions of openssl floating around. Thanks again. -Michael
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
