Jeff Trawick wrote:
Stas Bekman wrote:

Jeff Trawick wrote:

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.



So, you say that it's a better practice to use the exp file than the shared object. Especially since I still not sure what the shared object is in case of httpd (in contrast to apr/apr-util which are libs).


yes, in my opinion it is better practice to use the exp file

Thanks Jeff!


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?



Sorry, I'm not following you here. You just said above that using httpd.exp is the safest since it only provides symbols which are exported.


this was an attempt at anecdotal support for what I mentioned earlier...

more clearly:

a couple of years ago mod_perl wouldn't build on AIX because it called an httpd function which wasn't listed in httpd.exp... it wasn't listed in httpd.exp because it wasn't an intended part of the API...

That's a similar trouble I've had with apr_generate_random_bytes, but for a different reason (not using APR_HAS_RANDOM).


Yesterday, I've patched the mod_perl 2.0 build code to build on aix (tested on powerpc/aix/5.1). The interesting thing that I haven't used .exp's at all (neither -lapr/-laprutil/etc). I've used -berok and -brtl and let everything to be resolved at the startup time. This seems to work just fine, since by the time mod_perl boots, httpd/apr/aprutil are all loaded in memory.

Do you think this will work on other aix versions/platforms?

__________________________________________________________________
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



Reply via email to