ORACLE 10.2 Pro*C precompiler not reading header file
Asked Answered
W

8

9

I'm pre-compiling a C program containing Pro*C code with Oracle 10.2 and AIX 5.2

The Oracle precompiler reads the $ORACLE_HOME/precomp/admin/pcscfg.cfg file which contains the definition of the sys_include variable (set to /usr/include).

The Pro*C compiler complains that it doesn't know what the size_t type is and the Oracle header files that use the size_t type are reporting errors.

Here's an example error being reported on the sqlcpr.h file:

extern void sqlglm( char*, size_t*, size_t* );
...........................1
PCC-S-02201, Encountered the symbol "size_t" when expecting one of the following

size_t is defined in the stdio.h header file in the /usr/include directory. I'm including the stdio.h header in my example.pc file before I include the sqlcpr.h header.

I'm issuing the proc command as follows:

proc iname=example parse=full

Any ideas what I'm doing wrong?

Whizbang answered 28/11, 2008 at 13:59 Comment(0)
B
9

From Metalink

PCC-S-02201, Encountered the symbol "size_t" when expecting one of the 
following
:
   ... auto, char, const, double, enum,  float, int, long,
   ulong_varchar, OCIBFileLocator OCIBlobLocator,
   OCIClobLocator, OCIDateTime, OCIExtProcContext, OCIInterval,
   OCIRowid, OCIDate, OCINumber, OCIRaw, OCIString, register,
   short, signed, sql_context, sql_cursor, static, struct,
   union, unsigned, utext, uvarchar, varchar, void, volatile,
   a typedef name, exec oracle, exec oracle begin, exec,
   exec sql, exec sql begin, exec sql type, exec sql var,
The symbol "enum," was substituted for "size_t" to continue.
Syntax error at line 88, column 7, file /usr/include/gconv.h:
Error at line 88, column 7 in file /usr/include/gconv.h
                                  size_t *);

Solution Description

The 'sys_include' and 'include' precompiler options are not set correctly. Set 'sys_include' and 'include' precompiler options in the pcscfg.cfg file located at $ORACLE_HOME/precomp/admin or include on the command line when invoking 'proc'.

For example, here is a recommended way to set the variable properly:

Run the following command to obtain the compiler location:

gcc -v

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux7/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-128)

Use the path returned above (remove specs and replace with include)

sys_include=($ORACLE_HOME/precomp/public,
             /usr/lib/gcc-lib/i386-redhat-linux7/2.96/include, 
             /usr/include)

include=(/u02/app/oracle/product/8.1.5/precomp/public)
include=(/u02/app/oracle/product/8.1.5/rdbms/demo)
include=(/u02/app/oracle/product/8.1.5/network/public)
include=(/u02/app/oracle/product/8.1.5/plsql/public)

I am guessing that the part of having both sysinclude and include is your issue.

Brendon answered 28/11, 2008 at 16:33 Comment(0)
Q
4

You have to make sure that the include search path is setup such that all needed directories are included in the right order by Pro*C.

For example on CentOS 6.5 I specify following order (in the pcscfg.cf):

sys_include=$ORACLE_HOME/sdk/include
sys_include=/usr/include
sys_include=/usr/lib/gcc/x86_64-redhat-linux/4.4.7/include
sys_include=/usr/include/linux
ltype=short
define=__x86_64__

This configuration file is read by proc from $ORACLE_HOME/precomp/admin/pcscfg.cfg.

Apparently, the default file written by the Oracle installer is often suboptimal, because it e.g. lists a non-existing GCC path and/or uses a problematic include path order.

With a different order I get the same size_t related error messages (when permuting the first 4 lines to (1,2,4,3) ).

When permuting the first 4 lines to (1,3,2,4) and including <limits.h>, proc even goes into an memory allocating infinite loop until it is killed by the OOM killer.

As a workaround you can also specify the sys_include option on the proc command line, e.g:

lines=yes \
code=ANSI_C \
sqlcheck=full \
parse=full \
sys_include=$(ORACLE_HOME)/precomp/public \
sys_include=/usr/include \
sys_include=/usr/lib/gcc/x86_64-redhat-linux/4.4.7/include \
sys_include=/usr/include/linux
Quill answered 1/5, 2013 at 19:22 Comment(0)
C
1

Two thing worth noting when I playing with my pcscfg.cfg file.

1 Remember it doesn't support "space", so any path including space should be written in "short" style. e.g.: SYS_INCLUDE=D:\Progra~1\Micros~1.0\VC\include You can use dir /x in windows to get the short version of the names

2 It appears, in my case at least, INCLUDE should be written before all those options stuff. I.E. If

