Project Home
Project Home		 Trackers
Trackers		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Community/Discussion/QNX Momentics Community Support/"public.h" or similarly named header file in project results in errors compiling/List of Posts
Forum Topic - "public.h" or similarly named header file in project results in errors compiling: (3 Items)
   
Update
Eric Fausett
03/10/2010 7:01 AM
post49151
"public.h" or similarly named header file in project results in errors compiling   
I suspect the root issue has to do with a possible name collision somewhere inside the QNX recursive make system, but 
would like to find out for sure.

Using the 4.6 IDE if I create a 'QNX C Project' and add a header file named public.h (or even public1.h) and include 
this header in say main.c, errors are seen during compile:
---
C:\QNX641\host\win32\x86\usr\bin\make -k all --file=C:/DOCUME~1/efausett/LOCALS~1/Temp/QMakefile126822197273414112.tmp 
C:/QNX641/host/win32/x86/usr/bin/make -j 1 -Cx86 -fMakefile all
make[1]: Entering directory `C:/ws46/test/x86'
C:/QNX641/host/win32/x86/usr/bin/make -j 1 -Co -fMakefile all 
make[2]: Entering directory `C:/ws46/test/x86/o'
C:/QNX641/host/win32/x86/usr/bin/qcc -Vgcc_ntox86 -c -Wc,-Wall -Wc,-Wno-parentheses  -O          -DNDEBUG   -I. -IC:/
ws46/test/x86/o -IC:/ws46/test/x86 -IC:/ws46/test -IC:/ws46/test/public1.h -IC:/QNX641/target/qnx6/usr/include     -
DBUILDENV_qss  C:/ws46/test/test.c 
cc1: error: C:/ws46/test/public1.h: not a directory
cc: C:/QNX641/host/win32/x86/usr/lib/gcc/i386-pc-nto-qnx6.4.0/4.3.3/cc1 caught signal 1
make[2]: *** [test.o] Error 1
make[2]: Target `all' not remade because of errors.
make[2]: Leaving directory `C:/ws46/test/x86/o'
make[1]: [all] Error 2 (ignored)
C:/QNX641/host/win32/x86/usr/bin/make -j 1 -Co-g -fMakefile all
make[2]: Entering directory `C:/ws46/test/x86/o-g'
C:/QNX641/host/win32/x86/usr/bin/qcc -Vgcc_ntox86 -c -Wc,-Wall -Wc,-Wno-parentheses               -I. -IC:/ws46/test/x86
/o -IC:/ws46/test/x86/o-g -IC:/ws46/test/x86 -IC:/ws46/test -IC:/ws46/test/public1.h -IC:/QNX641/target/qnx6/usr/include
    -g    -DVARIANT_g -DBUILDENV_qss  C:/ws46/test/test.c 
cc1: error: C:/ws46/test/public1.h: not a directory
cc: C:/QNX641/host/win32/x86/usr/lib/gcc/i386-pc-nto-qnx6.4.0/4.3.3/cc1 caught signal 1
make[2]: Leaving directory `C:/ws46/test/x86/o-g'
make[2]: *** [test.o] Error 1
make[2]: Target `all' not remade because of errors.
make[1]: [all] Error 2 (ignored)
make[1]: Leaving directory `C:/ws46/test/x86'
---

This seems to be due to the extra "-IC:/ws46/test/public1.h" that is part of the qcc command generated by make.  I've 
verified that the same problem occurs from a command line build of the same project.

Note that a file like "mypublic1.h" does NOT generate this error, while "public1.h" does.

- Can someone tell my why this is occuring?

- Is there any work around besides NOT starting the name of any header file with the special keyword 'public'?

Regards,

Eric
Gunter Geigemueller
05/10/2010 6:57 AM
post54023
Re: "public.h" or similarly named header file in project results in errors compiling   
I fear it has to do with the recursive parsing of the files in the build directory. If you create a folder named "public
" in the procect directory, then it will be added to the include path automatically. Moreover, if you do a "make install
", its contents (supposedly header files) will get copied to $INSTALL_ROOT_nto/usr/include, so this is a good feature. 
From your observations it seems that the scripts that do the scanning have two properties:
1) They do a "starts with" on the file names
2) make no distincion whether the file is a regular file or a directory

At least the second point could be considered a bug. Maybe you have a look at the various *.mk files. I wonder what 
happens if you create a FOLDER named "xxx.c" - would the system try to compile it and bail out with "is a directory"?

-Albrecht
Eric Fausett
05/17/2010 12:51 AM
post54824
Re: "public.h" or similarly named header file in project results in errors compiling   
Gunter, All,

I did find a resolution to this issue for 6.4.0 and 6.4.1, but forgot to post the details about it back here.

A possible solution for this issue which has been tested and shown to work is to  remove the asterisks (wild-card 
characters) from both paths in the defpublic_invcpath definition. The file located on a 6.4.0 Windows environment at C:\
QNX640\target\qnx6\usr\include\mk\qmacros.mk can thus be altered.

This seems to resolve this issue in 6.4.0 and 6.4.1.

I've understand that these asterisks (wild-card characters) are unneeded under make 3.81, and everything should work 
fine without them on *nix versions of make as old as 3.75.

6.4.1 uses make 3.81
6.4.0 uses make 3.80

Regards,

Eric

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems