Re: Questions on exporting functions from a shared library

[Brian Dessent]

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

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

Brian