Latest autoconf (2.63): problem generating libtool script when reconfiguring GCC (maybe others).

Dave Korn
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)
-L`${PWDCMD-pwd}`/../libstdc++-v3/src/.libs -rpath
`${PWDCMD-pwd}`/.libs:`${PWDCMD-pwd}`/../libstdc++-v3/src/.libs -lstdc++"
+    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:
Problem reports:

More information about the Cygwin mailing list