I am trying to compile/install boost libraries (1.35.0 version) and some erros appears in console:
[code]# ./configure CC=ntox86-gcc-3.3.5 CXX=ntox86-g+±3.3.5 --without-icu --with-libraries=regex,filesystem
Building Boost.Jam with toolset qcc… tools/jam/src/bin.qnxntox86/bjam
Unicode/ICU support for Boost.Regex?.. disabled.
Backing up existing Boost.Build configuration in user-config.jam.15
Generating Boost.Build configuration in user-config.jam…
Generating Makefile…
make install
./tools/jam/src/bin.qnxntox86/bjam --user-config=user-config.jam --prefix=/usr/local --exec-prefix=/usr/local --libdir=
/usr/local/lib --includedir=/usr/local/include --with-regex --with-filesystem install
Building Boost.Regex with the optional Unicode/ICU support disabled.
Please refer to the Boost.Regex documentation for more information
(don’t panic: this is a strictly optional feature).
…patience…
…found 11243 targets…
…updating 9 targets…
qcc.compile.c++ bin.v2/libs/system/build/qcc/release/threading-multi/error_code.o
libs/system/src/error_code.cpp: In member function virtual std::string <unnamed>::posix_error_category::message(int) const': libs/system/src/error_code.cpp:112: error: strerror_r’ undeclared (first use
this function)
libs/system/src/error_code.cpp:112: error: (Each undeclared identifier is
reported only once for each function it appears in.)
libs/system/src/error_code.cpp: In member function `virtual
boost::system::error_condition
::system_error_category::default_error_condition(int) const’:
libs/system/src/error_code.cpp:167: error: duplicate case value
libs/system/src/error_code.cpp:164: error: previously used here
cc: /usr/qnx632/host/qnx6/x86/usr/lib/gcc-lib/i386-pc-nto-qnx6.3.0/3.3.5/cc1plus error 1
…failed qcc.compile.c++ bin.v2/libs/system/build/qcc/release/threading-multi/error_code.o…
…skipped <pbin.v2/libs/system/build/qcc/release/threading-multi>libboost_system-mt-1_35.so.1.35.0 for lack of <pbin.v2
/libs/system/build/qcc/release/threading-multi>error_code.o…
…skipped <p/usr/local/lib>libboost_system-mt-1_35.so.1.35.0 for lack of <pbin.v2/libs/system/build/qcc/release/threadi
ng-multi>libboost_system-mt-1_35.so.1.35.0…
…skipped <p/usr/local/lib>libboost_system-mt.so for lack of <p/usr/local/lib>libboost_system-mt-1_35.so.1.35.0…
…skipped <pbin.v2/libs/filesystem/build/qcc/release/threading-multi>libboost_filesystem-mt-1_35.so.1.35.0 for lack of
<pbin.v2/libs/system/build/qcc/release/threading-multi>libboost_system-mt-1_35.so.1.35.0…
…skipped <p/usr/local/lib>libboost_filesystem-mt-1_35.so.1.35.0 for lack of <pbin.v2/libs/filesystem/build/qcc/release
/threading-multi>libboost_filesystem-mt-1_35.so.1.35.0…
…skipped <p/usr/local/lib>libboost_filesystem-mt.so for lack of <p/usr/local/lib>libboost_filesystem-mt-1_35.so.1.35.0
…
…skipped <p/usr/local/lib>libboost_system-mt-1_35.so for lack of <p/usr/local/lib>libboost_system-mt-1_35.so.1.35.0…
…skipped <p/usr/local/lib>libboost_filesystem-mt-1_35.so for lack of <p/usr/local/lib>libboost_filesystem-mt-1_35.so.1
.35.0…
…failed updating 1 target…
…skipped 8 targets…
Not all Boost libraries built properly.[/code]
Does anybody know how to solve this? My qcc/QCC is set to 3.3.5,gcc_ntox86. The same errors appears with bjam
Most of boost code is made up of template and there is no need to build a library. Just add -Iyour_boost_include_path and you should be good to go in most cases.
It’s been quite a while since I tried to built Boost, but here are my notes, for what they’re worth.
Build bjam FIRST. The build.sh for bjam appears to work in QNX, or at least version 3.1.13 did.
You also need bzip2. You can get it several ways, but all I had to do to compile from source was to change the included Makefile so that CC=qcc (lower case qcc!)
Once you’ve got a bjam executable:
bjam --without-python -sGCC=qcc -sGXX=QCC -sBZIP2_INCLUDE={/path/to/bzip2} -sBZIP2_LIBPATH={/path/to/bzip2}
Of course if you have Python already you can ditch the --without-python. Again, note the caps; they matter.
I didn’t try specifying the gcc version. However, you can modify gcc so that 3.3.5 is the default. I did that at some point, but I’ve forgotten how.
thanks for your suggestion, but the errors continues with this bjam/parameters. However, i tried the same in boost 1.33.1 version and the compilation completed successfully, but without multithread support.
I’m not sure, but i think that this error is related std c lib that has not support to strerror_r function. if anyone has some idea about, please tell me…
is a GNU extension used by glibc (since 2.0), and must be
regarded as obsolete in view of SUSv3. The GNU version may,
but need not, use the user-supplied buffer. If it does, the
result may be truncated in case the supplied buffer is too
small. The result is always NUL-terminated.
The strerror_r() function conforms to IEEE Std 1003.1-2001 (‘POSIX.1’)
The strerror_r() function is similar to strerror(), but is thread safe.
strerror function is a GNU version.
and if QNX supports many requirements of POSIX standard, why BOOST compilation process does not recognize this function and defines the appropriate variable to setup the environment? In this case a simple flag could solve the problem like you said, but until now i don’t see anything about it.
Finally, i completed the libboost_filesystem compilation proccess (1.35.0 version) and it was successfuly. Some adjustments were needed to properly set up the environment. I would like to thank Guenther
Stattenberger for the valuable information that helped me to solve the problem. The original information posted at Boost-user mail list follows bellow:
"according to the QNX documentation, strerror itself is thread-safe,
therefore I thought it correct to add the QNX switch to
libs\system\src\error_code.cpp:86
if defined(BOOST_WINDOWS_API) || defined(__hpux) || defined(__sun)\
In addition, I had to uncomment the case statement for EALREADY later in this
file. Since the QNX errno.h header defines #define EALREADY EBUSY
it won’t compile otherwise."
I hope that it helps other with the same difficulty
I don’t think this is the correct approach. There are already way too many O/S specific tests (this is ugly). The real thing that needs to be tested is not whether we are building on QNX, but whether the strerror that is supplied by the system libraries is reentrant.
Thus the area where strerror_r is included needs to be cleaned up to read something like
#if !defined(REENTRANT_STRERROR)
// do whatever needs to be done to get a re-entrant strerror on a specific platform
...
// here there may be further tests for specific platforms to handle the case
// specific methods of obtaining a re-entrant strerror
#endif
This should be the mantra for these kind of tests:
“Test for the feature that is required, not for a platform that just happens to have (or not have) the required feature (as a side-effect) at the time you are adding the test”