Re: compiling informix IDS with PHP
Posted in 2006
Thread about building PHP 5.2 with Informix (ESQL/C CSDK) support: the build/install fails at the PEAR step and the CLI binary reports "error while loading shared libraries: libifgls.so: cannot open shared object file". One poster worked around it by configuring with --disable-cli, but the consensus answer was that this isn't a compile problem at all — the runtime library search path is wrong. The fix is to add the Informix $INFORMIXDIR/lib and lib/esql directories to ld.so.conf and re-run ldconfig (or set LD_LIBRARY_PATH). Others pressed the poster to post his ./configure line (e.g. via phpinfo()) in case multiple IDS/ESQL installs or a moved INFORMIXDIR were involved; no confirmation from the original poster is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Installation, Setup & Upgrades, Internationalization & Character Sets
Manas D schrieb: > Danny, > Please refer to the following article > http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0606bombardier/ > > Thanks, > -Manas > > Danny De Koster wrote: >> Hi all, >> >> I want to use my informix database with PHP. But with the compilation I get >> this. >> Any solutions? >> >> Thanks, >> Danny >> Hi Danny, this seems familiar to me. The only solution I found was to compile php with "--disable-cli". And yes, I did read the above mentioned DeveloperWorks article and used the latest CSDK and the current IDS available at IIUG. BTW: this only seems to a problem with PHP 5, older versions will work fine. Roland >> >> >> /bin/sh >> /usr/local/src/php-5.2.0/libtool --silent --preserve-dup-deps --mode=ins >> tall cp ext/wddx/wddx.la /usr/local/src/php-5.2.0/modules >> Installing PHP SAPI module: apache2handler >> /usr/local/apache/build/instdso.sh >> SH_LIBTOOL='/usr/local/apache/build/libtool' >> libphp5.la /usr/local/apache/modules >> /usr/local/apache/build/libtool --mode=install cp libphp5.la >> /usr/local/apache/m >> odules/ >> cp .libs/libphp5.so /usr/local/apache/modules/libphp5.so >> cp .libs/libphp5.lai /usr/local/apache/modules/libphp5.la >> libtool: install: warning: remember to run `libtool --finish >> /usr/local/src/php- >> 5.2.0/libs' >> chmod 755 /usr/local/apache/modules/libphp5.so >> [activating module `php5' in /usr/local/apache/conf/httpd.conf] >> Installing PHP CLI binary: /usr/local/bin/ >> Installing PHP CLI man page: /usr/local/man/man1/ >> Installing shared extensions: >> /usr/local/lib/php/extensions/no-debug-non-zts >> -20060613/ >> Installing build environment: /usr/local/lib/php/build/ >> Installing header files: /usr/local/include/php/ >> Installing helper programs: /usr/local/bin/ >> program: phpize >> program: php-config >> Installing man pages: /usr/local/man/man1/ >> page: phpize.1 >> page: php-config.1 >> Installing PEAR environment: /usr/local/lib/php/ >> /usr/local/src/php-5.2.0/sapi/cli/php: error while loading shared libraries: >> lib >> ifgls.so: cannot open shared object file: No such file or directory >> make[1]: *** [install-pear-installer] Error 127 >> make: *** [install-pear] Error 2 >
Hi Roland, Indeed with the enable-cli, obvious he did succeed to compile the php. I followed the steps in the "A step-by-step how-to guide to install, configure, and test a Linux, Apache,....." so I checked that PHP is well compiled. doing a /usr/local/bin/php -m I get ./php: error while loading shared libraries: libifgls.so: cannot open shared object file: No such file or directory any ideas?? Thanks, Danny "Roland Wintgen" <rw@evg.de> schreef in bericht news:newscache$svuf9j$899$1@news.itemax.de... > Manas D schrieb: >> Danny, >> Please refer to the following article >> http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0606bombardier/ >> >> Thanks, >> -Manas >> >> Danny De Koster wrote: >>> Hi all, >>> >>> I want to use my informix database with PHP. But with the compilation I >>> get >>> this. >>> Any solutions? >>> >>> Thanks, >>> Danny >>> > Hi Danny, > > this seems familiar to me. The only solution I found was to compile php > with "--disable-cli". > And yes, I did read the above mentioned DeveloperWorks article and used > the latest CSDK and the current IDS available at IIUG. > > BTW: this only seems to a problem with PHP 5, older versions will work > fine. > > Roland > >>> >>> >>> /bin/sh >>> /usr/local/src/php-5.2.0/libtool --silent --preserve-dup-deps --mode=ins >>> tall cp ext/wddx/wddx.la /usr/local/src/php-5.2.0/modules >>> Installing PHP SAPI module: apache2handler >>> /usr/local/apache/build/instdso.sh >>> SH_LIBTOOL='/usr/local/apache/build/libtool' >>> libphp5.la /usr/local/apache/modules >>> /usr/local/apache/build/libtool --mode=install cp libphp5.la >>> /usr/local/apache/m >>> odules/ >>> cp .libs/libphp5.so /usr/local/apache/modules/libphp5.so >>> cp .libs/libphp5.lai /usr/local/apache/modules/libphp5.la >>> libtool: install: warning: remember to run `libtool --finish >>> /usr/local/src/php- >>> 5.2.0/libs' >>> chmod 755 /usr/local/apache/modules/libphp5.so >>> [activating module `php5' in /usr/local/apache/conf/httpd.conf] >>> Installing PHP CLI binary: /usr/local/bin/ >>> Installing PHP CLI man page: /usr/local/man/man1/ >>> Installing shared extensions: >>> /usr/local/lib/php/extensions/no-debug-non-zts >>> -20060613/ >>> Installing build environment: /usr/local/lib/php/build/ >>> Installing header files: /usr/local/include/php/ >>> Installing helper programs: /usr/local/bin/ >>> program: phpize >>> program: php-config >>> Installing man pages: /usr/local/man/man1/ >>> page: phpize.1 >>> page: php-config.1 >>> Installing PEAR environment: /usr/local/lib/php/ >>> /usr/local/src/php-5.2.0/sapi/cli/php: error while loading shared >>> libraries: >>> lib >>> ifgls.so: cannot open shared object file: No such file or directory >>> make[1]: *** [install-pear-installer] Error 127 >>> make: *** [install-pear] Error 2 >>
> Indeed with the enable-cli, obvious he did succeed to compile the php. > I followed the steps in the "A step-by-step how-to guide to install, > configure, and test a Linux, Apache,....." so I checked that PHP is well > compiled. > doing a /usr/local/bin/php -m I get > ./php: error while loading shared libraries: libifgls.so: cannot open > shared object file: No such file or directory > any ideas?? You ldconfig is not complete; your library search path must include the folder that contains libifgls.so.
Adam Tauno Williams wrote: >> Indeed with the enable-cli, obvious he did succeed to compile the php. >> I followed the steps in the "A step-by-step how-to guide to install, >> configure, and test a Linux, Apache,....." so I checked that PHP is well >> compiled. >> doing a /usr/local/bin/php -m I get >> ./php: error while loading shared libraries: libifgls.so: cannot open >> shared object file: No such file or directory >> any ideas?? > > You ldconfig is not complete; your library search path must include the > folder that contains libifgls.so. > And the guy has _*still*_ not supplied his ./config line to tell anyone what he did to build PHP. Until that's done it's all bullshit. A good starting point is to create a php program like this: <?php phpinfo(); ?> save it as phpinfo.php and run it from your browser like this: http://mywebsite/phpinfo.php This will list out all the shit used to build php on that webserver. Once we get that all-important ./config command, which will be listed then the guy can get some real guidance, but for now it's amazing that so many are willing to help and this guy won't do what Paul offered as an immediate request, which was to show us the config. Sheeesh! Until then it's anybody's guess, which is exactly what people are doing, guessing! -DE-
>>> Indeed with the enable-cli, obvious he did succeed to compile the php. >>> I followed the steps in the "A step-by-step how-to guide to install, >>> configure, and test a Linux, Apache,....." so I checked that PHP is well >>> compiled. >>> doing a /usr/local/bin/php -m I get >>> ./php: error while loading shared libraries: libifgls.so: cannot open >>> shared object file: No such file or directory >>> any ideas?? >> You ldconfig is not complete; your library search path must include the >> folder that contains libifgls.so. > And the guy has _*still*_ not supplied his ./config line to tell anyone what > he did to build PHP. Until that's done it's all #######. Nope, you are wrong. If he has a /usr/local/bin/php then PHP did compile and install, the above error message always and exactly means his library path is wrong; he has to actually have the library for the thing to have compiled in the first place. There is no reason to present his "./config line" (which is "./configure" BTW).
> > >>> Indeed with the enable-cli, obvious he did succeed to > compile the php. > >>> I followed the steps in the "A step-by-step how-to guide > to install, > >>> configure, and test a Linux, Apache,....." so I checked > that PHP is > >>> well compiled. > >>> doing a /usr/local/bin/php -m I get > >>> ./php: error while loading shared libraries: > libifgls.so: cannot > >>> open shared object file: No such file or directory any ideas?? > >> You ldconfig is not complete; your library search path > must include > >> the folder that contains libifgls.so. > > And the guy has _*still*_ not supplied his ./config line to tell > > anyone what he did to build PHP. Until that's done it's > all #######. > > Nope, you are wrong. If he has a /usr/local/bin/php then PHP > did compile and install, the above error message always and > exactly means his library path is wrong; he has to actually > have the library for the thing to have compiled in the first > place. There is no reason to present his "./config line" > (which is "./configure" BTW). Nope it tells us that at one point he has had a successful compile and an install. Now that install could have informix install pointing to somewhere it is no longer. For example he's moved it from /usr/informix to /usr/informixsowmehereelse. Now if he had supplied the requested information then the correct environment would have been provided for him by now, ie make sure <supplied-data>/lib <supplied-data>/lib/esql are on the library path. So OK, he can go look for the missing library and make sure it's found but if he has multiple IDS/ESQLC installations then which one does he use - well that depends on the ./config line he as used and we are back to the first question. Most of us don't ask for more information for the sheer hell of it Cheers Paul Paul Watson Tel: +44 1414161772 Mob: +44 7818003457 Web: www.oninit.com GO FURTHER with DB2 GET THERE FASTER with Informix. Attend IDUG 2007 San Jose, North America May 6-10, 2007 Visit http://www.iiug.org/conf for more information.
Adam Tauno Williams wrote: >>>> Indeed with the enable-cli, obvious he did succeed to compile the php. >>>> I followed the steps in the "A step-by-step how-to guide to install, >>>> configure, and test a Linux, Apache,....." so I checked that PHP is >>>> well >>>> compiled. >>>> doing a /usr/local/bin/php -m I get >>>> ./php: error while loading shared libraries: libifgls.so: cannot >>>> open >>>> shared object file: No such file or directory >>>> any ideas?? >>> You ldconfig is not complete; your library search path must include the >>> folder that contains libifgls.so. >> And the guy has _*still*_ not supplied his ./config line to tell >> anyone what >> he did to build PHP. Until that's done it's all #######. > > Nope, you are wrong. If he has a /usr/local/bin/php then PHP did > compile and install, the above error message always and exactly means > his library path is wrong; he has to actually have the library for the > thing to have compiled in the first place. There is no reason to > present his "./config line" (which is "./configure" BTW). > Not so fast Adam. You can compile yet fail to completely install PHP. And until the web server is bounced he's still going to use the last known good version of PHP. You could also get part of the install, such as the cmd-line php to install and hork the rest of the install as we've seen. You *are* right of course, he does need to make sure his library references are up to date in ld.so.conf first, and then run ldconfig on the command line to get things in the lib department synchronized. And you are right it is "./configure" not ./config. There are still many sources out there that use the older ./config, my bad. :-) The right thing to do is to capture what the ./configure is for the current PHP installation. By creating a phpinfo.php and putting it in the docroot, and then capturing it, it will allow the new PHP version to overlay--if desired-- the current version. Personally I typically leave the RPM'd version of Apache alone, as well as the RPM'd version of PHP alone and build PHP into a new version of Apache over in its default /usr/local/apache2. This way if I hork it up I don't cripple the RPM'd version which is automagically updated in a lot of distros via update programs. After I get my own PHP up and running, I shut off the Apache that came with the distro, and then light up the Apache I built, which will also contain my own totally super-duper PHP installation. If the wheels fall off of my version, I simply turn off my Apache and turn on the RPM'd version, fix it, and away we go. This way I have a fall-back, and my web server stays operational for the most part, 100% of the time. Thanks for catching my errors, happy holidays! -DE-
Related threads
- Column name length in Informix
- Caching Data to Buffers
- Checkpoint Duration
- dbaccess standalone.
- Getting executable name.