On Sun, 16 May 2004, Randy Kobes wrote: > On Sat, 15 May 2004, Stas Bekman wrote: > > > Randy Kobes wrote: > > > On Mon, 10 May 2004, Stas Bekman wrote: > > > > > >>How about a quick workaround as follows: For windows only, > > >>link APR.so statically with all APR/Foo.o and the required > > >>modperl_foo.o and arrange for the bootstrap not to call it > > >>for windows if APR.so is loaded? > > > > > > > > > That sounds good ... > > > > So can you try to tackle that? I guess my latest patch > > won't apply against the current cvs and I'll need to > > re-sync it and resolve collisions. > > I'll give it a go ... So as I'll be current, could you > re-sync it, if it's not too difficult? Alternatively, > if the patch is OK on others (apart from Win32, and > perhaps aix), is it ready to apply, and we'll work > from there?
Well, I don't want to destabilize the tree, we should make a new release pretty soon. I think while you are playing with various solutions you could just check the cvs tree for the day I've posted my second patch and it should apply just fine. Your work is going to be in the xs/APR/APR area, not really touching anything else. If you think it's a problem I'll then try to post an up-to-date patch, but it may quickly become out-of-date in a few days. > > I guess all you need to do is to change > > xs/APR/APR/Makefile.PL to collect all .o files from under > > xs/APR and a few selected src/modules/perl/modperl_xxx.o > > and link them statically with APR.so if under win32. (and > > may be some other platforms too (aix comes to mind)). > > Just so I understand correctly, in this approach we'll have > one (big) APR.so that has collected all the functionality of > the individual APR::* modules (as well as the old APR.so > itself and selected symbols from modperl_xxx.o)? Or does APR > stay essentially the same (with the added symbols from > selected modperl_xxx.o), and then one links each APR::* with > APR.so? I was talking about the former, where APR.so will include all objects in Wrap/APR/*/.o (not .so) and some of src/modules/perl/modperl_xxx.o. 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). 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? __________________________________________________________________ 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]
