On Sun, 3 Sep 2000, Gerald Richter wrote:
> From my point of view it doesn't make any sense to have two versions of the
> library, actualy I guess it will not work correctly, because Apache always
> needs the DLL version and the DLL version and the static lib version will
> _not_ share globales, which is neccessary to make mod_perl work.
I had thought this use of a static mod_perl lib was similar
in spirit to what Matt did with AxKit - include all the
*.obj files at link time, but still build mod_perl normally
with a dll. As a test, I tried libapreq again, and found
it was missing 3 symbols from ApacheModulePerl.lib. I then
tried instead linking it in with a static mod_perl lib,
which resolved the missing symbols. After installing, some simple
tests seemed to indicate Apache::Request works OK. However, maybe
this is a bad route in principle? Is it the use of the static
mod_perl lib to resolve things in an external package, together
with mod_perl's subsequent use of the DLL, that could
potentially lead to problems?
>
> What I suggest is just to add some more entries to the symbol table of the
> DLL, makeing this symbols public viewable and thereby, makeing it possible
> that other modules can use them. For the first step it would be the esaiest
> to just creating a DEF file, so you don't have to modifiy any sources, but
> can make the linker happy. In the second step it has to be decided, which
> symbol belongs to the mod_perl API and should be exported by the DLL ( I
> think Doug should take a look at this list), then using the API macros from
> Apache would make it more portable to other platforms.
This sounds like a much more coherent approach - I guess this static
lib approach, if it was OK, might have been useful in the meantime
until these things are decided ... I'll take a stab at seeing
what should be put into the DEF file.
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
