perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radoslaw Zielinski <ra...@karnet.pl>
Subject Re: DynaLoader's "special case"
Date Sun, 21 Nov 2004 17:13:12 GMT
Stas Bekman <stas@stason.org> [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 <radek@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]

Mime
View raw message