define=(WIN32_LEAN_AND_MEAN)
parse=full
SYS_INCLUDE=D:\Progra~1\Micros~1.0\VC\include

doesn't work, try

define=(WIN32_LEAN_AND_MEAN)
SYS_INCLUDE=D:\Progra~1\Micros~1.0\VC\include
parse=full

Instead.

Colpin answered 25/12, 2012 at 9:21 Comment(0)
U
1

I had the similar issue ("PCC-S-02201, Encountered the symbol ..."). I listened to both pieces of advice above.

  • Check the sys_include and make sure the directory path is the one that compiler is actually is set to use. Defaults used by Pro*C generally do not exist. Compile a 'Hello World' program with gcc -v -c <prog.c> and check COMPILER_PATH
  • I adjusted the order of options and brought sys_include up in the order (not really sure if should matter, but still.)

so the PCC-S-02201 went away.

Univalve answered 7/5, 2013 at 6:15 Comment(0)
T
1

Add one compile flag line to pcscfg.cfg to make Oracle's precompiler compile with no system header file syntax errors:

define=_POSIX_C_SOURCE

That's it. It should now precompile without error.

Thermogenesis answered 1/2, 2017 at 20:21 Comment(1)
thank you very much for this. this worked like a charm! saved my life!Mayramays
R
0

I modified placing /usr/include/linux before everything else. This cleared both the failure to find stddef.h and not knowing what size_t was. Placing it next to /usr/include only fixed the former.

Modified pcscfg.cfg:

sys_include=(/usr/include/linux,$ORACLE_HOME/precomp/public,/usr/include,/usr/lib/gcc/i386-redhat-linux/4.1.1/include,/usr/lib/gcc/i386-redhat-linux/3.4.5/include,/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/include,/usr/lib/gcc/i586-suse-linux/4.1.2/include,/usr/lib/gcc/i586-suse-linux/4.3/include) ltype=short

(CentOS 6.3, oracle 11g)

Reverberatory answered 6/2, 2014 at 4:42 Comment(0)
C
0

Use sys_include for the path containing environment variables or Visual Studio variables. If the path is simple path, use "include", else use "sys_include"

I have this issue on Visual Studio 2013, for compiling .pc files, with the above change, all got worked.

Cultism answered 24/11, 2014 at 22:44 Comment(0)
C
0

I had the same issue:

[me@somesys:~/proC]$ proc sys_include='(/usr/include,/usr/include/linux,/usr/include/c++/4.8.2/x86_64-redhat-linux,/usr/include/c++/4.8.2/tr1,/usr/include/c++/4.8.2)' copy.pc

Pro*C/C++: Release 12.1.0.2.0 - Production on Thu Jun 6 17:47:11 2019

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

System default option values taken from: /oracle/app/oracle/product/12.1.0.2/precomp/admin/pcscfg.cfg

Syntax error at line 307, column 3, file /usr/include/libio.h:
Error at line 307, column 3 in file /usr/include/libio.h
  size_t __pad5;
..1
PCC-S-02201, Encountered the symbol "size_t" when expecting one of the following
:

   } char, const, double, enum, float, int, long, ulong_varchar,
   OCIBFileLocator OCIBlobLocator, OCIClobLocator, OCIDateTime,
   OCIExtProcContext, OCIInterval, OCIRowid, OCIDate, OCINumber,
...

And I did as yogmk suggested:

[me@somesys:~/proC]$ gcc -v -c borrame.c
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.8.5/cc1 -quiet -v borrame.c -quiet -dumpbase borrame.c -mtune=generic -march=x86-64 -auxbase borrame -version -o /tmp/cc2WTuu6.s
GNU C (GCC) version 4.8.5 20150623 (Red Hat 4.8.5-36) (x86_64-redhat-linux)
        compiled by GNU C version 4.8.5 20150623 (Red Hat 4.8.5-36), GMP version 6.0.0, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include
 /usr/local/include
 /usr/include
End of search list.
GNU C (GCC) version 4.8.5 20150623 (Red Hat 4.8.5-36) (x86_64-redhat-linux)
...

But instead of COMPILER_PATH, I copied, in order, the non-empty directories after #include <...> search starts here:, and it worked!

[me@somesys:~/proC]$ proc sys_include='(/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include,/usr/include)' copy.pc

Pro*C/C++: Release 12.1.0.2.0 - Production on Thu Jun 6 17:54:50 2019

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

System default option values taken from: /oracle/app/oracle/product/12.1.0.2/precomp/admin/pcscfg.cfg

[me@somesys:~/proC]$

Hope it helps anyone.

Counteraccusation answered 6/6, 2019 at 23:2 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.