http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #21 from Jonathan Wakely ---
Thanks for debugging and resolving it.
(In reply to Maxime Boissonneault from comment #0)
> - the options given when GCC was configured/built;
> ../${SRCDIR}/configure CFLAGS="$FLAGS" CXXFLAGS="$FLAGS" \
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
Maxime Boissonneault changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #19 from Maxime Boissonneault ---
Hi again,
I notice in the first line that leads to an error of bits/c++config.h not found
:
/software6/src/gcc-4.8.2-build/./gcc/xgcc -shared-libgcc
-B/software6/src/gcc-4.8.2-build/./gcc -nostdinc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #18 from Jonathan Wakely ---
(In reply to Maxime Boissonneault from comment #13)
> I see that.
>
> Wasn't the GCC 4.8.1 compiler supposed to already know to look in the folder
> /software6/compilers/gcc/4.8.1/include/c++/4.8.1/x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #17 from Jonathan Wakely ---
(In reply to Maxime Boissonneault from comment #5)
> Basically, we started with the system GCC. We compiled GCC, GMP, MPFR,
> MPC_V, with that system GCC. Then, we uninstalled the system GCC and its
> libst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #16 from Maxime Boissonneault ---
On a related not, is there a way to control default paths that GCC will always
look into for libraries and/or headers ? We install things in non-standard
locations (so that we can have multiple version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #15 from Maxime Boissonneault ---
Thanks for the advices. I will try to sort this out tomorrow. The reason we
enable all languages and why we build from source is to control all
dependencies and are able to provide multiple versions of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #14 from Paolo Carlini ---
You can experiment at will, but remember that on any sane Linux system nothing
similar is necessary, a tarball or a checkout can be built as is and all the
C99 facilities are normally enabled. Something I wou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #13 from Maxime Boissonneault ---
I see that.
Wasn't the GCC 4.8.1 compiler supposed to already know to look in the folder
/software6/compilers/gcc/4.8.1/include/c++/4.8.1/x86_64-unknown-linux-gnu/
to find bits/c++config.h ?
Do I ne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #12 from Paolo Carlini ---
In your log there are a lot of errors: "fatal error: bits/c++config.h: No such
file or directory" which are definitely unexpected and bad.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #11 from Paolo Carlini ---
But that is what matters, because the stdio functions in the header are
protected by the global C99 macro, not by something more fine grained. In any
case, on any normal Linux system the final outcome must be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #10 from Maxime Boissonneault ---
Created attachment 32759
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32759&action=edit
stage1-libstdc++-v3-config.log
Here is there libstdc++-v3 config.log file.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #9 from Maxime Boissonneault ---
I attached the config.log, configure.log and make.log. The only one containing
C99 is the make.log.
The only test that says no is
checking for fully enabled ISO C99 support... no
The rest are yesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #8 from Maxime Boissonneault ---
Created attachment 32758
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32758&action=edit
config.log, configure.log, make.log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #7 from Paolo Carlini ---
I would suggest having a look to the config.log in the libstdc++-v3 build
directory and see which and how a C99 test is failing.
By the way (Jon) in mine I see a warning:
conftest.cpp: In function 'int main(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #6 from Maxime Boissonneault ---
Here is our complete installation document :
https://docs.google.com/a/calculquebec.ca/document/d/1hcddCXGnm6OgTwRxRDU2akb-AxKx2aursppLp2JPwWo/edit
It went :
- System GCC compiled GCC 4.8.1
system GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #5 from Maxime Boissonneault ---
Any pointer on what could be wrong ?
Maybe a clue is that we compiled GCC not with the system GCC, but with another
GCC ?
Basically, we started with the system GCC. We compiled GCC, GMP, MPFR, MPC_V,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #4 from Jonathan Wakely ---
(In reply to Maxime Boissonneault from comment #2)
> /* #undef _GLIBCXX_USE_C99 */
Something is wrong with your GCC build.
I've just installed it on CentOS 6.5 and it works fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #3 from Maxime Boissonneault ---
Sorry, I missed the first question. The value of $FLAGS was
FLAGS="-O2 -march=native -pipe -Wall"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #2 from Maxime Boissonneault ---
[mboisson@colosse3 ~]$ grep USE_C99
/software6/compilers/gcc/4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu/bits/c++config.h
/* #undef _GLIBCXX_USE_C99 */
/* #undef _GLIBCXX_USE_C99_COMPLEX */
/* #und
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61101
--- Comment #1 from Jonathan Wakely ---
What was the value of $FLAGS when GCC was built?
Something is preventing the library from using C99 functions.
What is the output of running this?
grep USE_C99
/software6/compilers/gcc/4.8.2/include/c++/4
21 matches
Mail list logo
