gcc environment variable wierdness

QNX Newsgroups (Archives) qdn.public.qnxrtp.devtools
1

I’ve been trying to get “gcc” to look in user-specified
directories for include files, using the environment variables
“CPATH”, “C_INCLUDE_PATH”, and “CPLUS_INCLUDE_PATH”. Those
variables seem to have no effect. I tested this with

C_INCLUDE_PATH=/usr/local/include
export C_INCLUDE_PATH
gcc test.c

where “test.c” consisted of nothing but an include
of a file in /usr/local/include.

I’ve also tried setting CPATH and CPLUS_INCLUDE_PATH.
No effect.

Using “gcc -I/usr/local/include test.c” works fine.
I don’t want to do it that way, though, because I’m trying
to build some Linux packages with complicated configure
scripts, and don’t want to modify their build system.

gcc is 2.95.3, as supplied with QNX 6.20 NC.

John Nagle
Animats

2

Often you can pass in extra include paths to the ./configure script itself.

chris


John Nagle <nagle@downside.com> wrote:

I’ve been trying to get “gcc” to look in user-specified
directories for include files, using the environment variables
“CPATH”, “C_INCLUDE_PATH”, and “CPLUS_INCLUDE_PATH”. Those
variables seem to have no effect. I tested this with

C_INCLUDE_PATH=/usr/local/include
export C_INCLUDE_PATH
gcc test.c

where “test.c” consisted of nothing but an include
of a file in /usr/local/include.

I’ve also tried setting CPATH and CPLUS_INCLUDE_PATH.
No effect.

Using “gcc -I/usr/local/include test.c” works fine.
I don’t want to do it that way, though, because I’m trying
to build some Linux packages with complicated configure
scripts, and don’t want to modify their build system.

gcc is 2.95.3, as supplied with QNX 6.20 NC.

John Nagle
Animats

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

3

You’re answering tech support messages late at night
on a Saturday? I’m impressed. Thank you.

There are workarounds, but I’m just puzzled that
“gcc” on QNX seems to be ignoring its standard
environment variables. Is that known not to work,
or is there something special I need to do to
make it work?

[What I’m doing, incidentally, is bringing up
the OpenCV computer vision library up on QNX.]

John Nagle
Animats

Chris McKillop wrote:

Often you can pass in extra include paths to the ./configure script itself.

chris


John Nagle <> nagle@downside.com> > wrote:

I’ve been trying to get “gcc” to look in user-specified
directories for include files, using the environment variables
“CPATH”, “C_INCLUDE_PATH”, and “CPLUS_INCLUDE_PATH”. Those
variables seem to have no effect. I tested this with

C_INCLUDE_PATH=/usr/local/include
export C_INCLUDE_PATH
gcc test.c

where “test.c” consisted of nothing but an include
of a file in /usr/local/include.

I’ve also tried setting CPATH and CPLUS_INCLUDE_PATH.
No effect.

Using “gcc -I/usr/local/include test.c” works fine.
I don’t want to do it that way, though, because I’m trying
to build some Linux packages with complicated configure
scripts, and don’t want to modify their build system.

gcc is 2.95.3, as supplied with QNX 6.20 NC.

John Nagle
Animats

4

Definatly is busted on 6.2.0 but is working on 6.2.1. If you have our
commerical product and meet the requirements you could probably try signing
up for the 6.2.1 beta: http://www.qnx.com/newsletter/.

chris


John Nagle <nagle@downside.com> wrote:

You’re answering tech support messages late at night
on a Saturday? I’m impressed. Thank you.

There are workarounds, but I’m just puzzled that
“gcc” on QNX seems to be ignoring its standard
environment variables. Is that known not to work,
or is there something special I need to do to
make it work?

[What I’m doing, incidentally, is bringing up
the OpenCV computer vision library up on QNX.]

John Nagle
Animats

Chris McKillop wrote:

Often you can pass in extra include paths to the ./configure script itself.

