DevOps, CI/CD and Automation

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Cannot enable OCI8 on Linux

Moazzam-OCAug 13 2017 — edited Aug 14 2017

Hi All,

Cannot enable OCI8 after following steps mentioned in below document.

http://www.oracle.com/technetwork/articles/technote-php-instant-084410.html

Linux version - Red Hat Enterprise Linux Server release 6.9

PHP – 5.3

Server version: Apache/2.2.15 (Unix)

Oracle Instant client – 11.2.0.4

oracle-instantclient11.2-basic-11.2.0.4.0-1.x86_64.rpm

oracle-instantclient11.2-devel-11.2.0.4.0-1.x86_64.rpm

--------------------------------------

# pecl install oci8-2.0.12 --with-oci8=instantclient,/usr/lib/oracle/11.2/client64/lib

Attempting to discover channel "--with-oci8=instantclient,/usr/lib/oracle/11.2/client64"...

Attempting fallback to https instead of http on channel "--with-oci8=instantclient,/usr/lib/oracle/11.2/client64"...

unknown channel "--with-oci8=instantclient,/usr/lib/oracle/11.2/client64" in "--with-oci8=instantclient,/usr/lib/oracle/11.2/client64/lib"

invalid package name/package file "--with-oci8=instantclient,/usr/lib/oracle/11.2/client64/lib"

downloading oci8-2.0.12.tar ...

Starting to download oci8-2.0.12.tar (1,615,360 bytes)

.....................................................................................................................................................................................................................................................................................done: 1,615,360 bytes

11 source files, building

running: phpize

Configuring for:

PHP Api Version: 20121113

Zend Module Api No: 20121212

Zend Extension Api No: 220121212

Please provide the path to the ORACLE_HOME directory. Use 'instantclient,/path/to/instant/client/lib' if you're compiling with Oracle Instant Client [autodetect] :

building in /tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12

running: /tmp/pear/temp/oci8/configure --with-php-config=/usr/local/bin/php-config --with-oci8

checking for grep that handles long lines and -e... /bin/grep

checking for egrep... /bin/grep -E

checking for a sed that does not truncate output... /bin/sed

checking for cc... cc

checking for C compiler default output file name... a.out

checking whether the C compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables...

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether cc accepts -g... yes

checking for cc option to accept ISO C89... none needed

checking how to run the C preprocessor... cc -E

checking for icc... no

checking for suncc... no

checking whether cc understands -c and -o together... yes

checking for system library directory... lib

checking if compiler supports -R... no

checking if compiler supports -Wl,-rpath,... yes

checking build system type... x86_64-unknown-linux-gnu

checking host system type... x86_64-unknown-linux-gnu

checking target system type... x86_64-unknown-linux-gnu

checking for PHP prefix... /usr/local

checking for PHP includes... -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib

checking for PHP extension directory... /usr/local/lib/php/extensions/no-debug-non-zts-20121212

checking for PHP installed headers prefix... /usr/local/include/php

checking if debug is enabled... no

checking if zts is enabled... no

checking for re2c... no

configure: WARNING: You will need re2c 0.13.4 or later if you want to regenerate PHP parsers.

checking for gawk... gawk

checking for Oracle Database OCI8 support... yes, shared

checking PHP version... 5.5.38, ok

checking OCI8 DTrace support... no

checking size of long int... 8

checking checking if we're on a 64-bit platform... yes

configure: WARNING: OCI8 extension: ORACLE_HOME is not set, looking for default Oracle Instant Client instead

checking Oracle Instant Client directory... /usr/lib/oracle/11.2/client64/lib

checking Oracle Instant Client SDK header directory... /usr/include/oracle/11.2/client64

checking Oracle Instant Client library version compatibility... 11.1

checking for ld used by cc... /usr/bin/ld

checking if the linker (/usr/bin/ld) is GNU ld... yes

checking for /usr/bin/ld option to reload object files... -r

checking for BSD-compatible nm... /usr/bin/nm -B

checking whether ln -s works... yes

checking how to recognize dependent libraries... pass_all

checking dlfcn.h usability... yes

checking dlfcn.h presence... yes

checking for dlfcn.h... yes

checking the maximum length of command line arguments... 1572864

checking command to parse /usr/bin/nm -B output from cc object... ok

checking for objdir... .libs

checking for ar... ar

checking for ranlib... ranlib

checking for strip... strip

checking if cc supports -fno-rtti -fno-exceptions... no

checking for cc option to produce PIC... -fPIC

checking if cc PIC flag -fPIC works... yes

checking if cc static flag -static works... no

checking if cc supports -c -o file.o... yes

checking whether the cc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes

