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
