Leopold Toetsch wrote: > Ron Blaschke <[EMAIL PROTECTED]> wrote: >> Now things boil down to creating the .sym files. These might be >> created by grepping the source for C<nci_>, C<Parrot_>, etc, or >> by whatever script created the compilation unit(s).
> Not everything that starts with Parrot_ is an API (e.g. opcode > functions). I think an explicit macro PARROT_API should denote > exportable symbols. I thought so, too. #31649: [TODO] Win32 - Automatically Export Symbols http://rt.perl.org/rt3/Ticket/Display.html?id=31649 The other solution I proposed is somewhat similar, the exported symbols would be stored along the .obj in a separate file .sym. For that, we could grep for PARROT_API. Generated files (eg by F<ops2c.pl>) could directly generate the .sym file. Or the scripts could annotate the generated files with PARROT_API, for which would be grepped. The combinations seem endless. ;-) If I would be the one to choose, I'd add the C<PARROT_API> macro everywhere, and expand it to C<__declspec(dllexport)> on Windows (no more .def files). I'd also provide a sample script that can be used to get a .sym file (for whoever might need it). I'll gladly implemement any solution you consider best, as Windows is in desperate need for it All I need is a +1 from a comitter, to avoid warnocked patches. >> 2) Static linkage >> Dynclasses are currently statically linked against libparrot.lib, >> thereby using their own (uninitialized) parrot. > Yeah. Linux needed -Wl,-E in LINKFLAGS to convince the linker to do the > right thing. This is somewhat simpler on Windows, as one always specifies a .lib file. It contains either the real thing, or stub code that calls the shared library. Ron
