Project Home
Project Home
Source Code
Source Code
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - standard c++ include directories / changing options specified in qcc .conf files: (5 Items)
   
standard c++ include directories / changing options specified in qcc .conf files  
Hi,

I am attempting to build a third party library (libkml) using a configure script and qcc from the 6.3.2 IDE.  I invoke 
configure like this:

$QCC -V3.3.5,gcc_ntox86 -set-default
$CXX=QCC CC=qcc ./configure --host=i386-pc-nto-qnx6.3.0 CXXFLAGS='-g -O0 -lang-c++ -v'

After building a number of sources successfully, I get this error:
      cxxabi.h: No such file or directory

but this file exists in $QNX_TARGET/usr/include/c++/3.3.5/

I believe I can resolve the problem by specifying this directory as a -I include but that doesn't seem right.  So I'm 
wondering what is the proper way to tell QCC to include the std c++ include directories?

I see that by default, QCC is invoked with the options: -nostdinc -nostdinc++ .  How can I turn this off and why is this
 the default?   I attempted to change this in the /etc/gcc_ntox86++.conf files but just seemed to mess things up further
.  Is there documentation for how to edit qcc configuration files?  Or am I missing some basic option that will resolve 
my problem.

Thanks in advance for any help

-Bob



Re: standard c++ include directories / changing options specified in qcc .conf files  
Bob Barcklay wrote:
> Hi,
> 
> I am attempting to build a third party library (libkml) using a configure script and qcc from the 6.3.2 IDE.  I invoke
 configure like this:
> 
> $QCC -V3.3.5,gcc_ntox86 -set-default
> $CXX=QCC CC=qcc ./configure --host=i386-pc-nto-qnx6.3.0 CXXFLAGS='-g -O0 -lang-c++ -v'
> 
> After building a number of sources successfully, I get this error:
>       cxxabi.h: No such file or directory
> 
> but this file exists in $QNX_TARGET/usr/include/c++/3.3.5/
> 
> I believe I can resolve the problem by specifying this directory as a -I include but that doesn't seem right.  So I'm 
wondering what is the proper way to tell QCC to include the std c++ include directories?

By default, qcc uses the Dinkumware C++ headers and libraries. If you 
want to use the libstdc++-v3 headers 
($QNX_TARGET/usr/include/c++/3.3.5/) and libraries, you should use the 
qcc -V3.3.5,gcc_ntox86_gpp configuration.

The gcc drivers (e.g. ntox86-gcc, i386-pc-nto-qnx6.3.0-g++, etc) use the 
GNU C++ library.

Regards,

Ryan Mansfield


Re: standard c++ include directories / changing options specified in qcc .conf files  
Thanks Ryan.  Should I be able to set this as my default?  I tried:

qcc -V3.3.5,gcc_ntox86_gpp -set-default

and get the message:

cc: default set to "3.3.5,gcc_ntox86"

the file 'default' in $QNX_HOST/etc/qcc/gcc/3.3.5/ still contains:

CONF=gcc_ntox86

Can I edit this directly?  I tried editing .conf files before and qcc doesn't seem to like it.
Also, are there docs that I should be reading about this?

-Bob
Re: standard c++ include directories / changing options specified in qcc .conf files  
Bob Barcklay wrote:
> Thanks Ryan.  Should I be able to set this as my default?  I tried:
> 
> qcc -V3.3.5,gcc_ntox86_gpp -set-default
> 
> and get the message:
> 
> cc: default set to "3.3.5,gcc_ntox86"
> 
> the file 'default' in $QNX_HOST/etc/qcc/gcc/3.3.5/ still contains:
> 
> CONF=gcc_ntox86

It looks -set-default is dropping the library variant. I'll file a PR 
and fix that.

> Can I edit this directly?  I tried editing .conf files before and qcc doesn't seem to like it.

Yes, you can modify your $QNX_HOST/etc/qcc/gcc/3.3.5/default file to have:

CONF=gcc_ntox86_gpp

> Also, are there docs that I should be reading about this?

The qcc documentation explains the different library variants. However, 
I don't think we have anything describing the internals of the qcc conf 
files.

Regards,

Ryan Mansfield
Re: standard c++ include directories / changing options specified in qcc .conf files  
Just a heads-up: the GNU C++ libraries included in QNX 6.3.x use their own inline assembly spinlocks on x86 platforms to
 protect the reference count in the std::basic_string implementation.  This can result in a deadlock should a higher-
priority thread ever try to access a string locked by a lower-priority thread, since on an RTOS like QNX the lower-
priority thread will never be scheduled to release the lock.

-Will