X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <2ca21dcc0812091109n5f867ab7hb79e19a18eb86f58@mail.gmail.com>
Date: Tue, 9 Dec 2008 19:09:56 +0000
From: "Dave Korn" <dave DOT korn DOT cygwin AT googlemail DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Latest autoconf (2.63): problem generating libtool script when reconfiguring GCC (maybe others).
In-Reply-To: <loom.20081209T182339-675@post.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <2ca21dcc0812091011t544f1a12hf920d85359131ea2 AT mail DOT gmail DOT com> 	 <loom DOT 20081209T182339-675 AT post DOT gmane DOT org>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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
"_GCC_AUTOCONF_VERSION_CHECK"!

> 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)
     LIBSTDCXXSPEC=-lstdc++
     LIBGCJTESTSPEC="-L`${PWDCMD-pwd}`/.libs
-L`${PWDCMD-pwd}`/../libstdc++-v3/src/.libs -rpath
`${PWDCMD-pwd}`/.libs:`${PWDCMD-pwd}`/../libstdc++-v3/src/.libs -lstdc++"
     ;;
+*-*-mingw*|*-*-cygwin)
+    extra_ldflags_libjava='-lws2_32 -lintl'
+    ;;
 esac
 AC_SUBST(extra_ldflags_libjava)
 AC_SUBST(extra_gij_ldflags)

... 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 :)

    d'oh!
      DaveK

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/