chris


John Nagle <> nagle@downside.com> > wrote:

I’ve been trying to get “gcc” to look in user-specified
directories for include files, using the environment variables
“CPATH”, “C_INCLUDE_PATH”, and “CPLUS_INCLUDE_PATH”. Those
variables seem to have no effect. I tested this with

C_INCLUDE_PATH=/usr/local/include
export C_INCLUDE_PATH
gcc test.c

where “test.c” consisted of nothing but an include
of a file in /usr/local/include.

I’ve also tried setting CPATH and CPLUS_INCLUDE_PATH.
No effect.

Using “gcc -I/usr/local/include test.c” works fine.
I don’t want to do it that way, though, because I’m trying
to build some Linux packages with complicated configure
scripts, and don’t want to modify their build system.

gcc is 2.95.3, as supplied with QNX 6.20 NC.

John Nagle
Animats

\

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

5

Chris McKillop wrote:

Definitely is busted on 6.2.0, but is working on 6.2.1. If you have our
commercial product and meet the requirements, you could probably try signing
up for the 6.2.1 beta: > http://www.qnx.com/newsletter/> .

chris

OK, thanks. Good to know that it really is a bug.
I found a workaround for my problem; I put the include filenames
into the “compile options” parameter of the
config file. I’m trying to get to a February demo using the
NC product, but at that point may want to buy the commercial
version.

Is there a “what’s nonstandard about QNX’s version of
gcc” tech note? One would be helpful. So far, I’ve
discovered the following:

– Exceptions silently default to off. GCC normally
generates exception code for all .cpp files.
“-fexceptions” is needed to turn them on.

– A few of the include files are in nonstandard places,
even though they don’t seem to need to be. This
includes “new”, “new.h”, and some of the STL files.

– As mentioned, some of the usual environment variables don’t
seem to be recognized by the compiler.

– The “setjmp” structure (for “longjump”) is defined as an
anonymous structure. Some existing code assumes
otherwise.

– “sqrt” is not defined for type “int”. Some existing code
assumes otherwise.

Are more differences known? Thanks.

John Nagle
Animats


John Nagle <> nagle@downside.com> > wrote:

You’re answering tech support messages late at night
on a Saturday? I’m impressed. Thank you.

There are workarounds, but I’m just puzzled that
“gcc” on QNX seems to be ignoring its standard
environment variables. Is that known not to work,
or is there something special I need to do to
make it work?

[What I’m doing, incidentally, is bringing up
the OpenCV computer vision library up on QNX.]

John Nagle
Animats

Chris McKillop wrote:


Often you can pass in extra include paths to the ./configure script itself.

chris


John Nagle <> nagle@downside.com> > wrote:


I’ve been trying to get “gcc” to look in user-specified
directories for include files, using the environment variables
“CPATH”, “C_INCLUDE_PATH”, and “CPLUS_INCLUDE_PATH”. Those
variables seem to have no effect. I tested this with

C_INCLUDE_PATH=/usr/local/include
export C_INCLUDE_PATH
gcc test.c

where “test.c” consisted of nothing but an include
of a file in /usr/local/include.

I’ve also tried setting CPATH and CPLUS_INCLUDE_PATH.
No effect.

Using “gcc -I/usr/local/include test.c” works fine.
I don’t want to do it that way, though, because I’m trying
to build some Linux packages with complicated configure
scripts, and don’t want to modify their build system.

gcc is 2.95.3, as supplied with QNX 6.20 NC.

John Nagle
Animats
\

6

– Exceptions silently default to off. GCC normally
generates exception code for all .cpp files.
“-fexceptions” is needed to turn them on.

That is only the case with the GNU C++ library and driver. If you use the
dinkum libs (commerical only) then they are on by default. I suspect it is
probably legacy where exceptions where not working properly and so they
got turned off in our config files.

– A few of the include files are in nonstandard places,
even though they don’t seem to need to be. This
includes “new”, “new.h”, and some of the STL files.

