The Schizophrenic Parrot
Ron Blaschke
1) Missing exported symbols
If the powers that be give me a sign how it should be done, I'll
gladly implement it.
What do people think of my previous proposal? Is it any good?
"
How about this: We separate things into 2 steps.
1) Create a .sym file for each relevant compilation unit(s).
2) Join the .sym files for all to-be-linked objects and create the
.def file. (on Windows)
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).
"
2) Static linkage
Dynclasses are currently statically linked against libparrot.lib,
thereby using their own (uninitialized) parrot.
Ron
Leopold Toetsch
> 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.
> 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.
> Ron
leo
Ron Blaschke
> Ron Blaschke <mailin...@rblasch.org> 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
Leopold Toetsch
> Leopold Toetsch wrote:
>> 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.
> 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.
First question is: should it be contained in 0.1.2?
But these changes can't be done before Dan's string changes are merged
to CVS HEAD.
And WRT patches: please provide separate patches per subsystem - roughly
the structure of the html docs' c.html.
leo
Ron Blaschke
>> 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).
> First question is: should it be contained in 0.1.2?
> But these changes can't be done before Dan's string changes are merged
> to CVS HEAD.
That's fine with me. I'll just wait until the more important things
are in place before I start.
I guess there is no need to rush the changes into a 0.1.2.
> And WRT patches: please provide separate patches per subsystem - roughly
> the structure of the html docs' c.html.
Alright.
Thanks,
Ron