May I recommand you take a look at mod_jk from 
jakarta-tomcat-connectors which use configure stuff
to try to ease the build...

All the developpment effort on tomcat connectors have
now moved to J-T-C....

-
Henri Gomez                 ___[_]____
EMAIL : [EMAIL PROTECTED]        (. .)                     
PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-----Original Message-----
>From: Aaron Bannert [mailto:[EMAIL PROTECTED]]
>Sent: Sunday, November 18, 2001 9:04 PM
>To: Tomcat Developers List
>Subject: Re: Problem compiling mod_webapp for IBM HTTP Server 1.9.19
>running on AIX 4.3.3. Please help save Tomcat for a high 
>profile project
>in Switzerland
>
>
>Lurking indeed... ;)
>
>
>On Sun, Nov 18, 2001 at 10:34:42AM -0800, Justin Erenkrantz wrote:
>> On Sat, Nov 17, 2001 at 08:51:24PM +0100, 
>[EMAIL PROTECTED] wrote:
>> > First of all I attempt to calmly summarize the problem and 
>only then let my emotions get through. 
>
>You're certainly not the first to be frustrated by this problem. :)
>
>> > My insufficient knowledge of AIX platforms prevents me 
>from successfully compiling mod_webapp (as well mod_jk) on AIX 
>4.3.3 platform.
>> >  
>> > Tomcat itself appears to be running flawlessly. 
>Unfortunately due to my meager knowledge of AIX I seem to be 
>unable to recompile neither mod_webapp nor mod_jk for the 
>specified platform. Actually compilation worked fine in both 
>cases. What did fail was the 'ld' linker. As far as I can 
>judge about possible cause of failure, the linker requires a 
>module export (.exp) file in order to be able successfully 
>complete linking process. In this respect AIX appears to 
>differ from Unixes, as I had no problems at all building 
>mod_webapp & mod_jk under Linux (Mandrake 8.0 & Mandrake 8.1) 
>as well as Solaris 8. The problem is aggravated by the 
>management's desire to use IBM HTTP Server instead of plain 
>Apache mainly due to IBM's SSL support, which is perceived to 
>be more trustworthy and secure. 
>> > 
>> > Is my assumption right? If yes, is there a way I could 
>generate that damn .exp file for mod_webapp? I could also live 
>with mod_jk as a fallback scenario. 
>
>[snip]
>> I know that Aaron Bannert spent some time working with the IBM
>> httpd folks (Victor, Greg, Bill, Jeff, etc.) trying to get AIX DSO 
>> support for Apache 2.0 and APR.  I believe the eventual conclusion 
>> from the IBM AIX gurus in Austin was that the linker is not capable 
>> of handling external dependencies in an acceptable manner.  Their
>> recommendation was to wait for the next major release of AIX which 
>> would have a new linker.  But, this isn't very helpful to you or 
>> to us httpd folks though.
>
>As of yet we have not been able to tame the beast that is the 
>AIX linker
>WRT apache-2.0 and DSOs. The essential problem has to do with 
>the mechanism
>used at runtime to load and dynamically link modules, and the aparent
>inability of the AIX linker to deal with interdependent shared objects.
>
>In the short term this really only applies to apache-2.0 and modules
>that automatically depend on other libraries, like how 
>mod_webapp depends
>on libapr and libaprutil. The problem in this scenario is that 
>libaprutil
>actually depends on symbols exported from libapr. First-order runtime
>linkages seem to work fine, but as soon as you hit a symbol 
>that depends
>on that second library (even if they are statically linked 
>into the same
>shared object) you'll get a segfault. It's entirely possible that over
>in httpd-2.0 we're doing something wrong, but given the number 
>of people
>looking at this issue, that is becomming less and less likely.
>
>> > I have been informed by the management that if problem is 
>not resolved by mid next week Tomcat will be replaced with 
>WebSphere 3.5 Standard Edition. 
>
>My first impression to this post was to suggest you contact your vendor
>for a solution. (My second and more emotionally based response was to
>suggest you change operating systems. ;)
>
>Hope that provides some insight,
>-aaron
>
>--
>To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to