checking whether -lc should be explicitly linked in... no

checking dynamic linker characteristics... GNU/Linux ld.so

checking how to hardcode library paths into programs... immediate

checking whether stripping libraries is possible... yes

checking if libtool supports shared libraries... yes

checking whether to build shared libraries... yes

checking whether to build static libraries... no

creating libtool

appending configuration tag "CXX" to libtool

configure: creating ./config.status

config.status: creating config.h

running: make

/bin/sh /tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/libtool --mode=compile cc -I. -I/tmp/pear/temp/oci8 -DPHP_ATOM_INC -I/tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/include -I/tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/main -I/tmp/pear/temp/oci8 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib -I/usr/include/oracle/11.2/client64 -DHAVE_CONFIG_H -g -O2 -c /tmp/pear/temp/oci8/oci8.c -o oci8.lo

mkdir .libs

cc -I. -I/tmp/pear/temp/oci8 -DPHP_ATOM_INC -I/tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/include -I/tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/main -I/tmp/pear/temp/oci8 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib -I/usr/include/oracle/11.2/client64 -DHAVE_CONFIG_H -g -O2 -c /tmp/pear/temp/oci8/oci8.c -fPIC -DPIC -o .libs/oci8.o

/bin/sh /tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/libtool --mode=link cc -DPHP_ATOM_INC -I/tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/include -I/tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/main -I/tmp/pear/temp/oci8 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib -I/usr/include/oracle/11.2/client64 -DHAVE_CONFIG_H -g -O2 -o oci8.la -export-dynamic -avoid-version -prefer-pic -module -rpath /tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/modules oci8.lo oci8_lob.lo oci8_statement.lo oci8_collection.lo oci8_interface.lo -Wl,-rpath,/usr/lib/oracle/11.2/client64/lib -L/usr/lib/oracle/11.2/client64/lib -lclntsh

cc -shared .libs/oci8.o .libs/oci8_lob.o .libs/oci8_statement.o .libs/oci8_collection.o .libs/oci8_interface.o -L/usr/lib/oracle/11.2/client64/lib -lclntsh -Wl,-rpath -Wl,/usr/lib/oracle/11.2/client64/lib -Wl,-soname -Wl,oci8.so -o .libs/oci8.so

creating oci8.la

(cd .libs && rm -f oci8.la && ln -s ../oci8.la oci8.la)

/bin/sh /tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/libtool --mode=install cp ./oci8.la /tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/modules

cp ./.libs/oci8.so /tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/modules/oci8.so

cp ./.libs/oci8.lai /tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/modules/oci8.la

PATH="$PATH:/sbin" ldconfig -n /tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/modules

----------------------------------------------------------------------

Libraries have been installed in:

/tmp/pear/temp/pear-build-root2QETxI/oci8-2.0.12/modules

If you ever happen to want to link against installed libraries

in a given directory, LIBDIR, you must either use libtool, and

specify the full pathname of the library, or use the `-LLIBDIR'

flag during linking and do at least one of the following:

- add LIBDIR to the `LD_LIBRARY_PATH' environment variable

during execution

- add LIBDIR to the `LD_RUN_PATH' environment variable

during linking

- use the `-Wl,--rpath -Wl,LIBDIR' linker flag

- have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for

more information, such as the ld(1) and ld.so(8) manual pages.

----------------------------------------------------------------------

Build complete.

Don't forget to run 'make test'.

running: make INSTALL_ROOT="/tmp/pear/temp/pear-build-root2QETxI/install-oci8-2.0.12" install

Installing shared extensions: /tmp/pear/temp/pear-build-root2QETxI/install-oci8-2.0.12/usr/local/lib/php/extensions/no-debug-non-zts-20121212/

running: find "/tmp/pear/temp/pear-build-root2QETxI/install-oci8-2.0.12" | xargs ls -dils

128456 4 drwxr-xr-x. 3 root root 4096 Aug 10 09:21 /tmp/pear/temp/pear-build-root2QETxI/install-oci8-2.0.12

128485 4 drwxr-xr-x. 3 root root 4096 Aug 10 09:21 /tmp/pear/temp/pear-build-root2QETxI/install-oci8-2.0.12/usr

128486 4 drwxr-xr-x. 3 root root 4096 Aug 10 09:21 /tmp/pear/temp/pear-build-root2QETxI/install-oci8-2.0.12/usr/local

128487 4 drwxr-xr-x. 3 root root 4096 Aug 10 09:21 /tmp/pear/temp/pear-build-root2QETxI/install-oci8-2.0.12/usr/local/lib

