On Tue, Nov 11, 2014 at 03:59:03PM +0100, FX wrote:
>
> > Since you are simply patching all the configure files, the question
> > seems academic unless you switch to properly regenerating all of the
> > configure files using a fixed libtool.m4.
>
> I am actually proposing to fix libtool.m4 and re
> Since you are simply patching all the configure files, the question
> seems academic unless you switch to properly regenerating all of the
> configure files using a fixed libtool.m4.
I am actually proposing to fix libtool.m4 and regenerate the configure scripts
(which gives the same result as
On Tue, Nov 11, 2014 at 9:45 AM, FX wrote:
>>It looks like you missed patching a few configure files...
>>
>> libjava/classpath/configure
>> libjava/configure
>
> Aren’t those under external control? i.e. maintained out of GCC tree?
However these are maintained, the libjava configure files st
>It looks like you missed patching a few configure files...
>
> libjava/classpath/configure
> libjava/configure
Aren’t those under external control? i.e. maintained out of GCC tree?
> libgo/configure
> zlib/configure
Those are maintained upstream, and we import them directly. I’ve filed a
FX,
It looks like you missed patching a few configure files...
libjava/classpath/configure
libjava/configure
are definitely needed while
libgo/configure
zlib/configure
should be added for completeness.
Jack
On Tue, Nov 11, 2014 at 4:15 AM, FX wrote:
>> Your patch con
> Your patch contains lots of other changes, not just the libtool.m4
> change. Please filter those out.
Sorry about that. The patch attached should be clean, and the ChangeLog entries
formatted as they should.
OK to commit? This touches so many area it probably needs a build maintainer or
glob
On Tue, Nov 11, 2014 at 09:58:45AM +0100, FX wrote:
> libtool.m4 has a globbing pattern that assumes Mac OS version numbers 10.x
> are one digit for x. That’s unfortunate, especially now that Mac OS 10.10 was
> released :)
>
> libtool has released a new version to fix this bug. The attached patc
