ProC complains about undefined symbols on Linux (CentOS 7.3)

Question

TLDR: Running ProC from Oracle instant client 12.2 on CentOS 7.3 doesn't seem to be able to properly process even a trivial input file.

Minimal input file demonstrating the problem:

EXEC SQL BEGIN DECLARE SECTION;
     EXEC SQL INCLUDE oci.h;
EXEC SQL END DECLARE SECTION;

The real files obviously include my own project's header, but ultimately they pull in oci.h, which is one of the instant client SDK headers and this seems to be where the build issues are coming from.

Invocation of ProC:

The following script demonstrates the problem (again, a cut-down version of the real situation):

#!/bin/sh

export ORACLE_HOME=/some/path/instantclient_12_2
export ORACLE_SID=SomeSID
export PATH=/various/paths:${ORACLE_HOME}:${ORACLE_HOME}/sdk:${ORACLE_HOME}/bin:/some/more/paths/like:usr/bin:
export LD_LIBRARY_PATH=${ORACLE_HOME}:${ORACLE_HOME}/lib32:${ORACLE_HOME}/lib

${ORACLE_HOME}/sdk/proc \
  LTYPE=LONG \
  PARSE=PARTIAL \
  MODE=ORACLE \
  CODE=ANSI_C \
  iname=foo.pc

Oracle configuration:

The contents of my pcscfg.cfg file look like this:

sys_include=/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include
sys_include=/usr/include
include=/some/path/instantclient_12_2/sdk/include

I've also tried various reordering, switching include and sys_include, but all seem to give the same behaviour. Adding define=__x86_64__ as seen in various online references makes no difference. I've chosen to expand out the $ORACLE_PATH in the above to make the example clearer.

Sample error output:

Using the input file defined above results in output with errors like the following (truncated to help focus the discussion):

Pro*C/C++: Release 12.2.0.1.0 - Production on Mon Sep 4 16:19:45 2017

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

System default option values taken from: /some/path/instantclient_12_2/precomp/admin/pcscfg.cfg

