This check has been causing lots of problems for us, mostly because it
cares a LOT about whitespace - even a stray space at the end of the
variable. Are there any plans to make it less picky about whitespace
in the near future? Otherwise, is there some way to disable it
globally in, say, a gcc o
> I think for 2.60 we took care that AC_CONFIG_SUBDIRS and the like don't
> munge whitespace -- that was a cause for failure. And some more global
> $as_echo changes in 2.61b (CVS). But I guess that doesn't apply to GCC
> as it calls the sub-configures manually.
And it's still working on bringi
> Do you think that is feasible for GCC? I know it far too little to
> be able to judge.
No, sorry. In gcc, binutils, gdb, newlib, et al; there is a toplevel
configure and Makefile. Configure programatically determines which of
the available source directories will participate in the build, an
> Not any more. Nowadays every configured subdirectory gets its own cache.
Hmmm... I thought our source tree was up to date. I wonder if that
would "solve" our problem.
Still having autoconf be sensitive to trailing spaces seems overly
paranoid.
__
> Would you please point me to one bug report where the issue actually was
> only changed whitespace in the precious variables, or, even better, show
> me how to reproduce the issue you observe (with a combined, up to date
> tree)?
http://sourceware.org/ml/newlib/2006/msg01038.html
http://sourcew
> So, I am suspecting the "CFLAGS" leak in GCC's toplevel Makefile.in
> triggering the ".. change since previous run", might have been fixed in
> GCC since then.
If gcc moved to separate caches between those, that might be
hiding the bug, too.
___
Aut
> I am observing the "CFLAGS" issue in newlib-1.15.0 with gcc < 4.2, but I
> am not observing this issue with gcc >= 4.2.
>
> So, I am suspecting the "CFLAGS" leak in GCC's toplevel Makefile.in
> triggering the ".. change since previous run", might have been fixed in
> GCC since then.
Our tree i
> To work around this issue with gcc-4.1.x (I do not use it for gcc-4.0.x
> nor gcc-4.2), I am using this hack below.
We have that hack, plus a few others. I originally asked about this
because I'd rather not have to keep hacking onto otherwise normal
looking code just to avoid whitespace change
> > IMHO autoconf's test shouldn't be so sensitive to whitespace
> > changes.
>
> You keep saying that, but that doesn't make it more right.
Since I'm merely stating my opinion, by definition it is right.
Whether or not the test should change is, of course, debatable.
But I fail to see the poin
> Independently, I would anyway be interested in issues that keep you
> (GCC, binutils, ...) from moving to 2.61 rather than 2.60 or 2.59.
I suspect a major issue is that "popular development platforms" still
only have 2.59 on them. Making sure that everyone knows which version
is the right one,
10 matches
Mail list logo
