On 16.06.09 19:25:36, Michael Leong wrote: > > > > > 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.
Please post the output you get, in particular its interesting wether the undefined symbols are missing in code thats part of the executable or part of the library. Also I suggest to run nmake VERBOSE=1 (if you're using nmake generator) to see the actual compiler calls that cmake uses to compile the library and the executable and check wether the ssl-libs are really put into the library or not. > > > 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. I meant that the exported symbols of your library must not have datatypes from openssl in their signature. Andreas -- You have an unusual magnetic personality. Don't walk too close to metal objects which are not fastened down. _______________________________________________ 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
