You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/09/21 03:49:20 UTC
semi-resolved the modperl_bucket_sv_create problem cause
(continuing from the irc discussion here for the archives)
when starting the static modperl/httpd we get:
lt-httpd: symbol lookup error:
/home/stas/apache.org/mp2-static/blib/arch/Apache2/auto/APR/Bucket/Bucket.so:
undefined symbol: modperl_bucket_sv_create
1) APR.so doesn't get loaded when run under apache/mod_perl, so it's
useless to check its symbols.
2)
nm /home/stas/apache.org/httpd-2.0/.libs/lt-httpd | grep modperl_ | wc -l
453
nm /home/stas/apache.org/httpd-2.0/.libs/lt-httpd | grep modperl_bucket |
wc -l
0
Here is your answer: modperl_bucket is not linked into httpd
but:
% nm src/modules/perl/mod_perl.a | grep modperl_buc
modperl_bucket.o:
00000265 T modperl_bucket_sv_create
00000088 t modperl_bucket_sv_destroy
0000012e t modperl_bucket_sv_make
00000000 t modperl_bucket_sv_read
00000060 r modperl_bucket_sv_type
so that means that the linker decides that those symbols aren't used (and
they indeed aren't) and it drops them. I think I've seen that behavior
before. Just to prove that idea, try to use them somewhere (e.g some dummy
function in mod_perl.c).
--
__________________________________________________________________
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: [Patch mp2] ugly_hack ( was : emi-resolved the modperl_bucket_sv_create
problem cause )
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
>
>> Stas Bekman wrote:
>>
>>> [...]
>>>
>>> so that means that the linker decides that those symbols aren't used
>>> (and they indeed aren't) and it drops them. I think I've seen that
>>> behavior before. Just to prove that idea, try to use them somewhere
>>> (e.g some dummy function in mod_perl.c).
>>
>>
>>
>> Exactly, when the target of a link operation is an actual binary, the
>> linker will remove all unused functions. That is not the
>> case with a .so where the linker has no possible way of knowing what
>> might be needed at a later time.
>>
>> So, attached is a patch similar to httpd's ap_hack_* to work around
>> this problem.
>>
>> In a nutshell, create a modperl_exports.c that contains this :
>>
>> const void *modperl_ugly_hack = NULL;
>> const void *modperl_hack_$name = (const void *)modperl_$name;
>> [...]
>>
>> where $name is each and every single public modperl API function.
>>
>> This doesn't even guarantee that the linker won't delete these
>> entries from there, since it
>> will detect correctly that not a single external compilation uint
>> needed any of the symbols
>> in modperl_exports.c. Thus, to create that dependency, in mod_perl.c :
>> const void *modperl_suck_in_ugly_hack(void);
>> const void *modperl_suck_in_ugly_hack(void)
>> {
>> extern const void *modperl_ugly_hack;
>> return modperl_ugly_hack;
>> }
>>
>> And that does create an external link/dependency and the linker keeps
>> all symbols around.
>>
>> As a nice side effect, this might be of some help to people on more
>> esoteric platforms.
>
>
> +1
Now making it's way to a CVS server near you ;-)
Re: [Patch mp2] ugly_hack ( was : emi-resolved the modperl_bucket_sv_create
problem cause )
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> Stas Bekman wrote:
>
>> [...]
>>
>> so that means that the linker decides that those symbols aren't used
>> (and they indeed aren't) and it drops them. I think I've seen that
>> behavior before. Just to prove that idea, try to use them somewhere
>> (e.g some dummy function in mod_perl.c).
>
>
> Exactly, when the target of a link operation is an actual binary, the
> linker will remove all unused functions. That is not the
> case with a .so where the linker has no possible way of knowing what
> might be needed at a later time.
>
> So, attached is a patch similar to httpd's ap_hack_* to work around this
> problem.
>
> In a nutshell, create a modperl_exports.c that contains this :
>
> const void *modperl_ugly_hack = NULL;
> const void *modperl_hack_$name = (const void *)modperl_$name;
> [...]
>
> where $name is each and every single public modperl API function.
>
> This doesn't even guarantee that the linker won't delete these entries
> from there, since it
> will detect correctly that not a single external compilation uint needed
> any of the symbols
> in modperl_exports.c. Thus, to create that dependency, in mod_perl.c :
> const void *modperl_suck_in_ugly_hack(void);
> const void *modperl_suck_in_ugly_hack(void)
> {
> extern const void *modperl_ugly_hack;
> return modperl_ugly_hack;
> }
>
> And that does create an external link/dependency and the linker keeps
> all symbols around.
>
> As a nice side effect, this might be of some help to people on more
> esoteric platforms.
+1
--
__________________________________________________________________
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
[Patch mp2] ugly_hack ( was : emi-resolved the modperl_bucket_sv_create
problem cause )
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> [...]
>
> so that means that the linker decides that those symbols aren't used
> (and they indeed aren't) and it drops them. I think I've seen that
> behavior before. Just to prove that idea, try to use them somewhere
> (e.g some dummy function in mod_perl.c).
Exactly, when the target of a link operation is an actual binary, the
linker will remove all unused functions. That is not the
case with a .so where the linker has no possible way of knowing what
might be needed at a later time.
So, attached is a patch similar to httpd's ap_hack_* to work around this
problem.
In a nutshell, create a modperl_exports.c that contains this :
const void *modperl_ugly_hack = NULL;
const void *modperl_hack_$name = (const void *)modperl_$name;
[...]
where $name is each and every single public modperl API function.
This doesn't even guarantee that the linker won't delete these entries
from there, since it
will detect correctly that not a single external compilation uint needed
any of the symbols
in modperl_exports.c. Thus, to create that dependency, in mod_perl.c :
const void *modperl_suck_in_ugly_hack(void);
const void *modperl_suck_in_ugly_hack(void)
{
extern const void *modperl_ugly_hack;
return modperl_ugly_hack;
}
And that does create an external link/dependency and the linker keeps
all symbols around.
As a nice side effect, this might be of some help to people on more
esoteric platforms.