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.
To have the functionality of Dynaloader.a be built-in in libperl.(so|a)
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):
Yes, sorry, it can't have .so precisely for the explained reason.
But what I was aksking: what are the other reasons you mentioned for rebuilding mod_perl after perl upgrade?
You mean unrelated to the Dynaloader issue? Usually the main reason is that a new perl might be slightly built slightly different. I'm not talking about the binary compatibility, which for example all 5.8.x series preserve (well, almost, 5.8.1 wasn't the case). I'm talking about things like, linking against a different library (statically or dynamically) e.g. libdb or libgdbm, or not linking against it. Using a different compile option, extending @INC and more. So as long as the upgraded perl is exactly the same, there should be no need to upgrade mod_perl. But many times this is not the case. You can find plenty of examples in the mailing list archives, posted over the last 8 years.
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.
Right, but the dependency rule should have handled that.
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.
Welcome to the club, Radoslaw.
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.
and?
[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
;->
:)
It's probably the best to rework it to replace .xs files with .c and have it be part of libperl.so. But I suppose this won't happen in 5.8.6. Ask at p5p though.
-- __________________________________________________________________ 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]
