On 7/10/02 21:45, "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
> At 03:27 PM 10/7/2002, Sander Temme wrote: >> Your HEAD probably uses the glibtool(ize) installation on your local box, >> which on 10.2 by default is 1.4.2. The tarball was built using the FreeBSD >> libtool, which is 1.3.4. This version did not know about Darwin yet and will >> not create any sort of shared library on this platform. The solution is >> building the tarball with a more recent version of libtool. >> >> Maybe Apache should fail more conclusively if the user wants .so modules and >> the build system can't do them, but that's a different question from getting >> the functionality to work. >> >> I think the ASF roll environment should bump its libtool. I doubt Darwin is >> the only platform that would benefit from that. > > This is my doing. > > Suggestion; could you offer a patch to build/httpd_roll_release that warns > the RM that the version of buildconf is too stale? Checking against 1.4.2 would be a good-thing(TM) indeed, but doesn't guarantee that on certain platforms (such as darwin, where the mainstream libtool port doesn't work) this will not break things again... We've been playing the libtool game since I started building 2.0. At one point or another, it broke things (I remember AIX as well), and as far as I know, noone has ever been able to get a patch incorporated into the main tree (I mean, removing a couple of "" is not a big deal, right?)... We can't keep libtool on our CVS as it's GPLed, let's just keep it off somewhere, apply the patches _we_ need, and keep our machines updated with _our_ version which works _for_us_... Right? > And yes - updating all the Apache machines would be convienent. If my ex-girlfriend decides to give me back my Cube, I might be able to keep it as an Apache Server for development and Testing on MacOS/X, since it seems that moof is completely unmaintained... Pier