On Tue, 4 May 2004 08:34:55 -0400, Dan Sugalski wrote:
> Another todo list task for the interested. A perl & linker thing.
>
> Right now, through the wonders of the Unix default linking
> conventions, every function in parrot gets exported whether we want
> them to be or not, and generally we don't. That needs fixing.
>
> The right way to fix this is to have a file with the acceptable
> exportable symbols and a fix to the link stage to convince the linker
> that it should *only* export these symbols.
>
> Shouldn't be tough--the linker's quite capable of doing this if
> kicked hard enough, and the export list is actually required on a
> number of systems.
Windows requires this export list, which is currently stored in the
"module-definition file" libparrot.def. However, Windows provides a
"nicer" way of doing this, by prefixing a declaration with
__declspec(dllexport) someFunction
Windows then stores this information in the object file, and thereby
passing the inforation on to the linker.
So, here's my suggestion:
- Define something like PARROT_API to tag a symbol for export, eg
PARROT_API
Parrot_some_function
- Use "compiler magic" for every platform that supports it, eg for Windows
that would be
#ifdef PARROT_EXPORTS
#define PARROT_API __declspec(dllexport)
#else
#define PARROT_API __declspec(dllimport)
#endif
(PARROT_EXPORTS need to be declared during compilation of libparrot, but
undefined during building against libparrot.)
- For those that don't have such an extension, extract the
PARROT_API
Parrot_some_function
declarations and store them in a suitable format for that platform.
Ron