Syntax error at line 46, column 1, file /usr/include/bits/byteswap-16.h:
Error at line 46, column 1 in file /usr/include/bits/byteswap-16.h
{
1
PCC-S-02201, Encountered the symbol "{" when expecting one of the following:

   ; , = ( [

The contents around the line it is complaining about look like this:

static __inline unsigned short int
__bswap_16 (unsigned short int __bsx)
{                                       // <---- this is line 46
  return __bswap_constant_16 (__bsx);
}

If I insert #include <stdlib.h> before the EXEC SQL BEGIN DECLARE SECTION line, the error message changes to this:

Syntax error at line 265, column 50, file /some/path/instantclient_12_2/sdk/include/ociextp.h:
Error at line 265, column 50 in file /some/path/instantclient_12_2/sdk/include/ociextp.h
void  *ociepacm(OCIExtProcContext *with_context, size_t amount);
.................................................1
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.

This one is more interesting because I've traced through the logic more carefully and even forcing size_t to be defined by various means, I still get the above error. But if I change the ProC invocation to use PARSE=FULL, it is successful. Unfortunately, that causes other problems with the real code and those problems have a similar nature to this one (i.e. chokes on compiler headers for things that should really have been defined by the compiler headers).

Further comments:

Looking at various solutions online, these issues are normally the result of having incorrectly set include search paths, but I've verified from the output listing that the correct headers are indeed being found. It is as though there are some compiler defines missing that GCC would normally provide but ProC isn't providing. There have been various other related examples which support this theory, giving errors on things like __INT_LEAST8_TYPE__ being unknown (which as far as I can tell GCC defines internally rather than explicitly in any of its headers).

Specific question:

ProC doesn't seem to be processing the system compiler headers correctly. Any idea why or even further things to try to help diagnose the underlying cause?

Answer 1

For me, I fixed this in either of these 2 ways:

Add define=ORASYS_TYPES to ${ORACLE_HOME}/precomp/admin/pcscfg.cfg

or

Add DEFINE=ORASYS_TYPES as an option to proc.

oci.h includes <oratypes.h>

And oratypes.h has:

#ifndef ORASYS_TYPES
# include <sys/types.h>
# define ORASYS_TYPES
#endif

Answer 2

This happens when you include your header with the same name as a system header, which includes stdint.h.

From Pro*C manual:

The precompiler searches directories in the following order:

• the current directory

• the system directory specified in a SYS_INCLUDE precompiler option

• the directories specified by the INCLUDE option, in the order they are entered

• the built-in directories for standard header files

For example, you may create header file db.h for your project.

If you have in your system Berkeley DB installed, then it supplies your system with it's own db.h.

As long as your db.h is situated in the same folder as preprocessed .pc file and you don't have to pass include=your_include_folder option to proc you will be ok.

If you do have separate folder for include files you are obliged to pass include=../include option to proc and Berkeley's db.h comes in place instead of db.h file from your project.

Answer 3

I have been able to get my application to compile correctly, I found that even though some compile problems were resolved by adding the output of the command "gcc -dM -E - < /dev/null" into a header file and including it in every Pro*C source file, new compile problems were introduced because of that and trying to resolve those new problems again introduced others so that approach was going nowhere.

In the end I started again from scratch and only included those #defines that were realy needed by the proc compiler. Also, I had to re-arrange the paths in the proc configuration file ${ORACLE_HOME}/precomp/admin/pcscfg.cfg

This is what it looks like now:

sys_include=$ORACLE_HOME/precomp/public
sys_include=/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include
sys_include=/usr/local/include
sys_include=/usr/include
sys_include=/usr/include/linux
ltype=short
define=__x86_64__

the reason for this is that there are several files located in the gcc include directory that are also present in some of the other directories, but those assume that all of those gcc internal defines are set as well. The system include files located in the gcc include directory sometimes differ significantly from the ones in the usual include directories that are listed below it and it would seem that proc has a lot less difficulties in parsing the ones located in the gcc 4.8.5 directory.

Next to this, the include file I created and #include into every source file proc choked on now looks this:

#ifndef __GCC4_INTERNAL_DEFINES_H__
#define __GCC4_INTERNAL_DEFINES_H__

/* Proceed only when using the Oracle Pro*C compiler on RHEL7 */
#ifdef DB_PRE_COMP
#ifdef OS_IS_RHEL7

/* These are some of the defines that gcc4 sets by itself. The Pro*C precompiler
   does not know them and they are needed in order to correctly parse several
   system header files. Full list of gcc4 internal defines may be obtained with
   the following command: gcc -dM -E - < /dev/null */
#define __INT_LEAST8_TYPE__ signed char
#define __INT_LEAST16_TYPE__ short int
#define __INT_LEAST32_TYPE__ int
#define __INT_LEAST64_TYPE__ long int
#define __UINT_LEAST8_TYPE__ unsigned char
#define __UINT_LEAST16_TYPE__ short unsigned int
#define __UINT_LEAST32_TYPE__ unsigned int
#define __UINT_LEAST64_TYPE__ long unsigned int
#define __INT_FAST8_TYPE__ signed char
#define __INT_FAST16_TYPE__ long int
#define __INT_FAST32_TYPE__ long int
#define __INT_FAST64_TYPE__ long int
#define __UINT_FAST8_TYPE__ unsigned char
#define __UINT_FAST16_TYPE__ long unsigned int
#define __UINT_FAST32_TYPE__ long unsigned int
#define __UINT_FAST64_TYPE__ long unsigned int
#define __INTMAX_TYPE__ long int
#define __UINTMAX_TYPE__ long unsigned int

#include </usr/include/stdint.h>

#endif /* OS_IS_RHEL7 */
#endif /* DB_PRE_COMP */

#endif /* __GCC4_INTERNAL_DEFINES_H__ */

Much to my relief, I got everything to compile again with these updates. For completeness sake, proc is executed with the parse=full option, this is what I used to do under RHEL6 as well and what my application apparently needs; as part of my efforts to get it to compile I tried with partial option as well but that did not make a difference, it still choked.