httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [proposal/vote] OS X support
Date Thu, 12 Dec 2002 13:19:04 GMT
"Issac Goldstand" <> writes:


> So we're talking about perl glue for OS X only?  If so, I'm +1 for
> leaving it and moving on to bigger and better things...

It's even sillier than that.  Apache::Request and Apache::Cookie 
both work fine on OS X.  The problem WAS that if someone tried to 
use them simultaneously, the OS X dynamic loader (dyld) would balk, 
complaining about duplicate symbols.  

libapreq.a is statically linked into and, 
so each *.so contains a copy of it.  On ELF-based systems, loading
the *.so's simultaneously presents no problem whatsoever.  But OS X 
isn't ELF based, and this design does cause a symbol clash there.

When libapreq-1.0 was released, I developed 2 experimental 

  1) patching httpd to statically link libapreq.a into itself,
  2) installing using GNU libtool, and 
    *dynamically* linking and to that.

The first one worked, the second did not.  It turns out 
that libapreq-1.0 contained an older version of GNU libtool,
so it needed to be upgraded for OS X support.  Once we did
that, the second approach seemed to work for people with 
a user-compiled, statically linked mod_perl installation.  
It's not clear what happens with the vendor-supplied mod_perl 
(DSO) on OS X.

The problem NOW is that the OS X mod_perl community is too 
damned lazy to kick back a *documentation patch* that explains 
how to build Apache::Request/Cookie.  The build process going 
to be very awkward for OS X, and without any volunteerism from 
that community, I'm not going to burden apreq-dev with OS X user 
complaints about our sucky OS X build.

Bear in mind that I've never logged into an OS X box, and don't
plan to.  If it was the Win32 community that treated the apreq
developers like this, they'd surely be flamed for it.  I don't
see why modperl OSX-ers should be afforded any less heat.

Joe Schaefer

View raw message