I'm trying to build some of the Boost libraries for the tru64cxx65 toolset. It seems that a header is missing from my compiler (Compaq C++ V6.5-030 for Digital UNIX V4.0F). This kind of error is showing up in a lot of code, since it seems to be a problem in a basic Boost header: cxx: Error: /tmp_mnt/netDISKS/cgi/DIGITAL6/cgi/vendor/library/boost/boost_1_32_0/boost/cstdint.hpp, line 87: #5 could not open source file "inttypes.h" # include <inttypes.h> ----------------------^ cxx: Error: /tmp_mnt/netDISKS/cgi/DIGITAL6/cgi/vendor/library/boost/boost_1_32_0/boost/cstdint.hpp, line 91: #282 the global scope has no "int8_t" using ::int8_t; ----------^ cxx: Error: /tmp_mnt/netDISKS/cgi/DIGITAL6/cgi/vendor/library/boost/boost_1_32_0/boost/cstdint.hpp, line 92: #20 identifier "int8_t" is undefined typedef int8_t int_least8_t; ----------^ ... cxx: Info: 27 errors detected in the compilation of "/tmp_mnt/netDISKS/cgi/DIGITAL6/cgi/vendor/library/boost/boost_1_32_0/libs/filesystem/build/../src/convenience.cpp". cxx -c -timplicit_local -ptr "bin/boost/libs/filesystem/build/libboost_filesystem.so/tru64cxx65/release/cxx_repository" -noimplicit_include -D__USE_STD_IOSTREAM -nousing_std -msg_display_number -msg_disable 186,450,1115 -DNDEBUG -DNDEBUG -DBOOST_FILESYSTEM_DYN_LINK=1 -O2 -model ansi -I"bin/boost/libs/filesystem/build" -I"/tmp_mnt/netDISKS/cgi/DIGITAL6/cgi/vendor/library/boost/boost_1_32_0" -I"/usr/include" -I"/tmp_mnt/netDISKS/cgi/DIGITAL6/cgi/vendor/library/boost/boost_1_32_0" -o "bin/boost/libs/filesystem/build/libboost_filesystem.so/tru64cxx65/release/convenience.o" "/tmp_mnt/netDISKS/cgi/DIGITAL6/cgi/vendor/library/boost/boost_1_32_0/libs/filesystem/build/../src/convenience.cpp" -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
I'm trying to build some of the Boost libraries for the tru64cxx65 toolset. It seems that a header is missing from my compiler (Compaq C++ V6.5-030 for Digital UNIX V4.0F). This kind of error is showing up in a lot of code, since it seems to be a problem in a basic Boost header:
I believe we are assuming that your platform has an <inttypes.h> header (our test machines for that platform do so), if yours does not then you may need to stop BOOST_HAS_STDINT_H from getting defined, I believe this will be either in boost/config/suffix.hpp: # if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901) # define BOOST_HAS_STDINT_H # endif or in boost/config/posix_features.hpp: // POSIX version 6 requires <stdint.h> # if defined(_POSIX_VERSION) && (_POSIX_VERSION >= 200100) # define BOOST_HAS_STDINT_H # endif John.
John Maddock wrote:
I'm trying to build some of the Boost libraries for the tru64cxx65 toolset. It seems that a header is missing from my compiler (Compaq C++ V6.5-030 for Digital UNIX V4.0F). This kind of error is showing up in a lot of code, since it seems to be a problem in a basic Boost header:
I believe we are assuming that your platform has an <inttypes.h> header (our test machines for that platform do so), if yours does not then you may need to stop BOOST_HAS_STDINT_H from getting defined,
BOOST_HAS_STDINT_H is about <stdint.h>, is it not? Not <inttypes.h>.
Peter Dimov wrote:
John Maddock wrote:
I believe we are assuming that your platform has an <inttypes.h> header (our test machines for that platform do so), if yours does not then you may need to stop BOOST_HAS_STDINT_H from getting defined,
BOOST_HAS_STDINT_H is about <stdint.h>, is it not? Not <inttypes.h>.
My system has neither header (Tru64 4.0F), so I guess they are related closely enough that I can follow up with John's suggestion. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
John Maddock wrote:
I believe we are assuming that your platform has an <inttypes.h> header (our test machines for that platform do so), if yours does not then you may need to stop BOOST_HAS_STDINT_H from getting defined, I believe this will be either in boost/config/suffix.hpp:
# if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901) # define BOOST_HAS_STDINT_H # endif
or in boost/config/posix_features.hpp:
// POSIX version 6 requires <stdint.h> # if defined(_POSIX_VERSION) && (_POSIX_VERSION >= 200100) # define BOOST_HAS_STDINT_H # endif
Thanks for the suggestion. It turns out that neither of these defines BOOST_HAS_STDINT_H, because __STDC_VERSION__ is not defined, and _POSIX_VERSION is 199506. Also, boost/cstdint.hpp:85 is a #elif that ends the '#ifdef BOOST_HAS_STDINT_H' block, proving that BOOST_HAS_STDINT_H was not defined. So I will just take Markus's suggestion to remove the __osf__ part of the test for my system. I'll let you guys figure out whether you want to support old versions of Tru64 Unix like mine. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
I'm trying to build some of the Boost libraries for the tru64cxx65 toolset. It seems that a header is missing from my compiler (Compaq C++ V6.5-030 for Digital UNIX V4.0F). This kind of error is showing up in a lot of code, since it seems to be a problem in a basic Boost header:
The problem is Digital UNIX V4.0F. It doesn't have inttypes.h. Try to remove the check for __osf__ in boost/cstdint.hpp:85 and see what happens. But be warned, no regression tests were run for Digital UNIX V4.0F, only for V5.1, so you are on your own. HTH, Markus
Markus Schöpflin wrote:
The problem is Digital UNIX V4.0F. It doesn't have inttypes.h. Try to remove the check for __osf__ in boost/cstdint.hpp:85 and see what happens.
I did that, and it worked fine. I thought someone might like to know that it could use some kind of configuration macro.
But be warned, no regression tests were run for Digital UNIX V4.0F, only for V5.1, so you are on your own.
I understand the risks of using ancient systems. I won't complain about new or changed Boost libraries that no longer build on them. I'm hoping we can retire them in the near future. I'll check out John M's suggestions. While I do that, I wonder whether there is any bjam build option for tru64cxx65 that selects any configuration options distinguishing Tru64 4.x from 5.x. If not, probably the easiest solution for me is to just take your suggestion. (I have no Tru64 5.x systems.) -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Markus Schöpflin wrote:
The problem is Digital UNIX V4.0F. It doesn't have inttypes.h. Try to remove the check for __osf__ in boost/cstdint.hpp:85 and see what happens.
I did that, and it worked fine. I thought someone might like to know that it could use some kind of configuration macro.
If you happen to know a way to distinguish the two versions on preprocessor level, a fix would be easy.
But be warned, no regression tests were run for Digital UNIX V4.0F, only for V5.1, so you are on your own.
I understand the risks of using ancient systems. I won't complain about new or changed Boost libraries that no longer build on them. I'm hoping we can retire them in the near future.
I'll check out John M's suggestions. While I do that, I wonder whether there is any bjam build option for tru64cxx65 that selects any configuration options distinguishing Tru64 4.x from 5.x. If not, probably the easiest solution for me is to just take your suggestion. (I have no Tru64 5.x systems.)
I don't think that currently there is any distinction at all between 4.x and 5.x, neither in boost nor in boost.build or in the toolset. What really amazes me is that you can use V6.5 on Tru64 4.x, I always thought that V5.x was the latest compiler toolset for Tru64 4.x. Markus
Markus Schöpflin wrote:
If you happen to know a way to distinguish the two versions on preprocessor level, a fix would be easy.
What about using _POSIX_VERSION? boost/config/posix_features.hpp sets macros for the availability of various headers. Perhaps there could be one for inttypes.h. It might be difficult to find out what _POSIX_VERSION number would be the best indicator, but it seems a likely place to start. All I can tell you is that my 4.0F system defines _POSIX_VERSION = 199506.
I don't think that currently there is any distinction at all between 4.x and 5.x, neither in boost nor in boost.build or in the toolset.
If the preprocessor lets you down, and inttypes.h became available with 5.0, you could add a toolset option that sets an appropriate -D compiler flag to make the distinction between 4.x and 5.x. It would just be a bjam build option. (If this header is the only reason to distinguish between Tru64 versions, and it was introduced between 5.0c and 5.0d, for example, it seems a bit silly to have a toolset option just for this.)
What really amazes me is that you can use V6.5 on Tru64 4.x, I always thought that V5.x was the latest compiler toolset for Tru64 4.x.
I think that cxx 6.5 was ready before Tru64 5.0 was solid. Everyone was happy with 4.0F and they were unsure of 5.0, or they were not ready to support whatever source code changes it might entail. Yet they wanted the C++ improvements in 6.5. So when you installed the compiler, I think you had to select the version for 4.0 instead of the version for 5.0. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Markus Schöpflin wrote:
If you happen to know a way to distinguish the two versions on preprocessor level, a fix would be easy.
What about using _POSIX_VERSION? boost/config/posix_features.hpp sets macros for the availability of various headers. Perhaps there could be one for inttypes.h. It might be difficult to find out what _POSIX_VERSION number would be the best indicator, but it seems a likely place to start.
All I can tell you is that my 4.0F system defines _POSIX_VERSION = 199506.
I have been grepping around a little on my 5.1 system and the right check for inttypes.h on this OS seems to be #if defined (_XOPEN_SOURCE) && (_XOPEN_SOURCE>=500) #include <inttypes.h> #endif Unfortunately I don't have access to the Open Group Base Specification Issue 5 which could tell me what exactly is promised to be present in that header. The current Issue 6 is aligned with ISO/IEC 9899:1999 and gives us all we need, but of course we already have stdint.h on such a system.
I don't think that currently there is any distinction at all between 4.x and 5.x, neither in boost nor in boost.build or in the toolset.
If the preprocessor lets you down, and inttypes.h became available with 5.0, you could add a toolset option that sets an appropriate -D compiler flag to make the distinction between 4.x and 5.x. It would just be a bjam build option. (If this header is the only reason to distinguish between Tru64 versions, and it was introduced between 5.0c and 5.0d, for example, it seems a bit silly to have a toolset option just for this.)
Agreed.
What really amazes me is that you can use V6.5 on Tru64 4.x, I always thought that V5.x was the latest compiler toolset for Tru64 4.x.
I think that cxx 6.5 was ready before Tru64 5.0 was solid. Everyone was happy with 4.0F and they were unsure of 5.0, or they were not ready to support whatever source code changes it might entail. Yet they wanted the C++ improvements in 6.5.
So when you installed the compiler, I think you had to select the version for 4.0 instead of the version for 5.0.
Unfortunately we are stuck here with DEC CXX V5.7-002 on Tru64 4.0F. That's why there were no tests for this platform. Markus
Markus Schöpflin wrote:
I have been grepping around a little on my 5.1 system and the right check for inttypes.h on this OS seems to be
#if defined (_XOPEN_SOURCE) && (_XOPEN_SOURCE>=500) #include <inttypes.h> #endif
FYI: on my system _XOPEN_SOURCE is defined but has no value: cxx: Error: tests/Test2.cc, line 248: #29 expected an expression cout << "_XOPEN_SOURCE = " << _XOPEN_SOURCE << endl; ----------------------------------------------------^
Unfortunately I don't have access to the Open Group Base Specification Issue 5 which could tell me what exactly is promised to be present in that header.
The current Issue 6 is aligned with ISO/IEC 9899:1999 and gives us all we need, but of course we already have stdint.h on such a system. ...
-- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
participants (4)
-
John Maddock -
Markus Schöpflin -
Peter Dimov -
Richard Hadsell