[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-14 09:44:23 UTC --- *** Bug 54576 has been marked as a duplicate of this bug. ***
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2012-09-14 11:44:20 UTC --- Fixed by http://gcc.gnu.org/ml/gcc-bugs/2012-09/msg01086.html
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||drepper.fsp at gmail dot ||com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-09 11:44:45 UTC --- If it's not defined, it means that the configure time tests fails because the target doesn't support the feature. In general - even for stdint which is supported by most targets now - we should simply make sure that the build works in both cases, simply the random features may end up not being available. Adding Ulrich in CC, something needs tweaking in his recent work.
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-09 Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 11:50:18 UTC --- (In reply to comment #0) Commenting out '#ifdef _GLIBCXX_USE_C99_STDINT_TR1' fixed build problem, but I'm not sure that it is correct solution. It's not. (In reply to comment #1) etc. Those are the only uses of it in code that I can find. It's used in many more headers. It seems like it isn't exactly the best name for the define (it no longer just applies to TR1), but it doesn't do too much. I can't think of a case where this would not be desired behavior (I don't remember, but I *think* that the C++ standard says that those typenames should be in the standard namespace). But the C standard requires stdint.h and if the OS doesn't provide that we can't provide a useful cstdint. Anyway, it doesn't appear like removing that code will have any adverse effects. It would completely break libstdc++ on platforms without stdint.h, such as djgpp The fix is simply to check for the macro in random.cc index 50b5359..1d0723d 100644 --- a/libstdc++-v3/src/c++11/random.cc +++ b/libstdc++-v3/src/c++11/random.cc @@ -24,6 +24,8 @@ #include random +#ifdef _GLIBCXX_USE_C99_STDINT_TR1 + #if defined __i386__ || defined __x86_64__ # include cpuid.h #endif @@ -142,5 +144,5 @@ namespace std _GLIBCXX_VISIBILITY(default) 0xUL, 7, 0x9d2c5680UL, 15, 0xefc6UL, 18, 1812433253UL; - } +#endif
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 --- Comment #4 from Andris Pavenis andris.pavenis at iki dot fi 2012-09-09 16:47:44 UTC --- My test was done with DJGPP development version (2.04) only. It has stdint.h, but it was recognized by configure as unusable due to bug unrelated to GCC itself. After fixing this problem locally libstdc++-v3 builds OK for DJGPP v2.04 (only tested cross-native build from Linux) Stable version DJGPP v2.03 does not have stdint.h As the result I agree with the suggestion in comment 3 to completely disable random.cc when _GLIBCXX_USE_C99_STDINT_TR1 is not defined Maybe it would be nice to use #error in header file to inform the user that this feature is not supported for target system (nicer than to get linker error later)
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 17:19:44 UTC --- (In reply to comment #4) Maybe it would be nice to use #error in header file to inform the user that this feature is not supported for target system (nicer than to get linker error later) You won't get a linker error, if the macro is not defined then the types in random are not declared, so code using them won't compile. Using #error would prevent #include random which I don't think is a good idea. There's no harm including the header as long as you don't try to use types which require a working stdint.h The fix is to simply make random.cc check the macro. This is what we already do in future.cc and thread.cc and mutex.cc and other files too.
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 --- Comment #6 from rbmj at verizon dot net 2012-09-09 18:08:11 UTC --- Making local changes to bring stdint.h into compliance works for me as well. (In reply to comment #5) (In reply to comment #4) Maybe it would be nice to use #error in header file to inform the user that this feature is not supported for target system (nicer than to get linker error later) You won't get a linker error, if the macro is not defined then the types in random are not declared, so code using them won't compile. However, you will get weird std::random_device not declared errors, which will seem strange to any end user. Using #error would prevent #include random which I don't think is a good idea. There's no harm including the header as long as you don't try to use types which require a working stdint.h Agreed. But could we use #warning to tell the user what's happening (if portability is an issue we can check for __GNUC__) without going through the source? The fix is to simply make random.cc check the macro. This is what we already do in future.cc and thread.cc and mutex.cc and other files too. Also true.
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 18:18:32 UTC --- No, it should be consistent with how it's handled everywhere else.
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451
rbmj at verizon dot net changed:
What|Removed |Added
CC||rbmj at verizon dot net
--- Comment #1 from rbmj at verizon dot net 2012-09-09 02:36:26 UTC ---
I can confirm that the build fails as reported.
A bit of searching - turns out that acinclude.m4 has the following:
if test x$glibcxx_cv_c99_stdint_tr1 = xyes; then
AC_DEFINE(_GLIBCXX_USE_C99_STDINT_TR1, 1,
[Define if C99 tyeps in stdint.h should be imported in
tr1/cstdint in namespace std::tr1.])
fi
This is confirmed in include/tr1/cstdint:
#ifdef _GLIBCXX_USE_C99_STDINT_TR1
namespace std _GLIBCXX_VISIBILITY(default)
{
namespace tr1
{
using ::int8_t;
using ::int16_t;
etc. However, this is also in include/c_global/cstdint:
#ifdef _GLIBCXX_USE_C99_STDINT_TR1
namespace std
{
using ::int8_t;
using ::int16_t;
etc. Those are the only uses of it in code that I can find. It seems like it
isn't exactly the best name for the define (it no longer just applies to TR1),
but it doesn't do too much. I can't think of a case where this would not be
desired behavior (I don't remember, but I *think* that the C++ standard says
that those typenames should be in the standard namespace).
Anyway, it doesn't appear like removing that code will have any adverse
effects.
The relevant code is coming from revision 150312 (written by Paolo Carlini in
2009). Since this just broke, I'm *guessing* that this is because of 4.8
moving more towards c++11, and because it was thought that this define was only
for tr1, it was removed from a default define set *somewhere* (I'm too scared
to venture too far into the build system...). I can't seem to find any
evidence of this though... I know it worked ~3 months ago, but my git foo can't
seem to find the change.
