configure script fails to detect oracle headers path on Oracle Linux 7

[mailinglists35]

the configure script only searches $ORACLE_HOME/rdbms/public and $ORACLE_HOME/rdbms/demo and fails to find the path:

[...]
checking for Oracle OCI headers location... configure: error: variable not set or unable to guess

currently to compile under OL7 (with latest updates) it needs to have argument --with-oracle-headers-path=/usr/include/oracle/21/client64

the script should also try to parse rpm output about installed oracle-instantclient-devel package, which can result in finding oracle-headers-path at /usr/include/oracle/*/client64

the rdbms paths appear to originate from oracle documentation about demonstrative programs, however in practice nobody has these folders installed. instead, rpm packages are available from official oracle repositories.

[user@host ocilib-4.7.4]$ yum list installed oracle-i\*
Loaded plugins: ulninfo, versionlock
Installed Packages
oracle-instantclient-basic.x86_64                    21.7.0.0.0-1  @ol7_oracle_instantclient21
oracle-instantclient-devel.x86_64                   21.7.0.0.0-1 @ol7_oracle_instantclient21
oracle-instantclient-release-el7.x86_64          1.0-3.el7  @ol7_latest

[user@host ocilib-4.7.4]$ grep ol7_oracle_instantclient21 /etc/yum.repos.d/*
/etc/yum.repos.d/oracle-instantclient-ol7.repo:[ol7_oracle_instantclient21]

[user@host ocilib-4.7.4]$ rpm -qf /etc/yum.repos.d/oracle-instantclient-ol7.repo
oracle-instantclient-release-el7-1.0-3.el7.x86_64

[user@host ocilib-4.7.4]$ rpm -ql oracle-instantclient-devel
/usr/include/oracle
/usr/include/oracle/21
/usr/include/oracle/21/client64
/usr/include/oracle/21/client64/jzndom.h
/usr/include/oracle/21/client64/jznerr.h
/usr/include/oracle/21/client64/jznev.h
/usr/include/oracle/21/client64/jznotn.h
/usr/include/oracle/21/client64/jzntypes.h
/usr/include/oracle/21/client64/ldap.h
/usr/include/oracle/21/client64/nzerror.h
/usr/include/oracle/21/client64/nzt.h
/usr/include/oracle/21/client64/occi.h
/usr/include/oracle/21/client64/occiAQ.h
/usr/include/oracle/21/client64/occiCommon.h
/usr/include/oracle/21/client64/occiControl.h
/usr/include/oracle/21/client64/occiData.h
/usr/include/oracle/21/client64/occiObjects.h
/usr/include/oracle/21/client64/oci.h
/usr/include/oracle/21/client64/oci1.h
/usr/include/oracle/21/client64/oci8dp.h
/usr/include/oracle/21/client64/ociap.h
/usr/include/oracle/21/client64/ociapr.h
/usr/include/oracle/21/client64/ocidef.h
/usr/include/oracle/21/client64/ocidem.h
/usr/include/oracle/21/client64/ocidfn.h
/usr/include/oracle/21/client64/ociextp.h
/usr/include/oracle/21/client64/ocijson.h
/usr/include/oracle/21/client64/ocikpr.h
/usr/include/oracle/21/client64/ociver.h
/usr/include/oracle/21/client64/ocixmldb.h
/usr/include/oracle/21/client64/ocixstream.h
/usr/include/oracle/21/client64/odci.h
/usr/include/oracle/21/client64/orajson.h
/usr/include/oracle/21/client64/oratypes.h
/usr/include/oracle/21/client64/ori.h
/usr/include/oracle/21/client64/orid.h
/usr/include/oracle/21/client64/orl.h
/usr/include/oracle/21/client64/oro.h
/usr/include/oracle/21/client64/ort.h
/usr/include/oracle/21/client64/xa.h
/usr/lib/oracle
/usr/lib/oracle/21
/usr/lib/oracle/21/client64
/usr/lib/oracle/21/client64/lib
/usr/lib/oracle/21/client64/lib/ottclasses.zip
/usr/share/oracle
/usr/share/oracle/21
/usr/share/oracle/21/client64
/usr/share/oracle/21/client64/admin
/usr/share/oracle/21/client64/admin/oraaccess.xsd
/usr/share/oracle/21/client64/demo
/usr/share/oracle/21/client64/demo/cdemo81.c
/usr/share/oracle/21/client64/demo/demo.mk
/usr/share/oracle/21/client64/demo/occidemo.sql
/usr/share/oracle/21/client64/demo/occidemod.sql
/usr/share/oracle/21/client64/demo/occidml.cpp
/usr/share/oracle/21/client64/demo/occiobj.cpp
/usr/share/oracle/21/client64/demo/occiobj.typ
/usr/share/oracle/21/client64/demo/oraaccess.xml
/usr/share/oracle/21/client64/demo/ott
/usr/share/oracle/21/client64/demo/setuporamysql.sh
/usr/share/oracle/21/client64/doc
/usr/share/oracle/21/client64/doc/SDK_LICENSE
/usr/share/oracle/21/client64/doc/SDK_README

[vrogier]

Hi,

Autodetecting oracle assets location had never been a feature but rather a best effort.
When OCILIB had been first released about 15 years ago, Oracle 8/9/10 was the norm and it was not delivered as npm packages.
NPM is also not available on all possible environment supported by Oracle.
That's why I never enhanced configure scripts to auto detect oracle location from npm packages.
And I kept it simple and instead relied on the configure options --with-oracle-headers-path and --with-oracle-lib-path to handle Oracle assets locations.
You may have several oracle packages installed that contains their own sets of include files and libraries.
We can have possible mismatch between headers files and library path locations from different packages.
Also in your example, it is about client packages only. What if you've got the full server installed instead ?

Thus, taking all of these parameters (different target environments, different Oracle versions, client/server distribution, different distribution primitives like rpm, installers, …), trying to have an universal auto detect mechanism seems to me not easy at all and requires time and effort. Important investment and very low benefit. Thus not a priority.

You're welcome to propose an autodetect implementation from configure script that handle server installs and client (multiple) distributions that works on all non Windows environments supported by Oracle : Linux, HP/UX, AIX, MacOS, OpenVMS.

Good luck :)

Regards,

Vincent

[cjbj]

If anyone picks this task up, PHP OCI8 could be an example to look at https://github.com/php/php-src/blob/master/ext/oci8/config.m4 (or older versions).

[mailinglists35]

Hi,

Autodetecting oracle assets location had never been a feature but rather a best effort. When OCILIB had been first released about 15 years ago, Oracle 8/9/10 was the norm and it was not delivered as npm packages. NPM is also not available on all possible environment supported by Oracle. That's why I never enhanced configure scripts to auto detect oracle location from npm packages. And I kept it simple and instead relied on the configure options --with-oracle-headers-path and --with-oracle-lib-path to handle Oracle assets locations. You may have several oracle packages installed that contains their own sets of include files and libraries. We can have possible mismatch between headers files and library path locations from different packages. Also in your example, it is about client packages only. What if you've got the full server installed instead ?

Thus, taking all of these parameters (different target environments, different Oracle versions, client/server distribution, different distribution primitives like rpm, installers, …), trying to have an universal auto detect mechanism seems to me not easy at all and requires time and effort. Important investment and very low benefit. Thus not a priority.

You're welcome to propose an autodetect implementation from configure script that handle server installs and client (multiple) distributions that works on all non Windows environments supported by Oracle : Linux, HP/UX, AIX, MacOS, OpenVMS.

Good luck :)

Regards,

Vincent

About the multiple paths, I believe it is normally impossible to install multiple versions for the same client devel packages - the rpm package manager would not allow it.

Anyway, my point was that trying to match /usr/include/oracle/*/client64 is much close to real life setups than trying to match $ORACLE_HOME/rdbms/public. Got multiple matches? fail and warn the user. Or at least remove it completely until a totally satisfying solution is agreed, and instruct users to rely on explicit configure --with-oracle-headers-path= option.

I've posted this in the hope is going to be helpful to others, to point that the autodetection will most likely always fail since it only looks for a demonstrative app that most likely nobody is going to install on production machines, as well as to suggest a high probability location.