PHP/Informix consultant?
Posted in 2000
Richard Puchalsky couldn't get PHP3 (built as an Apache DSO) working with Informix on Caldera Linux with CSDK 2.40: Apache failed to load libphp3.so with "/opt/informix/lib/esql/libifos.so: undefined symbol: ifx_checkAPI". Andrej Falout explained the checkapi.o/ESQL-C API-version check and supplied a fix: export IFX_LIBDIR, IFX_INCDIR and an explicit IFX_LIBS list (the static libif* libraries plus checkapi.o) before running ./configure --with-informix. That worked; testing showed the IFX_* variables, not the -DEAPI CFLAGS, were the cure, since configure wasn't detecting the libraries itself. They suggested filing it as a PHP bug.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Platform-Specific Issues, Jobs, Consulting & Announcements
Can anyone recommend a consultant who I can hire to get PHP working with Informix functions on my Linux machine? I've exhausted the various free and tech support resources to no avail and at this point I just need to get it working.
In article <gsWS4.5169$XO1.299371@bgtnsc06-news.ops.worldnet.att.net>, rpuchalsky@att.net says... > Can anyone recommend a consultant who I can hire to get PHP working with > Informix functions on my Linux machine? I've exhausted the various free and > tech support resources to no avail and at this point I just need to get it > working. > > > Why not ask us? After all, this is not really a brain surgery, too many people have this working. -- Yours, Andrej Falout, http://www.falout.com ICQ 7628616 ++64.21.607517 #----------------------------------------------------------------- globals "std_disclaimer.4gl" Ask yourself just one question: ' Qu' m's se puede hacer y aprender ? - Propellerhead ReBirth RB-338 manual
"Andrej Falout" <afalout@xtra.co.nz> wrote:
> rpuchalsky@att.net says...
> > Can anyone recommend a consultant who I can hire to get PHP working with
> > Informix functions on my Linux machine? I've exhausted the various free
and
> > tech support resources to no avail and at this point I just need to get
it
> > working.
>
> Why not ask us? After all, this is not really a brain surgery, too many
> people have this working.
>
I have; no one here could answer my question. If you'd like to give it
another shot, I'd be happy to have you prove that I don't need a consultant
after all. Rather than make you look up the previous thread through
Dejanews, here's my problem again:
I'm trying to get PHP3 working with the Informix functions by recompiling
mod_php3. My compilation is (apparently) OK. But when I try to turn Apache
on with the new version of mod_php3, I get the error message "Cannot load
/usr/libexec/apache/libphp3.so into server:
/opt/informix/lib/esql/libifos.so: undefined symbol: ifx_checkAPI". I can
compile and use mod_php3 if I don't try to compile it with Informix
functions.
At every stage of the compilation, and in the script that starts Apache, I
have INFORMIXDIR, INFORMIXSERVER, the PATH including /opt/informix/bin, and
LD_LIBRARY_PATH=/opt/informix/lib:/opt/informix/lib/esql:/opt/informix/incl/esql set. I even tried setting INFORMIXC=gcc. The symbol ifx_checkAPI is
defined in /opt/informix/lib/esql/checkapi.o (according to Informix tech
support), and I appear to have this file. I've tried compiling
/opt/informix/lib and /opt/informix/lib/esql into my ld.so.cache.
I'm using:
Caldera OpenLinux eServer 2.3
Informix Foundation 2000
Informix Client SDK 2.40.UC1-2
Apache 1.3.9-4
PHP 3.0.16
I'm trying to compile php by using
"./configure --with-apxs=/usr/sbin/apxs --with-ldap --with-xml --with-inform
ix=/opt/informix --enable-versioning --with-config-file-path=/etc/httpd/conf
".
[This followup was posted to comp.databases.informix and a copy was sent to the cited author.] In article <TEKT4.66788$fV.4095282@bgtnsc05-news.ops.worldnet.att.net>, rpuchalsky@att.net says... ...snip... > esql set. I even tried setting INFORMIXC=gcc. The symbol ifx_checkAPI is > defined in /opt/informix/lib/esql/checkapi.o (according to Informix tech A little C&P from ESQL/C manual ESQL/C uses an Informix function that is called checkapi() to perform this check. The checkapi() function is in the checkapi.o object file, which is contained in the $INFORMIXDIR/lib/esql directory. The esql command automatically links this checkapi.o object file with every executable that it creates. To determine the API version of the library that the application uses, ESQL/C checks the values of special macro definitions in the executable file. When the ESQL/C preprocessor processes a source file, it copies the macro definitions from the sqlhdr.h header file into the C source file (.c) that it generates. The following example shows sample values for these macros: #define CLIENT_GEN_VER 710 #define CLIENT_OS_VER 710 #define CLIENT_SQLI_VER 710 #define CLIENT_GLS_VER 710 Tip: The ESQL/C preprocessor automatically includes the sqlhdr.h file in all ESQL/C executable files that it generates. If the API version of the libraries in this executable file are not compatible, ESQL/C returns a runtime error that indicates which library is not compatible. You must recompile your ESQL/C application to link the new release-version of the shared library. If you do not use esql to link one of the shared Informix general libraries with your ESQL/C application, you must explicitly link the checkapi.o file with your application. Otherwise, ESQL/C might generate an error at link time of the form: undefined ifx_checkAPI() OK, lets try this: IFX_LIBDIR="-L$INFORMIXDIR/lib -L$INFORMIXDIR/lib/esql" IFX_INCDIR="$INFORMIXDIR/incl/esql" IFX_LIBS="$INFORMIXDIR/lib/esql/libifsql.a \\ $INFORMIXDIR/lib/libifasf.a \\ $INFORMIXDIR/lib/esql/libifgen.a \\ $INFORMIXDIR/lib/esql/libifos.a \\ $INFORMIXDIR/lib/esql/libifgls.a \\ -lgen -lgls -lm -ldl $INFORMIXDIR/lib/esql/checkapi.o \\ $INFORMIXDIR/lib/esql/libifglx.a" export IFX_LIBDIR IFX_INCDIR IFX_LIBS CFLAGS="-O2 -s -DEAPI " \\ ./configure --with-informix=yes \\ ... and the rest ... > I'm using: > Caldera OpenLinux eServer 2.3 > Informix Foundation 2000 > Informix Client SDK 2.40.UC1-2 Not sure about this, but is it possible that ifx_checkAPI() cannot load because API is realy changed? I use 2.10.UC2-1 CSDK so cannot help here. So, is anyone using PHP3 with 2.40 SDK? More C&P, this time bugs.php.net ---start---- When I use function ifx_connect(), httpd instance crashes and in the logfile appears record: /usr/lib/dld.sl: Unresolved symbol: ifx_checkAPI (code) from /apl/informix/lib/ esql/libifsql.sl I use Iformix SE 7.22 and Inf. client sdk v2.40 uc11. I've compiled php4 with informix support and the phpinfo() shows information about the informix extension well. ----end---- Again 2.40 There is another under http://bugs.php.net/bugs.php3?id=3765 but it does not state CSDK version. Danny, what do you say? -- Yours, Andrej Falout, http://www.falout.com ICQ 7628616 ++64.21.607517 #----------------------------------------------------------------- globals "std_disclaimer.4gl" Ask yourself just one question: ' Qu' m's se puede hacer y aprender ? - Propellerhead ReBirth RB-338 manual
Andrej Falout" <afalout@xtra.co.nz> wrote in message news:MPG.138bc6da3d5baf749896ce@news.xtra.co.nz... > [This followup was posted to comp.databases.informix and a copy was sent > to the cited author.] Thanks! I'll try your suggestion. If it doesn't work, maybe I'll try getting ahold of the 2.10 version of Client SDK and seeing if that works. While I'm trying that, someone else asked for the result of ldd when run on my mod_php3 library (presumably libphp3.so). On the off chance that anyone else is interested, I'll post it: libgd.so.0 => /usr/lib/libgd.so.0 (0x2ab8d000) libpng.so.1 => /usr/lib/libpng.so.1 (0x2abb5000) libz.so.1 => /usr/lib/libz.so.1 (0x2abd0000) libldap.so.1 => /usr/lib/libldap.so.1 (0x2abde000) liblber.so.1 => /usr/lib/liblber.so.1 (0x2abf4000) libifsql.so => /opt/informix/lib/esql/libifsql.so (0x2abf9000) libifasf.so => /opt/informix/lib/libifasf.so (0x2ac38000) libifgen.so => /opt/informix/lib/esql/libifgen.so (0x2ac6e000) libifos.so => /opt/informix/lib/esql/libifos.so (0x2acba000) libifgls.so => /opt/informix/lib/esql/libifgls.so (0x2acd0000) libc.so.6 => /lib/libc.so.6 (0x2ad09000) libdl.so.2 => /lib/libdl.so.2 (0x2adfe000) libifglx.so => /opt/informix/lib/esql/libifglx.so (0x2ae02000) libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x2ae04000) libpam.so.0 => /lib/libpam.so.0 (0x2ae0a000) libm.so.6 => /lib/libm.so.6 (0x2ae13000) libresolv.so.2 => /lib/libresolv.so.2 (0x2ae32000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x55555000) > > In article <TEKT4.66788$fV.4095282@bgtnsc05-news.ops.worldnet.att.net>, > rpuchalsky@att.net says... > > ...snip... > > > esql set. I even tried setting INFORMIXC=gcc. The symbol ifx_checkAPI is > > defined in /opt/informix/lib/esql/checkapi.o (according to Informix tech > > A little C&P from ESQL/C manual > > ESQL/C uses an Informix function that is called checkapi() to perform > this check. The checkapi() function is in the checkapi.o object file, > which is contained in the $INFORMIXDIR/lib/esql directory. The esql > command automatically links this checkapi.o object file with every > executable that it creates. > > To determine the API version of the library that the application uses, > ESQL/C checks the values of special macro definitions in the executable > file. When the ESQL/C preprocessor processes a source file, it copies > the macro definitions from the sqlhdr.h header file into the C source > file (.c) that it generates. The following example shows sample values > for these macros: > > > #define CLIENT_GEN_VER 710 > #define CLIENT_OS_VER 710 > #define CLIENT_SQLI_VER 710 > #define CLIENT_GLS_VER 710 > > Tip: The ESQL/C preprocessor automatically includes the sqlhdr.h file > in all ESQL/C executable files that it generates. > If the API version of the libraries in this executable file are not > compatible, ESQL/C returns a runtime error that indicates which library > is not compatible. You must recompile your ESQL/C application to link > the new release-version of the shared library. > If you do not use esql to link one of the shared Informix general > libraries with your ESQL/C application, you must explicitly link the > checkapi.o file with your application. Otherwise, ESQL/C might generate > an error at link time of the form: > > > undefined ifx_checkAPI() > > OK, lets try this: > > IFX_LIBDIR="-L$INFORMIXDIR/lib -L$INFORMIXDIR/lib/esql" > IFX_INCDIR="$INFORMIXDIR/incl/esql" > IFX_LIBS="$INFORMIXDIR/lib/esql/libifsql.a \\ > $INFORMIXDIR/lib/libifasf.a \\ > $INFORMIXDIR/lib/esql/libifgen.a \\ > $INFORMIXDIR/lib/esql/libifos.a \\ > $INFORMIXDIR/lib/esql/libifgls.a \\ > -lgen -lgls -lm -ldl $INFORMIXDIR/lib/esql/checkapi.o \\ > $INFORMIXDIR/lib/esql/libifglx.a" > > export IFX_LIBDIR IFX_INCDIR IFX_LIBS > > CFLAGS="-O2 -s -DEAPI " \\ > ./configure --with-informix=yes \\ > ... and the rest ... > > > I'm using: > > Caldera OpenLinux eServer 2.3 > > Informix Foundation 2000 > > Informix Client SDK 2.40.UC1-2 > > Not sure about this, but is it possible that ifx_checkAPI() cannot load > because API is realy changed? I use 2.10.UC2-1 CSDK so cannot help here. > So, is anyone using PHP3 with 2.40 SDK? > > More C&P, this time bugs.php.net > > ---start---- > > When I use function ifx_connect(), httpd instance crashes and in the > logfile appears > record: > > /usr/lib/dld.sl: Unresolved symbol: ifx_checkAPI (code) from > /apl/informix/lib/ > esql/libifsql.sl > > I use Iformix SE 7.22 and Inf. client sdk v2.40 uc11. > I've compiled php4 with informix support and the phpinfo() shows > information about the > informix extension well. > > ----end---- > > Again 2.40 > > There is another under http://bugs.php.net/bugs.php3?id=3765 but it does > not state CSDK version. > > Danny, what do you say? > > > -- > Yours, Andrej Falout, http://www.falout.com ICQ 7628616 ++64.21.607517 > #----------------------------------------------------------------- > globals "std_disclaimer.4gl" > > Ask yourself just one question: ' Qu' m's se puede hacer y aprender ? > - Propellerhead ReBirth RB-338 manual
"Andrej Falout" <afalout@xtra.co.nz> wrote: > OK, lets try this: The script worked! This time, I didn't get the ifx_checkAPI error when I tried to run PHP, and I tested it by actually running a program that used Informix functions. Thanks! If you do decide to become a consultant rather than helping people for free, I'll be sure to recommend you. :-) I understand the part of the script where you're setting IFX_LIBDIR, IFX_INCDIR, and IFX_LIBS, but I'm not sure what the compilation flags mean, so I'm not sure whether you had me try fixing two things at once or only one. Would you like me to try eliminating anything from the script in an effort to figure out which part of it was the critical fix? My problem is fixed, but it might help the next person who runs into this to identify what went wrong. > > IFX_LIBDIR="-L$INFORMIXDIR/lib -L$INFORMIXDIR/lib/esql" > IFX_INCDIR="$INFORMIXDIR/incl/esql" > IFX_LIBS="$INFORMIXDIR/lib/esql/libifsql.a \\ > $INFORMIXDIR/lib/libifasf.a \\ > $INFORMIXDIR/lib/esql/libifgen.a \\ > $INFORMIXDIR/lib/esql/libifos.a \\ > $INFORMIXDIR/lib/esql/libifgls.a \\ > -lgen -lgls -lm -ldl $INFORMIXDIR/lib/esql/checkapi.o \\ > $INFORMIXDIR/lib/esql/libifglx.a" > > export IFX_LIBDIR IFX_INCDIR IFX_LIBS > > CFLAGS="-O2 -s -DEAPI " \\ > ./configure --with-informix=yes \\ > ... and the rest ...
[This followup was posted to comp.databases.informix and a copy was sent to the cited author.] In article <s3lU4.13653$XO1.753548@bgtnsc06-news.ops.worldnet.att.net>, rpuchalsky@att.net says... > "Andrej Falout" <afalout@xtra.co.nz> wrote: > > OK, lets try this: > > The script worked! This time, I didn't get the ifx_checkAPI error when I > tried to run PHP, and I tested it by actually running a program that used > Informix functions. Thanks! If you do decide to become a consultant rather > than helping people for free, I'll be sure to recommend you. :-) (Danny, do we have a FAQ for IFX/PHP? This should obviously go there) I have become consultant long time ago, and most people here are making living by doing this for money, just like me. Goto www.falout.com, click on picture of penguin with "Born to frag" sign if you wonder if I'm crazy or not. And if you want to pay me for this, help someone else that needs help in the future. > I understand the part of the script where you're setting IFX_LIBDIR, > IFX_INCDIR, and IFX_LIBS, but I'm not sure what the compilation flags mean, > so I'm not sure whether you had me try fixing two things at once or only > one. Would you like me to try eliminating anything from the script in an > effort to figure out which part of it was the critical fix? My problem is > fixed, but it might help the next person who runs into this to identify what > went wrong. You stated: I'm trying to compile php by using "./configure --with-apxs=/usr/sbin/apxs --with-ldap --with-xml --with- inform ix=/opt/informix --enable-versioning --with-config-file- path=/etc/httpd/conf ". I was not absolutely sure, but somewhere in my ROM I have traces of : EAPI patches are required which have to change internal Apache structures. PHP3 needs to know about these in order to work correctly. Always make sure that -DEAPI is contained in the compiler flags when PHP3 is build. ...in connection with xml. Maybe I was wrong. Try to remove CFLAGS, it will maybe work, maybe it was just me and my obsession with SSL that definitely needs this. IFX_xxxx stuff is definitely more significant. It might be interesting to read Danny's reply on the subject too: I use PHP3 and PHP4 with the 2.40 CSDK on Linux, but only with a statically built Apache/modphp. If you use the Informix shared libraries, you can not run your httpd binary on a machine with a different ESQL/C runtime than the one you compiled your httpd on, which does not help with deployment. People using a dso version of modphp + Informix have been complaining about this "checkapi.o" problem, but I did not realize that CSDK 2.40 was the cause. I have in the past built modphp3 as a DSO, even with php3_ifx.dso as a seperately loadable module, but that was a long time ago and I don't remember the CSDK version I used at the time. It is possible that it no longer works. Danny --- -- Yours, Andrej Falout, http://www.falout.com ICQ 7628616 ++64.21.607517 #----------------------------------------------------------------- globals "std_disclaimer.4gl" Ask yourself just one question: ' Qu' m's se puede hacer y aprender ? - Propellerhead ReBirth RB-338 manual
"Andrej Falout" <afalout@xtra.co.nz> wrote: > Goto www.falout.com, click on picture of penguin with "Born to frag" > sign if you wonder if I'm crazy or not. Oh, I understand the idea of charging money only for the first time that you discover something, and not for your time in passing it on to other people. It wasn't clear to me, though, that my problem could be answered without someone discovering something new. > > And if you want to pay me for this, help someone else that needs help in > the future. Sure. > ...in connection with xml. Maybe I was wrong. Try to remove CFLAGS, it > will maybe work, maybe it was just me and my obsession with SSL that > definitely needs this. IFX_xxxx stuff is definitely more significant. All right, I'll try it with just the CFLAGS and with just the IFX_xxx environment variables, and see if either one was the fix by itself.
In article <Z%AU4.70993$WF.3958383@bgtnsc04-news.ops.worldnet.att.net>, rpuchalsky@att.net says... > "Andrej Falout" <afalout@xtra.co.nz> wrote: > > Goto www.falout.com, click on picture of penguin with "Born to frag" > > sign if you wonder if I'm crazy or not. > > Oh, I understand the idea of charging money only for the first time that you > discover something, and not for your time in passing it on to other people. > It wasn't clear to me, though, that my problem could be answered without > someone discovering something new. Hehehe, actually it was different lib but (more/less) same prob, and same solution (Interesting is the fact that it looks like the whole thing is just another side effect of not linking with esql, something Jonathan L. was warning against on this list soooo many times...). I can give you phone number of the company I charged this solution orriginaly if you want to check...:-) > > ...in connection with xml. Maybe I was wrong. Try to remove CFLAGS, it > > will maybe work, maybe it was just me and my obsession with SSL that > > definitely needs this. IFX_xxxx stuff is definitely more significant. > > All right, I'll try it with just the CFLAGS and with just the IFX_xxx > environment variables, and see if either one was the fix by itself. Cool. Let us know. -- Yours, Andrej Falout, http://www.falout.com ICQ 7628616 ++64.21.607517 #----------------------------------------------------------------- globals "std_disclaimer.4gl" Ask yourself just one question: ' Qu' m's se puede hacer y aprender ? - Propellerhead ReBirth RB-338 manual
"Andrej Falout" <afalout@xtra.co.nz> wrote: > rpuchalsky@att.net says... > > All right, I'll try it with just the CFLAGS and with just the IFX_xxx > > environment variables, and see if either one was the fix by itself. > > Cool. Let us know. > When I tried it with just the IFX_xxx environment variables set but with no CFLAGS, the fix worked. When I tried with the CFLAGS but without the IFX_xxx variables, it didn't. So I guess the original problem was that the ./configure couldn't detect IFX_LIBS, IFX_INCDIR, and IFX_LIBDIR correctly. That's odd, since you'd think that these would be rather platform and version independent, once $INFORMIXDIR is known, and since I never saw an error message in the compile. Anyways, is there some way to write this up so that other people can find the fix if they get the same error? I'm not even sure where these kinds of things should be archived.
In article <WdIU4.70959$fV.4390027@bgtnsc05-news.ops.worldnet.att.net>, rpuchalsky@att.net says... > "Andrej Falout" <afalout@xtra.co.nz> wrote: > > rpuchalsky@att.net says... > When I tried it with just the IFX_xxx environment variables set but with no > CFLAGS, the fix worked. When I tried with the CFLAGS but without the > IFX_xxx variables, it didn't. So I guess the original problem was that the > ./configure couldn't detect IFX_LIBS, IFX_INCDIR, and IFX_LIBDIR correctly. > That's odd, since you'd think that these would be rather platform and > version independent, once $INFORMIXDIR is known, and since I never saw an > error message in the compile. RTFM time again: If you do not use esql to link one of the shared Informix general libraries with your ESQL/C application, you must explicitly link the checkapi.o file with your application. Otherwise, ESQL/C might generate an error at link time of the form: undefined ifx_checkAPI() > Anyways, is there some way to write this up so that other people can find > the fix if they get the same error? I'm not even sure where these kinds of > things should be archived. Well, I would say it's a stuff for bug report, not a FAQ. Apparently, makefile for PHP/Ifx is not using esql to link under some conditions, and not explicitly including libraries. I guess I'll look at that code, RSN. In the mean time (and for folks with older versions) you might do all a favour by entering a bug in bugs.php.net, describing all we discussed here, inc solution, and then ... hmmm, close it or not. I'm not sure. Leave it open, assign it to me. Unless some of Big Boys of ESQL/C wants this? (yes, you know who you are!) -- Yours, Andrej Falout, http://www.falout.com ICQ 7628616 ++64.21.607517 #----------------------------------------------------------------- globals "std_disclaimer.4gl" Ask yourself just one question: ' Qu' m's se puede hacer y aprender ? - Propellerhead ReBirth RB-338 manual
"Andrej Falout" <afalout@xtra.co.nz> wrote: > If you do not use esql to link one of the shared Informix general > libraries with your ESQL/C application, you must explicitly link the > checkapi.o file with your application. Otherwise, ESQL/C might generate > an error at link time of the form: > undefined ifx_checkAPI() OK, sure -- but in my case I didn't see any error at link time, I saw the error at run time. And my Makefile was explicitly linking in checkapi.o for me as one of the libraries, even before I ran your script that fixed the problem. I did check that before; it's one of the reasons that I couldn't figure out what was going on. > In the mean time (and for folks with older versions) you might do all a > favour by entering a bug in bugs.php.net, describing all we discussed > here, inc solution, OK, will do.