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:[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]
