Stas Bekman <[EMAIL PROTECTED]> [21-11-2004 17:41]: > Radoslaw Zielinski wrote: [...] >> So, as it's a p5p problem, I'll just switch to annoying them with perlbug. [...] > You mean you want to suggest to make it a core feature of perl?
I'm not sure how do you define a "core feature"... I want to show
a problem (breaking the binary compatibility) and suggest a solution.
>>> 2) DynaLoader.a is statically linked with mod_perl.so, therefore every
>>> time you upgrade perl you need to rebuild mod_perl (which is not the only
>>> reason).
>> I'm sure this particular problem is resolvable [1], but could you tell
>> me more about the other reasons?
> In order to load a shared library .so, one needs to load DynaLoader first,
> but since DynaLoader has its own .so lib, it's a chicken and egg problem.
> Therefore all embeded perl apps link statically against DynaLoader.a
DynaLoader doesn't have a *.so lib, only *.a and *.pm (at least on my
system):
$ locate DynaLoader |grep /usr/lib
/usr/lib/perl5/5.8.6/athlon-pld-linux-thread-multi/auto/DynaLoader
/usr/lib/perl5/5.8.6/athlon-pld-linux-thread-multi/auto/DynaLoader/DynaLoader.a
/usr/lib/perl5/5.8.6/athlon-pld-linux-thread-multi/auto/DynaLoader/autosplit.ix
/usr/lib/perl5/5.8.6/athlon-pld-linux-thread-multi/auto/DynaLoader/dl_expandspec.al
/usr/lib/perl5/5.8.6/athlon-pld-linux-thread-multi/auto/DynaLoader/dl_find_symbol_anywhere.al
/usr/lib/perl5/5.8.6/athlon-pld-linux-thread-multi/auto/DynaLoader/dl_findfile.al
/usr/lib/perl5/5.8.6/athlon-pld-linux-thread-multi/auto/DynaLoader/extralibs.ld
/usr/lib/perl5/5.8.6/athlon-pld-linux-thread-multi/DynaLoader.pm
But what I was aksking: what are the other reasons you mentioned for
rebuilding mod_perl after perl upgrade?
>> Why do I care: we're about to freeze PLD; if it's to be a stable,
>> production-ready code base, it means I shouldn't include newer perls
>> in the updates, or I'd break peoples hand-crafted mod_perl builds...
> Normally DynaLoader is not updated, so it's usually not a problem. Though
Well, it is in 5.8.6-rc1 and was at least once more (5.8.3?) in the
5.8.x line.
> if you create a correct dependency between the DynaLoader version and
> mod_perl (and any other embed perl apps) you shouldn't have a problem.
Oh well, I did that yesterday, searching for affected applications, and
adding "Requires: perl(DynaLoader) = %(perl -MDynaLoader -e 'print
DynaLoader->VERSION)" to the *.spec files. A friend laughed at me to
wash my hands after digging this shit, when he saw what I'm doing.
But I also want to support hand-made builds (people may not like the way
we distribute apache and mod_perl) and (maybe) propietary applications
embedding perl, not only my extra-tuned RPMs.
>> [1] For example: since all embedded perl application link with -lperl,
>> the libperl.so itself could be linked with DynaLoader.a, so
>> applications wouldn't have to; other benefits: smaller apps,
>> smaller /usr/bin/perl (also appears to contain DynaLoader.a code).
> I suppose so, but I haven't tried that, so I can't tell whether this will
> be easy.
I'm in the middle of patching Makefile.SH right now. Almost works:
$ LD_LIBRARY_PATH=$PWD ./perl
./perl: symbol lookup error: ./perl: undefined symbol: boot_DynaLoader
;->
[...]
>>> eval_pv("require DynaLoader;", TRUE);
>> [...]
>> Thanks. BTW, while I was getting this code to build, the line above
>> caused a core dump when I invoked: "./my_embperl non-existing-file.pl".
> well, it wasn't a real code, just a proof of concept. Email me offlist if
> you want to see a real program (I've a few small test programs that embed
> perl)
Thanks, I've seen a real program before... ;-)))
--
Radosław Zieliński <[EMAIL PROTECTED]>
[ GPG key: http://radek.karnet.pl/ ]
pgptTG6gTwkwJ.pgp
Description: PGP signature
