httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [mp2 patch] getting APR to work w/o modperl
Date Mon, 17 May 2004 04:07:56 GMT
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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Mime
View raw message