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

[Andreas Pakulat]

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.