[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: Mon, 22 Sep 2008 12:14:30 +0200
User-agent: Thunderbird (X11/20080724)

Brian Dessent wrote:
Jef Driesen wrote:

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.

They have to relink *if* they linked to functions in your DLL by ordinal
and not by name.  (Or in other words, using __declspec(dllexport) does
not guarantee that the order that ordinals are assigned is stable, it
might change based on the order that the linker sees object files or

I don't see how this really matters in real life unless you expect to
support "goober" programmers that do weird things.  So yes, MS has to
forever keep the ordinals stable on system DLLs because someone figured
out one day that by linking their app to Windows DLLs by ordinal instead
of by name they could shave off a few ms in startup time, never mind the
consequences.  But do you have to support that?  I'd hope not.  Most
everybody imports functions by name.

I didn't even know about the possibility to link by ordinal. I don't need to support that.

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

I think on systems that support ELF visibility, libtool uses an
anonymous version map to implement -export-symbols.  (There was a recent
thread on this somewhere, I don't remember.)

On my linux system (Ubuntu 8.04), the symbols list is used to generate a version map. On Windows (mingw32), a DEF file is generated from it. That makes the -export-symbols option easy to use on both systems, without the need for a lot of platform specific stuff.

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


But it's still two places where you have to maintain it, i.e. adding a
new function means adding it to the header and adding it to the
proto-.def file.  My point was more that using declaration macros keeps
that information tied to the prototype so that it's impossible to get
out of sync, e.g. accidently neglecting to export a public function.

True, but the -export-symbols option seems a lot easier to use. At least I can't figure out the necessary macro magic to make the attributes work in an easy to use way.

Suppose, I follow the step by step guide in the GCC Visibility wike page [1] and declare this in a global header file (omitting the check for gcc visibility support):

#ifdef WIN32
  #define FXEXPORT __declspec(dllexport)
  #define FXIMPORT __declspec(dllimport)
  #define FXEXPORT __attribute__ ((visibility("default")))
  #define FXIMPORT __attribute__ ((visibility("default")))

When compiling or linking against the library there are now three cases:

1. Static library (both building and linking)

#define FXAPI

2a. Shared library (building it)


2b. Shared library (linking against it)


Now the documentation suggest to define a "FOXDLL" macro to distinguish between the static and shared library. But on my linux system, libtool build (by default) both a static and shared library. So it seems I can't pass this flag automatically from within my How can I make this work?

Distinguishing between 2a and 2b, seems easier to do without breaking anything, since on win32 libtool defines DLL_EXPORT, and PIC on linux.

And how about gcc < 4.0 that do not support the visibility attributes? Is there a way to hide non-public symbols? Is the version script still available in this case? Is it possible to use both the attributes and the -export-symbols together?


reply via email to

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