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

Reply via email to