------- Comment #16 from paolo dot carlini at oracle dot com 2009-04-06 13:49 ------- (In reply to comment #15) > Well *some* configure tests succeed (see "Description"), but grep says, of > cris-elf/libstdc++-v3/include/cris-elf/bits/c++config.h: > /* #undef _GLIBCXX_USE_C99_STDINT_TR1 */
Ok... > > if the tests do not pass, the issue is probably > > simpler, just matter of waiting for 448 to be closed > > I can't see that it is a matter of something depending on that PR since all > the > target stuff is there, I'm afraid you didn't get my point completely: *if* that macro above is disabled, then the library *assumes* stdint.h is *not* available, in general. In that case, *any* library code relying on stdint.h should be ifdef-out out completely, disabled. However, the author of the new std::random bits didn't take care of doing that - we have been consistently doing that, elsewhere - and in that case fails are expected. When 448 will be closed, we'll *remove* completely any configure test for stdint.h, we'll assume it's available, similarly to float.h for example, we'll unconditionally include it, and correctly unconditionally enable any facility relying on it. To summarize, right now, for std::random the library is in an inconsistent state for some targets, because the facility is unconditionally enabled but stdint.h is not unconditionally available. I hope my explanation is more clear. The above said, I'm not sure we should spend much time trying to figure out why for your target the configure checks for stdint.h fail, because, as I said above, as soon as 448 is closed, all those tests will go away, the library will simply assume stdint.h (that's the very point of 448, after all, for libstdc++ and all the other target libraries). If, however, you have reasons to believe your stdint.h is still not ok, it's really not ok, that's another matter, does not have much to do with libstdc++ proper. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
