At 7:16 PM +0200 5/5/04, Ron Blaschke wrote:
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.

Yeah, options like this are available on a number of platforms. It's probably the right answer since it puts the declaration right with the function itself, but there's the issue of pulling it out, since we'll need to preprocess the code on most platforms.


If you're up for the perl trickery needed (or, I suppose, the parrot trickery if you're feeling adventuresome :) we can do this. Until we've got something, though, I think we're going to want to stick with a separate file so there's only one thing to manage rather than two.
--
Dan


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk

Reply via email to