[CMake] Creating a dynamic library with a static library hidden inside

[Michael Leong]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090616/b0fa829c/attachment.htm>