You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Radoslaw Zielinski <ra...@karnet.pl> on 2004/11/19 13:44:57 UTC
DynaLoader's "special case"
Each time I upgrade perl and the DynaLoader's version changes, I have to
rebuild mod_perl, or I'll get this error:
DynaLoader object version 1.05 does not match $DynaLoader::VERSION 1.06
It happens when I add "PerlModule AnyXSmodule" to my httpd.conf (of
course any more complicated thing, like adding a handler or a <perl>
section also triggers it). The module itself of course works just fine
outside mod_perl.
I finally found some time to dig the issue; when I grepped out the
src/modules/perl/modperl_xsinit.c: /* DynaLoader is a special case */
line I knew I'm home... ;-) The problematic call is:
newXS("DynaLoader::boot_DynaLoader", boot_DynaLoader, file);
It's triggered in mod_perl.c::modperl_xs_init(), for whatever reason.
DynaLoader.pm contains:
boot_DynaLoader('DynaLoader') if defined(&boot_DynaLoader) &&
!defined(&dl_error);
When I test it from the command line, the &dl_error is always defined,
so I think on my system the condition is always false.
My question is: what's the point of that newXS() call? Can it be done
in any other way?
--
Radosław Zieliński <ra...@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
Re: DynaLoader's "special case"
Posted by Radoslaw Zielinski <ra...@karnet.pl>.
Stas Bekman <st...@stason.org> [21-11-2004 18:24]:
> Radoslaw Zielinski wrote:
>> Stas Bekman <st...@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.
> To have the functionality of Dynaloader.a be built-in in libperl.(so|a)
Then yes. Since it's in /usr/bin/perl anyway, it's not a big revolution.
[...]
>> 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
[...]
Ah, then fine. Build options are under my control; I thought that maybe
mod_perl is using some weird perl features, not covered by the backward
compatibility policy.
[...]
>> 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?
And I need a complex solution, so I patched that Makefile.SH.
[...]
Bug #32539 it is.
--
Radosław Zieliński <ra...@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
Re: DynaLoader's "special case"
Posted by Stas Bekman <st...@stason.org>.
Radoslaw Zielinski wrote:
> Stas Bekman <st...@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.
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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: DynaLoader's "special case"
Posted by Radoslaw Zielinski <ra...@karnet.pl>.
Stas Bekman <st...@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 <ra...@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
Re: DynaLoader's "special case"
Posted by Stas Bekman <st...@stason.org>.
Radoslaw Zielinski wrote:
> Stas Bekman <st...@stason.org> [19-11-2004 21:41]:
>
>>Radoslaw Zielinski wrote:
>>
>>>Each time I upgrade perl and the DynaLoader's version changes, I have to
>>>rebuild mod_perl, or I'll get this error:
>>> DynaLoader object version 1.05 does not match $DynaLoader::VERSION 1.06
>
> [...]
>
>>1) You need to have DynaLoader loaded before anything else, so you can
>>load .so Perl extensions. That's why you see all those things. more
>>explanation below.
>
>
> That's what I thought, but then gaim's perl plugins feature misleaded me
> (it just works without rebuilding and uses similar code; I failed to
> find out what's the difference).
>
> So, as it's a p5p problem, I'll just switch to annoying them with perlbug.
> Sorry for blaming mod_perl too fast and thanks for the info. ;-)
You mean you want to suggest to make it a core feature of perl?
>>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
> 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
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.
> [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.
For the future it's probably the best for perl to include that
functionality internally. It's probably a good idea to ask at p5p, why its
functionality was "sourced out" to an external module.
>>if you ever write an embedded perl app, which needs to load .pm files with
>>.so extensions, you need to write:
>
> [...]
>
>> 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)
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: DynaLoader's "special case"
Posted by Radoslaw Zielinski <ra...@karnet.pl>.
Stas Bekman <st...@stason.org> [19-11-2004 21:41]:
> Radoslaw Zielinski wrote:
>> Each time I upgrade perl and the DynaLoader's version changes, I have to
>> rebuild mod_perl, or I'll get this error:
>> DynaLoader object version 1.05 does not match $DynaLoader::VERSION 1.06
[...]
> 1) You need to have DynaLoader loaded before anything else, so you can
> load .so Perl extensions. That's why you see all those things. more
> explanation below.
That's what I thought, but then gaim's perl plugins feature misleaded me
(it just works without rebuilding and uses similar code; I failed to
find out what's the difference).
So, as it's a p5p problem, I'll just switch to annoying them with perlbug.
Sorry for blaming mod_perl too fast and thanks for the info. ;-)
> 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?
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...
[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).
> if you ever write an embedded perl app, which needs to load .pm files with
> .so extensions, you need to write:
[...]
> 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".
--
Radosław Zieliński <ra...@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
Re: DynaLoader's "special case"
Posted by Stas Bekman <st...@stason.org>.
Radoslaw Zielinski wrote:
> Each time I upgrade perl and the DynaLoader's version changes, I have to
> rebuild mod_perl, or I'll get this error:
> DynaLoader object version 1.05 does not match $DynaLoader::VERSION 1.06
>
> It happens when I add "PerlModule AnyXSmodule" to my httpd.conf (of
> course any more complicated thing, like adding a handler or a <perl>
> section also triggers it). The module itself of course works just fine
> outside mod_perl.
>
> I finally found some time to dig the issue; when I grepped out the
>
> src/modules/perl/modperl_xsinit.c: /* DynaLoader is a special case */
>
> line I knew I'm home... ;-) The problematic call is:
>
> newXS("DynaLoader::boot_DynaLoader", boot_DynaLoader, file);
>
> It's triggered in mod_perl.c::modperl_xs_init(), for whatever reason.
> DynaLoader.pm contains:
>
> boot_DynaLoader('DynaLoader') if defined(&boot_DynaLoader) &&
> !defined(&dl_error);
>
> When I test it from the command line, the &dl_error is always defined,
> so I think on my system the condition is always false.
>
> My question is: what's the point of that newXS() call? Can it be done
> in any other way?
1) You need to have DynaLoader loaded before anything else, so you can
load .so Perl extensions. That's why you see all those things. more
explanation below.
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).
--------
if you ever write an embedded perl app, which needs to load .pm files with
.so extensions, you need to write:
#include <EXTERN.h>
#include <perl.h>
EXTERN_C void xs_init (pTHX);
EXTERN_C void boot_DynaLoader (pTHX_ CV* cv);
EXTERN_C void
xs_init(pTHX)
{
char *file = __FILE__;
dXSUB_SYS;
/* DynaLoader is a special case */
newXS("DynaLoader::boot_DynaLoader", boot_DynaLoader, file);
}
int main(int argc, char **argv, char **env)
{
[...]
perl_construct(perl);
perl_parse(one_perl, xs_init, 3, embedding, (char **)NULL);
/* DynaLoader must be preloaded before perl_clone, if DynaLoader
* is to be required later */
eval_pv("require DynaLoader;", TRUE);
now you can continue loading other things.
See perlembed.pod for more info.
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org