Re: Questions on exporting functions from a shared library

[Jef Driesen]

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
> whatever.)
>
> 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:
> >
> > mylib_abc
> > #ifdef MYLIB_XYZ_SUPPORT
> >     mylib_xyz
> > #endif
>
> 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)
#else
  #define FXEXPORT __attribute__ ((visibility("default")))
  #define FXIMPORT __attribute__ ((visibility("default")))
#endif

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)

#define FXAPI FXEXPORT

2b. Shared library (linking against it)

#define FXAPI FXIMPORT

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 Makefile.am. 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?

[1] http://gcc.gnu.org/wiki/Visibility