Latest autoconf (2.63): problem generating libtool script when reconfiguring GCC (maybe others).
Tue Dec 9 19:10:00 GMT 2008
Eric Blake wrote:
> my understanding is that the entire gcc tree must be generated by 2.59 and
> nothing else, because gcc includes a lot of hacks back-ported from newer
> autoconf versions to make 2.59 work, but which might break when used side-by-
> side with even newer autoconf versions where the upstream implementation has
> moved on from the state where those hacks were extraced from.
Argh. Thanks for that. I was thrown off slightly by the fact that the
raw tarball mixes 2.59 and 2.61, but on looking closer it's only fixincludes
that was generated by 2.61, so I guess it still matters elsewhere.
I'm a bit surprised that I didn't get an error, when binutils /does/ give
an error, and the binutils error comes from a macro called
> I guess it boils down to: why are you rerunning autoconf anywhere in the gcc
> tree in the first place? Are the configuration managed configure scripts
> already in the gcc tree insufficient in some manner? Let's tackle the root
> problem (what do you hope by regenerating java's configure) before worrying
> about the secondary problem (why isn't a version of autoconf not yet supported
> by the gcc team not working).
Well, if gcc isn't /supposed/ to work with newer autoconf, there /is/ no
second problem! As to the first problem: I need to modify
extra_ldflags_libjava before it gets AC_SUBST'd:
@@ -808,6 +809,9 @@ arm*linux*eabi)
+ extra_ldflags_libjava='-lws2_32 -lintl'
... I think it's the right place for a bit of target-os-related configury
such as that.
Anyway thanks for pointing out something I should have remembered myself :)
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin