https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691
Richard Biener changed:
What|Removed |Added
Target Milestone|11.5|12.5
--- Comment #8 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691
Richard Biener changed:
What|Removed |Added
Target Milestone|10.5|11.5
--- Comment #7 from Richard Biene
]
|libcpp configure fails on |libcpp configure fails on
|empty expansion |empty expansion
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
Fixed on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691
--- Comment #5 from CVS Commits ---
The master branch has been updated by Bernhard Reutner-Fischer
:
https://gcc.gnu.org/g:5a6c698ea31f587151a2fa4a982c8cc43bd9cc45
commit r13-4165-g5a6c698ea31f587151a2fa4a982c8cc43bd9cc45
Author: Bernhard Reut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691
--- Comment #4 from rep.dot.nop at gmail dot com
---
The problem was encountered with configure --enable-valgrind-annotations with
valgrind not installed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691
--- Comment #3 from Andrew Pinski ---
have_valgrind_h is never set anywhere.
Adding before that code in configure.ac:
dnl # This check AC_REQUIREs various stuff, so it *must not* be inside
dnl # an if statement. This was the source of very frus
]
|libcpp configure fails on |libcpp configure fails on
|bashism |empty expansion
--- Comment #2 from Andreas Schwab ---
That's 100% POSIX conforming, it's just $have_valgrind_h etc. expanding to
nothing (only gcc/configure has the necessary checks).
||7.1.0
Known to work|7.0 |6.1.0
Summary|libcpp configure fails on |[10/11/12/13 Regression]
|bashism |libcpp configure fails on
||bashism
Ever confirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691
Bug ID: 107691
Summary: libcpp configure fails on bashism
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482
Nicolas Boulenguez changed:
What|Removed |Added
CC||nicolas at debian dot org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482
Kevin Sweet changed:
What|Removed |Added
CC||kevin at teews dot com
--- Comment #8 from
--- Comment #7 from tromey at gcc dot gnu dot org 2009-08-09 00:09 ---
The earlier comments should probably first be investigated by looking
in config.log. (Except the original comment which sounds like a missing
feature in depcomp -- that should go upstream to Automake.)
Comment #5 so
--- Comment #6 from steven at gcc dot gnu dot org 2009-08-08 22:52 ---
Obviously something experienced by more than one user, on more than one
platform.
Tom, can you make a guess about what is wrong based on the suggested
work-around of comment #5?
--
steven at gcc dot gnu dot org
--- Comment #5 from aschorr at telemetry-investments dot com 2007-03-15
13:22 ---
FYI, I had this same problem trying to build gcc-4.1.2 on Solaris 8.
After a lot of experimentation, I found that it could be solved by
changing my PATH so that any invocations of 'make' will actually resu
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-19 22:57 ---
> checking dependency style of gcc... none
This is a weird message (from comment #2 and comment #3).
It suggests to me that something else is going on -- something
unrelated to the original bug filed in this PR. For
--- Comment #3 from maxim dot yegorushkin at gmail dot com 2007-01-03
12:31 ---
(In reply to comment #2)
> I'm having a similar problem on Linux Fedora Core 5. Is there any quick way to
> fix it? I am new to autoconf and would appreciate any hints.
>
> Here is the output:
The same pro
al/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/build-x86_64-unknown-linux-gnu/fixincludes'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/build-x86_64-unknown-linux-gnu/fixincludes'
Configuring in ./libcpp
configure: load
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-16 15:46 ---
The configure check in libcpp is based on automake's code. Do you know if they
support SCO's cc dependencies yet?
Note you should also read README.SCO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482
ese scripts can do the trick?
Thank you,
Mircea
P.S.1 Here's the uname -a : OpenUNIX T114p 5 8.0.0 i386 x86at Caldera UNIX_SVR5
P.S.2 May be mp4 could be made to generate these dependencies so this whole
script collection becomes unneeded?
--
Summary: libcpp/c
Chris Webb <[EMAIL PROTECTED]> wrote:
> libcpp/configure falls over on a Solaris 9 machine (not tested on
> others)
Thanks for the report. This used to be PR bootstrap/21230 and has been already
fixed a few days ago, for both GCC 4.1.0 and GCC 4.0.1.
http://gcc.gnu.org/bugzilla/sho
libcpp/configure falls over on a Solaris 9 machine (not tested on
others)
[EMAIL PROTECTED] libcpp]1% uname -a
SunOS taskmaster 5.9 Generic_118558-06 sun4u sparc SUNW,Sun-Fire-V240
[EMAIL PROTECTED] libcpp]0%
Adding quotes to the appropriate line fixes the problem:
[EMAIL PROTECTED] libcpp]1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-18
14:44 ---
*** This bug has been marked as a duplicate of 21230 ***
--
What|Removed |Added
Hello!
Bootstraping the gcc-4.0.0 leads to a error message:
/tmp/gcc-4.0.0/libcpp/configure[2760]: test: argument expected
As far as I see in the line
if test $GCC = yes; then
the var GCC is not set. It is set in line 2145, but in case of a non gcc
compiler, it is evaluated to an empty string
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
13:07 ---
*** This bug has been marked as a duplicate of 21230 ***
--
What|Removed |Added
When I run "make bootstrap" libcpp/configure exits with a "test: argument
expected". A quick fix did it, when I compile with cc I can expect that
$GCC is not defined.
diff configure configure.DIST
2761,2763c2761
< # BM
< if test "$GCC" = yes; then
< # BM
---
26 matches
Mail list logo
