Re: sync top level configure to binutils

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 16.07.2012 17:30, schrieb Joseph S. Myers: > On Mon, 16 Jul 2012, Rainer Emrich wrote: > >> binutils head top level configure still requires ppl. Now as the changes >> for ppl, isl and cloog are in, I think it's time t

Re: sync top level configure to binutils

On Mon, 16 Jul 2012, Rainer Emrich wrote: > binutils head top level configure still requires ppl. > Now as the changes for ppl, isl and cloog are in, I think it's > time to sync to binutils. Any comments? Both trees seem to have local changes not in the other, so it's no

sync top level configure to binutils

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 binutils head top level configure still requires ppl. Now as the changes for ppl, isl and cloog are in, I think it's time to sync to binutils. Any comments? Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using

Re: libgomp forces -Werror even when top level configure --disable-werror

In the broader scope, there are two separate problems here. One is that libgomp does not honor --disable-werror indeed. However, --disable-werror, if it worked for libgomp, would be too big a hammer to work around the second (real) problem, and not quite useful for development builds anyway.

Re: libgomp forces -Werror even when top level configure --disable-werror

Hi, FYI this problem is still here on powerpc64-linux, I opened http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42519 There's also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32193 Laurent On Thu, 2009-02-19 at 15:06 +0100, Laurent GUERBY wrote: > Hi, > > Trunk bootstrap on powerpc64-linux (deb

Re: Question about top-level configure code and in-tree builds

From: "Ben Elliston" On Fri, 2009-04-10 at 23:56 -0400, Kaveh R. GHAZI wrote: Ah, but cake is only easy when someone else bakes it. :-) While you're baking, Kaveh :-) could you see if your patch could also fix: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34818 Thanks, Ben I don't think

Re: Question about top-level configure code and in-tree builds

On Fri, 2009-04-10 at 23:56 -0400, Kaveh R. GHAZI wrote: > Ah, but cake is only easy when someone else bakes it. :-) While you're baking, Kaveh :-) could you see if your patch could also fix: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34818 Thanks, Ben

Re: Question about top-level configure code and in-tree builds

"Kaveh R. GHAZI" writes: > On Fri, 10 Apr 2009, Ian Lance Taylor wrote: > >> Add a new shell variable in configure.ac extra_mpfr_configure_args. Set >> it to what you want to pass to the mpfr configure. Call >> AC_SUBST(extra_mpfr_configure_args). In Makefile.in add a line >> EXTRA_MPFR_CONFIG

Re: Question about top-level configure code and in-tree builds

On Fri, 10 Apr 2009, Ian Lance Taylor wrote: > Add a new shell variable in configure.ac extra_mpfr_configure_args. Set > it to what you want to pass to the mpfr configure. Call > AC_SUBST(extra_mpfr_configure_args). In Makefile.in add a line > EXTRA_MPFR_CONFIGURE_ARGS = @extra_mpfr_configure_a

Re: Question about top-level configure code and in-tree builds

"Kaveh R. GHAZI" writes: > What I would like to see is that the extra_configure_flags for mpfr > actually check whether gmp is being built in-tree before passing > --with-gmp-build=foo to mpfr's configure. But I don't get how to do that. > If the mpfr case could be fixed, I could then copy the m

Question about top-level configure code and in-tree builds

I'm seeing an issue with the top level configure code. Looking at it requires juggling m4, guile, shell and make syntax in one's head, I'm having some trouble so I'm seeking some assistance. I'm running into the actual problem when I'm integrating the mpc librar

libgomp forces -Werror even when top level configure --disable-werror

Hi, Trunk bootstrap on powerpc64-linux (debian etch) fails on a warning during libgomp build: << if /bin/sh ./libtool --tag=CC --mode=compile /home/guerby/build-144268/./gcc/xgcc -B/home/guerby/build-144268/./gcc/ -B/n/41/guerby/install-trunk-144268/powerpc64-unknown-linux-gnu/bin/ -B/n/41/gue

Re: Who should top level configure changes be coordinated with?

On Sun, 2007-10-14 at 18:28 -0500, Steve Kenton wrote: > If so, who should these sort of patches be coordinated with? > I did not find a maintainer listed for the top level configure. build machinery (*.in) Paolo Bonzini [EMAIL PROTECTED] build machinery (*.in) DJ D

Who should top level configure changes be coordinated with?

While digging through the top level configure researching my inhibit_libc changes I realized that there are some non-obvious ways to shoot yourself in the foot. For example, the build-sysroot parameter parsing in gcc-4.3-20071012 has the following code fragment. It looks like specifying

Re: top-level configure

> > 2007-07-23 Ralf Wildenhues <[EMAIL PROTECTED]> > > > > * configure.ac (TOPLEVEL_CONFIGURE_ARGUMENTS, baseargs): > > Pass --silent if $silent. Ok.

Re: top-level configure

Ralf Wildenhues wrote: Hello, a gentle reminder for: Ok. Paolo

Re: top-level configure

Hello, a gentle reminder for: <http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01679.html> :ADDPATCH configure: > * Ben Elliston wrote on Sat, Jul 21, 2007 at 10:33:54PM CEST: > > > It used to be the case that the Cygnus top-level configure script would > > pass any

Re: top-level configure

Hello Ben, * Ben Elliston wrote on Sat, Jul 21, 2007 at 10:33:54PM CEST: > Before I open a PR for this, I'd like to make sure I'm not doing > anything wrong .. :-) I don't think you are. > It used to be the case that the Cygnus top-level configure script would > pa

top-level configure

Before I open a PR for this, I'd like to make sure I'm not doing anything wrong .. :-) It used to be the case that the Cygnus top-level configure script would pass any configure options to all subdirectory `configure' invocations. Now it doesn't seem to work as I expect when I