Randy Kobes wrote: [...]
I'm not sure how can you go with the latter idea. I mean, I'll work perfectly fine without mod_perl. But how is it going to work under mod_perl, when both mod_perl.so and APR.so will have the same symbols, and according to your suggestion, both will be loaded (since APR/Foo.so will be linked against APR.so).
In this approach I don't there's a problem on Windows with linking against libraries with the same symbols; depending on the order of the libraries in the link command, VC++ will resolve the symbols not found in the object files in the 1st library file it finds that has them (which then registers the corresponding .so, if it's a shared library), so any identical symbols in a later library used in the link command are ignored. Thus, you could in principle build an application linked against two dlls that have the same symbols in them and there shouldn't be a conflict, as the application knows, from how it was linked, which dll each symbol comes from.
That's excellent. So you link APR/Foo.so against APR.so which contains the minimal amount of modperl_xxx.o in it which is already provided by my patch (you only need to arrange linking against APR.lib instead of mod_perl.lib). APR/Foo.pm then must make sure that APR.pm (and so APR.so) are loaded before it loads its own APR/Foo.so. But this could be done later, for now let's say that we do it manually, by doing
PerlModule APR
immediately after
LoadModule mod_perl.so
Now the question is, whether the same could work for all other platforms. I was sure that's it's not possible to load two objects with the same symbols, but I could be wrong. Do you know whether this is true for all platforms?
However, this also means that no symbols can be resolved through mod_perl.lib, as this would require loading mod_perl.so (unless one used the -delayload link option, to load the dll only if a symbol is invoked).
That's perfectly fine.
It would have worked perfectly if we could also link mod_perl.so against APR.so and not include those symbols in mod_perl.so. Which is probably the best solution possible. The problem is that the loaded will somehow have to find APR.so when trying to load mod_perl.so. This could have been done by installing APR.so along with libapr.so I suppose. In that case we will have APR a totally autonomous systems and mod_perl will use it. May be it makes perfect sense, but I haven't thought of the implications for users.
It should be relatively straightforward to do the latter (as long as APR.so is built before APR::*). However, with the former, there'd be problems building the individual APR::* modules first, to be used as components in building APR.so, for the same reason that exists now - to build APR::*, one has to specify the library where the symbols are found, and one can't specify a library (APR.so) that hasn't been built yet.
But I was talking about building .o objects, not shared libs. and linking those .o objects with APR.so. Will that be a problem too? AFAIK you never need to provide information about shared libs, during compilation time. Is that different on windows?
No, you're right - resolving all symbols only is required at link time, so this could be done by just compiling (with -c) the APR::* files to build the object files, and skip building the associated APR::* dlls, as is done now.
I think things are becoming clearer to me - thanks. It looks like most of this can be done by fiddling with the compiling/linking commands, without the need (hopefully) of any source code modifications. I'll try it and see.
Correct. I think your suggestion at the top is much better that dumping all .o into APR.so. If it works for every platform then we are gold.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