128488 4 drwxr-xr-x. 3 root root 4096 Aug 10 09:21 /tmp/pear/temp/pear-build-root2QETxI/install-oci8-2.0.12/usr/local/lib/php

128489 4 drwxr-xr-x. 3 root root 4096 Aug 10 09:21 /tmp/pear/temp/pear-build-root2QETxI/install-oci8-2.0.12/usr/local/lib/php/extensions

128490 4 drwxr-xr-x. 2 root root 4096 Aug 10 09:21 /tmp/pear/temp/pear-build-root2QETxI/install-oci8-2.0.12/usr/local/lib/php/extensions/no-debug-non-zts-20121212

128484 488 -rwxr-xr-x. 1 root root 497707 Aug 10 09:21 /tmp/pear/temp/pear-build-root2QETxI/install-oci8-2.0.12/usr/local/lib/php/extensions/no-debug-non-zts-20121212/oci8.so

Build process completed successfully

Installing '/usr/local/lib/php/extensions/no-debug-non-zts-20121212/oci8.so'

install ok: channel://pecl.php.net/oci8-2.0.12

configuration option "php_ini" is not set to php.ini location

You should add "extension=oci8.so" to php.ini

# make test

make: *** No rule to make target `test'. Stop.

# which make

/usr/bin/make

# grep extension= /etc/php.ini

; extension=modulename.extension

; extension=msql.so

; extension=/path/to/extension/msql.so

extension=mysql.so

extension=mysqli.so

extension=oci8.so

# grep extension_dir /etc/php.ini

; extension_dir = "./"

extension_dir="/usr/lib64/php/modules"

;sqlite3.extension_dir =

# ls -ltr /usr/lib64/php/modules

total 3824

-rwxr-xr-x. 1 root root 46840 Oct 3 2016 mcrypt.so

-rwxr-xr-x. 1 root root 83088 Jan 11 2017 zip.so

-rwxr-xr-x. 1 root root 34056 Jan 11 2017 xsl.so

-rwxr-xr-x. 1 root root 46736 Jan 11 2017 xmlwriter.so

-rwxr-xr-x. 1 root root 30096 Jan 11 2017 xmlreader.so

-rwxr-xr-x. 1 root root 33320 Jan 11 2017 wddx.so

-rwxr-xr-x. 1 root root 44368 Jan 11 2017 sqlite3.so

-rwxr-xr-x. 1 root root 261392 Jan 11 2017 phar.so

-rwxr-xr-x. 1 root root 24640 Jan 11 2017 pdo_sqlite.so

-rwxr-xr-x. 1 root root 102456 Jan 11 2017 pdo.so

-rwxr-xr-x. 1 root root 30112 Jan 11 2017 pdo_mysql.so

-rwxr-xr-x. 1 root root 54408 Jan 11 2017 mysql.so

-rwxr-xr-x. 1 root root 136832 Jan 11 2017 mysqli.so

-rwxr-xr-x. 1 root root 36200 Jan 11 2017 json.so

-rwxr-xr-x. 1 root root 328784 Jan 11 2017 gd.so

-rwxr-xr-x. 1 root root 1843120 Jan 11 2017 fileinfo.so

-rwxr-xr-x. 1 root root 170360 Jan 11 2017 dom.so

-rwxr-xr-x. 1 root root 66448 Jan 11 2017 curl.so

-rwxr-xr-x. 1 root root 497707 Aug 10 10:21 oci8.so

---------------------------------

restarted Apache and tested phpinfo.php don't show oci8 enable.

Please let me know if any more steps needs to be performed.

Regards,

Moazzam.

MWaseem

Dear Sir,

         @"Michael Ferrante-Oracle" is below tweet regarding forms 19c.

1 person found this helpful

Dan Andro-Oracle

Answer

Hello,

There won't be a 19c version, the version will be called 12.2.1.4. No official release date has been established.

Regards,

Dan

Marked as Answer by MWaseem · Sep 27 2020

2 people found this helpful

bkmcdaniel

Dan,

There is a lot of confusion, speculation, and misinformation concerning the future of Oracle Forms and associated products. It would be nice if Michael or someone could provide an updated roadmap, MOS document, etc. Even our sales reps and support coordinators have conflicting information.

In 2018, Michael gave a presentation which contained a "Forms Road Map" slide (timeline) that showed "19.1.0.0 Patch Update" targeted for CY19. While that presentation contained the usual warning/disclaimer that the product was for information purposes only, is not a commitment, etc., etc., etc. However, a tweet by Michael also showed a success screen for Fusion Middleware / Forms Services 19.1.0.0.

Regardless of the actual version number attached to the final product, it would be nice to have some details available as to what we can expect to see. Not every organization is capable of applying the next product update without planning, scrutiny, etc. Throw in a timeline (i.e. 1 year to end of support after update) and things get stressful for absolutely everyone involved (i.e. "developer crunch"). A little information here can be a big help for project planning, software life cycle planning, resource management, etc.

According to the Lifetime Support Policy, Oracle Forms and Reports is supported until August 2022 / August 2025. However all other documentation, release notes, roadmaps, articles, presentations, etc. state that Reports is deprecated, 12.2.1.3 is the planned terminal release, reports not to be included with the next version, etc. and that BI Publisher (which a RUL is included with the WLS/Forms license) is the recommended replacement.
1. Will 12.2.1.4/19.x continue to offer support for Oracle Reports?
2. Will 12.2.1.4/19.x offer an installation option for BI Publisher or will it remain a separate download?
It has been stated that there are technical reasons that Oracle Forms 12.2.1.3 cannot be used with the newer releases of Java.
1. Will 12.2.1.4/19.x continue to support Java 8?
2. Will 12.2.1.4/19.x support Java 11 (the LTS release)?
3. Will 12.2.1.4/19.x support both?
Will Forms 12.2.1.4/19.x continue to support JWS or will it be FSAL only? Obviously if there is no support for Java 8, it will have to be FSAL only.
Is the upgrade from 12.2.1.3 to 12.2.1.4/19.x the same as previous "upgrades" or will it be simpler (i.e. more like a true patch)? I understand that things are more complicated due to the underlying WebLogic and FMW Infrastructure.
Not specific to Forms, but an easier path to relocate the WebLogic repository would be nice. There are MOS documents on how to do this but there is a lot of room for error. So, if you could put in an enhancement request that'd be great! Probably 90% of our WLS installations are specifically for OFR.

I know Oracle, like many other companies, has a policy on what can and cannot be said on unreleased products. This is understandable, but it sure would be nice to be able to set management expectations and to be able to prepare them for changes on the horizon.

2 people found this helpful

Holger.Lehmann

I think you'll have to be patient and wait :-)

CY19 is there and even more we don't know :-)

Let OOW come or KScope and perhaps .....

1 person found this helpful

Michael Ferrante-Oracle

@"bkmcdaniel", let me start with this. I have been working with Oracle and specifically the Forms product for a very long time. In that time, neither I or anyone else with the authority to say anything about the Forms product have ever said that Forms was not planned to continue on forward. We may have encouraged users to consider newer technologies when appropriate, but never was it said that the product was at the end of its life. So there should be no "confusion, speculation, and misinformation", as you've stated, if you are listening to those with authority to comment. Problems start when you (the community of product users) take comments from a third party who are trying to sell you something as gospel or manipulate you for some other purpose. I have been in a Product Management role for a long time. In that time, I have done nothing but provide roadmap information and generally good news about the product. So it is unclear how anyone could be confused.

Regarding "Reports", Oracle previously announced the product as being deprecated. This does not necessarily mean it won't be delivered any longer nor does it mean you are no longer entitled to support. It means that Oracle is planning to end its life at some future time and you should not be banking on it being available in the future. It also means that no new updates will be added to it. It will basically be frozen in time beginning with 12.2.1.3. So if Oracle decides to ship it with the next release or any release in the future, likely it would be just like it was in 12.2.1.3, except for changes required to make it compatible with the infrastructure and framework that hosts it. It may (but may not) also include bug fixes that were deemed critical to include. So yes, considering a move to BI-Publisher is likely a good idea if your organization is making significant changes to its current reports and expects to create new ones in the future. That said, Reports 12.2.1.3, like most of the products in the FMW 12.2.1 family are entitled to support based on the published support dates. At this time, there are no plans to change that. So you can choose to remain on Reports for some time, but I would not wait until Aug 2022 (or Extended Support - Aug 2025) to start discussing what you should be doing next. Such discussions should have already started. Note that BI-Publisher is available on-premise, but is also available in Oracle Cloud (Oracle Analytics Cloud). This could be a good match for Oracle Forms in Cloud, which you can do today using Oracle Cloud Infrastructure (OCI- Compute).

Regarding your other comments/questions, beyond what I've said here, i can't say much more. However, what I can say is that some of your desires are being planned for a future release. Exactly which release I cannot say. Also, with regard to continuing support of JWS or removing it from Forms, we have no plans to remove any functionality from Forms while related dependencies are still available and supported. So in the case of JWS, which is planned to be available to Oracle customers who are using supported products (e.g. Forms 12.2.1.x), you should have some kind of JWS support at least until 2025 (and possibly longer). FSAL will be the preferred configuration, although JWS is planned to continue being supported for the foreseeable future, as mentioned.

My recommendation is that if you have a product question (regardless which product or its vendor), you should reach out to someone of authority related to the product owner/vendor. Offer very limited faith in social media and unsubstantiated rumors not communicated by those with authority to comment.

A more official statement can be found in MyOracleSupport Note 2009262.1

It all sounds like mostly good news to me...

2 people found this helpful

bkmcdaniel

In that time, neither I or anyone else with the authority to say anything about the Forms product have ever said that Forms was not planned to continue on forward.

There was no question or concern with that. Oracle has clearly stated that they remain committed to this product. As I stated in my post, the "confusion, speculation, and misinformation concerning the future of Oracle Forms and associated products." As you can see from my post, this mainly hinges on topics such as Java, Reports, and the things that are used in conjunction with Forms itself.

When it comes to Reports, I understand that it is deprecated, at the terminal release, and we shouldn't expect to see new features. To me, I would consider this to be a risk and will continue to be a risk until it is eliminated from our environment. To my management, they see "supported until August 2022." What my management does not understand is what "supported" means when it comes to Oracle products. It means I can submit an SR, it does not guarantee that it will be available with or work with later products. We ran into a similar situation years ago where a security fix was only available in OHS 11.1.1.9, could we upgrade the included OHS 11.1.1.7 with OFR 11.1.2.2? No (Doc ID 1373061.1). But our product was supported. Sure, we could submit an SR to request version compatibility, backport, etc. Such requests are often painful and lengthily to get a resolution. The whole 12.2.1, 12.2.1.1, 12.2.1.2, and 12.2.1.3 has been somewhat similar... technically, according to the Lifetime Support Policy, these are still supported. According to the Error Correction policy, that is a different story (Doc ID 1933372.1). I understand that this is the same process used elsewhere with Oracle - the 12.2/18c/19c database is another prime example of how the support policy says one thing but other documents are needed to get all the other details required to put together the big picture.

Again, my goal is to try and set expectations and keep management informed. MOS documents, statements of direction, and whitepapers are often vague and subject to change without notice (or details of what changed). I don't want my organization to be in a situation where they are planning to be done by X date, only to have a security situation that requires a patch/update specific to a particular version that is sans features still being used. When we ask such questions of our Oracle reps (sales or otherwise) we receive conflicting information from them or information that contradicts published documents. That's why the questions are put here, to hopefully get as much information as possible from those of authority, like you.

I'm in a situation where I cannot provide the information to management to get them to prioritize certain change. Yet, if something occurs and we need to make a move by a certain date, I will be the one to catch management's ire for not providing them the information to raise the priority. Damned either way. All I can do is ask questions, and if something occurs, have the documentation available to show that I tried and hope that is enough.

1 person found this helpful

Michael Ferrante-Oracle

Well kudos to you for doing your homework. I wish you would/could encourage others to do the same.

Regarding Java, we (Forms) are doing everything within our internal boundaries to ensure that the changes in Java do not impact our customers' ability to run their Forms applications. This was one reason for creating the Forms Standalone Launcher (FSAL). If we find ways to improve it or even an alternative, we will consider that as well. Going forward we will be considering improvements to FSAL that will hopefully make it easier to use and administer. We are also looking into supporting newer Java versions although exactly which is to be determined. Likely we would only support the LTS (Long Term Support) releases. Also, we likely will not support the use of OpenJDK. Only the Oracle builds would be certified.

For Reports, as I mentioned I see no immediate issue with getting support for using it assuming you are using the latest version (currently 12.2.1.3). However, as time passes (especially after 12.2.1.4 releases), you may find it more difficult to get bugs fixed unless they are clearly critical. That said, your definition of "critical" and Oracle's may differ and it is Oracle that will get the last word. As for compatibility with other products, like my comments related to the use of Java with Forms, we are doing everything we can to ensure that Forms and Reports continue to offer direct integration (i.e. through RUN_REPORT_OBJECT). This should not be an issue for 12.2.1.4, but after that is still unknown.

I mentioned BI-Publisher above. Don't forget that Forms 12.2.1.x introduced integration with BI-Publisher similar to the integration with Reports. Check out the Forms 12c New Features Guide for more information about it and more. You can find that doc and other Forms 12c specific papers here:

https://www.oracle.com/technetwork/developer-tools/forms/documentation/techlisting12c-2855390.html

1 person found this helpful

1 - 7

Locked Post

New comments cannot be posted to this locked post.

Locked on Sep 11 2017

Added on Aug 13 2017

#php

4 comments

21,388 views

DevOps, CI/CD and Automation

Cannot enable OCI8 on Linux

Comments

Post Details