At 10:24 PM 4/13/2001 +0100, Nicholas Clark wrote:
>On Fri, Apr 13, 2001 at 04:05:05PM -0400, Dan Sugalski wrote:
> > Okay, I think we're talking at cross-purposes at the moment.
> >
> > There are exactly 6 things that need prefixes added:
> >
> > 1) Functions that are explicitly exported as part of the API
> > 2) Functions that are internal only, but we can't stop being exported
> > because lots of linkers suck
> > 3) Global data that we export. (If any)
> > 4) Global data we can't not export. (For the same reason as #2)
>
> > Classes 2 and 4 need our "internal" prefix, and only because so many
> > linkers are dead-stupid and won't let us restrict what functions and data
> > we export. Having convenience prefixing macros is fine with me for
> > these--we're adding them because we're forced to, and I don't see any
> > reason to be inconvenienced because of stupid linkers.
>
>Presumably there are internal functions that aren't part of the public
>API, but because they are used in more than 1 source file do need external
>linkage.
They really don't, which is the annoying bit. (Hence the hack) The object
files need to mark the routines as external, but the linked shared library
doesn't. We just can't do that a lot of places.
>Or were your "linkers are dead-stupid" words meaning that we can't tell
>linkers to partially link libperl.a and then declare a whole bunch of
>symbols that now can't be used for any purpose external to libperl.a
Something like the latter. Basically when we're building libperl.so (or,
rather, libparrot.so... :) we really ought to export only a very few
symbols. Unfortunately most Unix linkers I know of don't do that--they all
get exported, like it or not. (I see from the man page for gnu's ld that
you can get around that, but it has problems in other ways)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
