[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions on exporting functions from a shared library

From: Jef Driesen
Subject: Re: Questions on exporting functions from a shared library
Date: Thu, 18 Sep 2008 17:36:43 +0200
User-agent: Thunderbird (Windows/20080708)

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.

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

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:


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]