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

[Andreas Pakulat]

On 16.06.09 14:58:28, Michael Leong wrote:
> > > 1: A dynamic library containing openssl which does not require me to
> > > link in openssl if I want to use it to make an executable.
> >
> > AFAIK what you're doing ought to work. Maybe since this is Windows you
> > need some symbol decoration magic (declspec)?
> 
> I'd really like to get a CMake solution instead of doing some nasty
> decoration magic, because I do need this to work on some unix-like
> systems as well.

Uhm, there cannot be a cmake solution to the declspec stuff, as thats
something thats done on the language side. It doesn't have anything to
do with the buildsystem itself (except that the buildsystem helps you
get the right thing with import vs. export by setting a define when
building a library). However if your dynamic library actually uses
symbols from openssl and it links fine, then at least there's no
declspec-stuff needed - as you don't want to re-export the openssl
symbols from your dynamic libs as far as I understood.
 
> >
> > > 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?

> 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.

Andreas

-- 
Someone whom you reject today, will reject you tomorrow.