Re: Questions on exporting functions from a shared library

[Jef Driesen]

Brian Dessent wrote:
> Jef Driesen wrote:
>
> > What are the (dis)advantages of each method? I see differences in usage
> > (see below), but are there technical differences as well?
>
> It sounds like you already are aware of all the tradeoffs.  I don't
> think there's a technical difference in the end, i.e. the results are
> the same assuming that you mark the same set of functions.

The MSDN documentation [1] about this issue, gives me the impression 
that applications have to relink when new symbols are added to the 
library (when not using a DEF). And that's something I would like to 
avoid. Actually this statement surprises me, so I'm probably just 
misunderstanding the explanation there.

http://msdn.microsoft.com/en-us/library/900axts6(VS.80).aspx

> Having to worry about disabling the declspec attributes when
> building/using the static version of the library is not that big a
> deal.  If you're using libtool you can already get this for free because
> libtool always adds -DPIC even on Win32/PE where there is no meaningful
> -fPIC, so you can just gate on that.  If you're not using libtool you
> can just make up something, e.g. just document that users need to use
> -DMYLIB_STATIC when they want to use the static version of your lib,
> otherwise default to shared.

I never noticed the -DPIC. In most of the documentation -DDLL_EXPORT is 
mentioned. The effect is the same of course :-)

The only remaining "problem" is that (I think) libtool can sometimes 
automatically decide to use the static library instead of the shared 
library. (For instance when building a dll on win32 without specifying 
-no-undefined.) I assume that in this case building (the project using 
my library) won't work anymore, because the -DMYLIB_STATIC was not defined?

> If you care about limiting the exported interface you should care about
> symbol visibility for ELF systems too.  And once you have the declspec
> macros set up it's not hard to simply hook into that for ELF visibility
> as well.  There are some examples at
> <http://gcc.gnu.org/wiki/Visibility>.

One of the reasons I care about this stuff, is that the msvc compiler 
does not export any symbols without a DEF file or declspec. So I need to 
use one of them anyway.

I already noticed that page about ELF visibility. But I still do not 
understand what it does more than libtool's -export-symbols.

> IMHO, these are all reasons why you should go with the declspec method
> and ditch the .def file.  Having to keep things in sync in two separate
> places is always extra work, plus the additional kludge of having to
> jump through preprocessor hoops to maintain it sounds like a real pain.

The preprocessor stuff is automated. I only have to maintain a symbols 
file with a few #ifdef's in it:

mylib_abc
#ifdef MYLIB_XYZ_SUPPORT
   mylib_xyz
#endif

And in the makefile, there is a rule that runs this file through the C 
preprocessor before passing it to libtool's -export-symbols. (I borrowed 
that idea from gtk+.)