In mod_perl 2.0 on AIX we have to import symbols from ap_ and apr_ namespaces
when linking the shared object (the other approach is to use -berok which
works as symbols get resolved at load time, but this is too error-prone).
The following two ways to import apr_ symbols seem to have the same effect (let's say that there is only apr, and no aprutil for simplicity):
ld -bM:SRE -brtl -bnoentry -bI:/path/to/apr.exp a.o b.o -o foo.o
or
ld -bM:SRE -brtl -bnoentry -lapr a.o b.o -o foo.o
it looks like the loader figures out the imported symbols either from apr.exp
or from apr.so. It seems that the latter way is preffered since the exp file
could be wrong, whereas the shared object is always correct.
The shared object has symbols that aren't intended for use by applications, whereas the .exp file doesn't. Personally, I think it is a good thing that we have a tight control over our API, so I think in terms of getting httpd.exp fixed instead of forgetting about that mechanism altogether.
mod_perl has been caught before on AIX calling functions which weren't intended to be part of the API because of the use of httpd.exp. Is that useful to anybody?
Also, if httpd.exp is broken, it is because exports.c is broken, so there may be additional reasons to get the parse problem or symbol declaration problem resolved.
--
By the way, what is the symbol that should be in httpd.exp but isn't?
