Re: [xml] [patches] static linking on win32 with static cruntimes

[Joel Reed <joelwreed comcast net>]

snip

> > also, while on topic of APIs, the fact that extension registeration
> > functions don't take the hash to register the extension in as an 
> > argument, but instead register to global xmlHashes means folks wanting
> > to using plugins MUST dynamically link libxslt into the plugin.
> > would we ever want to fix that? not sure...
>
>   I'm not sure I understand :-)

sorry, let me try again. so a plugin init function looks like this:

void EXSLTPUBFUN exslt_org_regular_expressions_init (void)
{
    xsltRegisterExtModuleFunction ((const xmlChar *) "match",
                                   (const xmlChar *)
                                   EXSLT_REGEXP_NAMESPACE,
                                   exsltRegexpMatchFunction);
}

xsltRegisterExtModuleFunction in libxslt/extensions.c adds
exsltRegexpMatchFunction to xsltFunctionsHash which is a global
variable.

now imagine xsltproc and exslt_org_regular_expressions.so, each
statically linking to libxslt. each has a xsltFunctionsHash now.
if they were both dynamically linked to libxslt, there'd be only
one xsltFunctionsHash.

so given the current API, exslt_org_regular_expressions.so ends
up adding a new entry into its xsltFunctionsHash, and not
the right one -> which is xsltproc's xsltFunctionsHash.

it seems that one way to fix this would be to pass some context
ptr to plugin init funcs, that would then just be passed along
in some new xsltRegisterExtModuleFunction that besides the params
above, also took a context pointer, and that in the implementation
of this new func, exsltRegexpMatchFunction would be added not to 
some global xsltFunctionsHash, but to context->xsltFunctionsHash.
thereby fixing the issue with statically linked xsltproc's and plugins.

whether this has other benefits, or is just too much change for
a small set of users/configs i'm not sure. just describing how
i think we could make it work.

jr