[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 2.0.0.16 (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.
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+.)
- Questions on exporting functions from a shared library, Jef Driesen, 2008/09/18
- Re: Questions on exporting functions from a shared library, Brian Dessent, 2008/09/18
- Re: Questions on exporting functions from a shared library,
Jef Driesen <=
- Re: Questions on exporting functions from a shared library, Brian Dessent, 2008/09/19
- Re: Questions on exporting functions from a shared library, Ralf Wildenhues, 2008/09/19
- Re: Questions on exporting functions from a shared library, Jef Driesen, 2008/09/22
- Re: Questions on exporting functions from a shared library, Brian Dessent, 2008/09/22
- Re: Questions on exporting functions from a shared library, Jef Driesen, 2008/09/23