[ODE] Why no __declspec(dllexport)

[Jon Watte]

> This is probably a silly questionm, but how to non-microsoft compilers 
> know that a function is to be exported from within a Shared Object/DLL ( 
> for example )?

That depends on the linkage model.

For example, on ELF/UNIX, everything is exported (although you can hide 
things in the symbol table if you really want to).

Note that on most models, "importing" a symbol from a DLL is no different 
from importing a symbol from a static library. Only on Windows, with its 
DOS-era shared library system, do you need an "import library" which 
under the covers loads the DLL library and patches up a jump table. On 
most other systems (Linux, MacOS, BSD, AIX, BeOS, etc), the loader will 
resolve shared libraries and patch symbols just like it patches symbols 
for relocation.

Exporting everything that's not "static" is not fine-grained enough, 
because you will likely have classes or globals that are used between 
translation units within a library, but should not be visible outside 
of that library. Here's where the C/C++ language model breaks down; it 
has only a notion of "translation units" and no notion of "modules" 
that is higher than that. And, in fact, it doesn't even specify much 
about linkage (hence this great variation in linkage models).

The major exception is the XCOFF/PEF model used by AIX and Mac Toolbox; 
here, you have to #pragma export to mark symbols for export (or use an 
export list) else they're hidden. However, the loading still is done by 
the loader, not by some magic import library.

Also, when you link against a shared library, and sometimes when you just 
dlopen() a shared library, the UNIX/ELF model will merge the symbol 
tables, so it's not clear whose "malloc()" you'll be getting. This is 
good for overriding specific symbols, but it's really bad for testability, 
because you CAN'T KNOW what symbols you'll end up getting in the future, 
or on another machine.

The Windows and XCOFF/PEF format allow you full control over where your 
symbols are coming from. They also promise never to pollute your symbol 
table with arbitrary objects at load or run time. Overall, I think this 
is a stronger approach, and I especially like the XCOFF/PEF method of 
tieing symbols to specific libraries, and explicitly exporting, but to 
let the loader do the resolution, rather than using the Windows-style 
import library.

Martin> > This stuff is there because it genuinely makes life much easier on us.
Martin> I've never heard anyone on Linux, Solaris or IRIX complain about 
Martin> the lack of it.

Well, now you have! Maybe people on Linux, Solaris and IRIX don't care 
about being able to deploy tested binaries to a diverse system flora.

Of course, I've glossed over lots of details, so don't go writing any 
tools without an actual specification in front of you :-)

Cheers,

			/ h+