Non-standard in what way? They are all in the default search paths for
the compiler. You have to realize we support two totally different C++
library setups, so the headers have to be kept separate so that a
single machine can have mulitple versions of multiple libraries installed
and useable.

– The “setjmp” structure (for “longjump”) is defined as an
anonymous structure. Some existing code assumes
otherwise.

This isn’t a gcc thing but just how it is defined on QNX. Existing code
that looks inside of that structure is broken. Much the same as code
that looks inside of the FILE structure is broken.

– “sqrt” is not defined for type “int”. Some existing code
assumes otherwise.

I don’t belive it is ever defined for type int, it is always double’s.
Even looking thru headers on a Linux box I don’t see anything defined
for type int. This sounds like more broken code.

chris

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

7

I’m not complaining. I’m just noting the problems
I find as I port the Open Computer Vision Library to
QNX. I like to get problems like this on the record, so
others can find them by searching, and so that there’s
some hope of getting them fixed. I’m sending in bug
reports and fixes to the SourceForge project that supports
that library, and eventually, I expect that it will
build for QNX without modifications. Almost everything
that’s giving porting trouble is bad code, anyway.

I’m surprised at how easy it’s been to
port most Linux code to QNX. It’s just that now I’m porting
some code that has more system dependencies that it really
needs, so I’m exploring some of the darker corners of
gcc and Posix compatibility.

Chris McKillop wrote:

– A few of the include files are in nonstandard places,
even though they don’t seem to need to be. This
includes “new”, “new.h”, and some of the STL files.

Non-standard in what way? They are all in the default search paths for
the compiler.

Actually, “new” and “new.h” don’t seem to be in the
default search path for the gcc compiler. I’ve needed to
specify

-I/usr/include/g+±3
-I/usr/ntox86/include
-I/usr/lib/gcc-lib/ntox86/2.95.3/include

to get new, new.h, and the less-used STL files.


– The “setjmp” structure (for “longjump”) is defined as an
anonymous structure. Some existing code assumes
otherwise.

This isn’t a gcc thing but just how it is defined on QNX. Existing code
that looks inside of that structure is broken. Much the same as code
that looks inside of the FILE structure is broken.

Agreed. For some reason, though, QNX’s GCC won’t allow
the return of a reference to a jmp_buf structure, because it’s
an anonymous struct. I’m not yet sure whether that’s a valid rule
GCC is enforcing or not.

The right solution, of course, is to remove all the archaic
“longjmp” calls from the C++ code I’m porting, and use exceptions.

Onward.

John Nagle
Animats

8

Actually, “new” and “new.h” don’t seem to be in the
default search path for the gcc compiler. I’ve needed to
specify

-I/usr/include/g+±3
-I/usr/ntox86/include
-I/usr/lib/gcc-lib/ntox86/2.95.3/include

to get new, new.h, and the less-used STL files.

Junky. We are starting to run the gcc/g++ drivers into more tests to
keep this from happening. In the meantime (and in the future), I would
use the qcc and QCC drivers.

QCC -Vgcc_ntox86_gpp …

rather then…

gcc/g++ …

You should be able to set the CC and CXX macros pretty easily.

chris

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

9

OK, thanks.

John Nagle
Animats

Chris McKillop wrote:

Actually, “new” and “new.h” don’t seem to be in the
default search path for the gcc compiler. I’ve needed to
specify

-I/usr/include/g+±3
-I/usr/ntox86/include
-I/usr/lib/gcc-lib/ntox86/2.95.3/include

to get new, new.h, and the less-used STL files.



Junky. We are starting to run the gcc/g++ drivers into more tests to
keep this from happening. In the meantime (and in the future), I would
use the qcc and QCC drivers.

QCC -Vgcc_ntox86_gpp …

rather then…

gcc/g++ …

You should be able to set the CC and CXX macros pretty easily.

chris