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 ;-)
signature.asc
Description: OpenPGP digital signature
