OpenQNX :: The QNX Community Portal

Aug 21, 2008 - 06:18 AM
Google
  Web openqnx.com   
     Create an account Home · Submit News · QNX Forums · QNX Download · Search   
_
Main Menu
Who's Online
There are 46 unlogged users and 0 registered users online.

You can log-in or register for a user account here.

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
rperrones
9 Post subject: libboost_* compile error  PostPosted: Apr 08, 2008 - 05:37 PM
Active Member


Joined: Feb 12, 2008
Posts: 24

Hi,

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
   <unnamed>::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

    "QCC" -Wc,-ftemplate-depth-100 -O3 -Wc,-finline-functions -Wc,-Wno-inline -shared -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTE
M_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/system/build/qcc/release/threading-multi/error_code.o" "libs/system/src/e
rror_code.cpp"

...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.


Does anybody know how to solve this? My qcc/QCC is set to 3.3.5,gcc_ntox86. The same errors appears with bjam

Thanks
Ricardo
 
 View user's profile Send private message  
Reply with quote Back to top
mario
Post subject: RE: libboost_* compile error  PostPosted: Apr 08, 2008 - 08:38 PM
QNX Master


Joined: Sep 01, 2002
Posts: 2831

I'm not sure this works:
CC=ntox86-gcc-3.3.5 CXX=ntox86-g++-3.3.5

Instead try

CC=qcc -V3.3.5,gcc_ntox86 CXX=qcc -V3.3.5,gcc_ntox86

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.
 
 View user's profile Send private message Visit poster's website  
Reply with quote Back to top
rperrones
Post subject: RE: libboost_* compile error  PostPosted: Apr 09, 2008 - 01:09 AM
Active Member


Joined: Feb 12, 2008
Posts: 24

Hi,

thanks for your suggestion, but even considering these parameters the error continues
 
 View user's profile Send private message  
Reply with quote Back to top
ingraham
Post subject:   PostPosted: Apr 09, 2008 - 08:58 PM
Active Member


Joined: Nov 05, 2003
Posts: 68
Location: Texas
It's been quite a while since I tried to built Boost, but here are my notes, for what they're worth.

1) Build bjam FIRST. The build.sh for bjam appears to work in QNX, or at least version 3.1.13 did.


2) 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!)


3) 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.


-James Ingraham
Sage Automation, Inc.
 
 View user's profile Send private message Visit poster's website  
Reply with quote Back to top
rperrones
Post subject:   PostPosted: Apr 11, 2008 - 10:47 PM
Active Member


Joined: Feb 12, 2008
Posts: 24

Hi ingraham,

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..

Thanks
Ricardo
 
 View user's profile Send private message  
Reply with quote Back to top
rgallen
Post subject:   PostPosted: Apr 12, 2008 - 12:40 AM
QNX Master


Joined: Jul 11, 2002
Posts: 600

rperrones wrote:

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..


That's a good bet. Is there a flag to say "without strerror_r" ?

strerror_r, is not a Posix function, but is a Linux specific function.

From the glibc manpage:

...

char *strerror_r(int errnum, char *buf, size_t n);

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.

...
 
 View user's profile Send private message Visit poster's website  
Reply with quote Back to top
rperrones
Post subject:   PostPosted: Apr 12, 2008 - 03:55 AM
Active Member


Joined: Feb 12, 2008
Posts: 24

Hi,

searching in google:

- 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.
 
 View user's profile Send private message  
Reply with quote Back to top
rperrones
Post subject:   PostPosted: Apr 15, 2008 - 07:14 PM
Active Member


Joined: Feb 12, 2008
Posts: 24

Hi,

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)\
|| (defined(__linux) && (!defined(__USE_XOPEN2K) ||
defined(BOOST_SYSTEM_USE_STRERROR)))\
|| (defined(__osf__) && !defined(_REENTRANT))\
|| (defined(__vms))\
|| (defined(__QNXNTO__)) // <===================================

Any comments on that?

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
 
 View user's profile Send private message  
Reply with quote Back to top
rgallen
Post subject:   PostPosted: Apr 15, 2008 - 07:54 PM
QNX Master


Joined: Jul 11, 2002
Posts: 600

rperrones wrote:
Hi,

searching in google:

- 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.


No. strerror() is Posix. strerror_r() is not.
 
 View user's profile Send private message Visit poster's website  
Reply with quote Back to top
rgallen
Post subject:   PostPosted: Apr 15, 2008 - 08:06 PM
QNX Master


Joined: Jul 11, 2002
Posts: 600

rperrones wrote:

"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)\
|| (defined(__linux) && (!defined(__USE_XOPEN2K) ||
defined(BOOST_SYSTEM_USE_STRERROR)))\
|| (defined(__osf__) && !defined(_REENTRANT))\
|| (defined(__vms))\
|| (defined(__QNXNTO__)) // <===================================

Any comments on that?


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

Code:

#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"
 
 View user's profile Send private message Visit poster's website  
Reply with quote Back to top
rperrones
Post subject:   PostPosted: Apr 15, 2008 - 10:51 PM
Active Member


Joined: Feb 12, 2008
Posts: 24

Thank for your suggestions to improve the code and correct me
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2007 The PNphpBB Group
Credits
All logos and trademarks in this site are property of their respective owners. The comments are property of their posters.
Powered by OpenQNX: The QNX Community Portal Site
QNX and the QNX logo are registered trademarks of QNX Software Systems.