Re: Bug id #3386 - Informix related

On Tue, 3 Oct 2000, Danny Heijl wrote: >At some point PHP4 introduced the use of "libtool"in the configure process. I think it was pretty early on, and it is a complete pain. I'd just worked out how to rig the PHP3 build to work with Informix, and the build got completely altered. >This makes it much easier to build shared object versions of your >programs. But not to link with shared objects that don't obey the rules that libtool imposes on you. And Informix does not obey those rules by default -- you have to fix the system to make it obey libtool's rules. >However, there is a problem with libtool : you can't easily specify >libraries with their full name (libxxx.a for instance). Too right. I spent a day going very grey and very bald busting my guts chasing how libtool did the build and rigging it to actually allow me to specify absolute path names because contrary to its expectations, sometimes the best way to deal with a shared library is to link in an absolute pathname -- and Informix shared libraries are a case in point! >If you need to specify static libraries : copy them all to one >directory, add this directory to your LDFLAGS (-Llibdirectory) and >specify the static libraries as -lxxx instead of as libxxx.a in your >LDFLAGS or CFLAGS. Make sure that there are no ".so" versions of that >same library in your library paths. Ouch. But static libraries are not usually desirable and not usually a major problem. >This should fix the problem with libtool. > >Sascha already had to provide a work-around for ".o" files (checkapi.o) in >the PHP/Informix configure process, but it does not work for ".a" files. > >Linking with the shared object versions of the Informix libraries should be >no problem with libtool. Huh! Depending on platform, it is or it isn't. Solaris is OK. Linux is manageable provided that you either use ldconfig to locate the Informix shared libraries (that's what it is designed for, though I didn't get it to work the one time I tried -- possibly because I didn't reboot) or create links from /usr/lib pointing to the actual Informix shared libraries (which is what I used on my last Linux PHP4 build). Solaris works because of the -R option. On platforms without an equivalent to that or ldconfig, the symlinks in /usr/lib is the only mechanism likely to work. >From: "Andrej Falout" <afalout@xtra.co.nz> >To: "Tyler Bannister" <tyler@nas.net> >Cc: "Jonathan Leffler" <jleffler@informix.com>; "Danny Heijl" ><danny.heijl@cevi.be>; <php-dev@lists.php.net> >Sent: Tuesday, October 03, 2000 10:25 AM >Subject: RE: Bug id #3386 - Informix related > > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi *, Danny, Jonathan, >> >> I received this PHP/Informix problem, basically: >> >> cannot build libtool library `libinformix.la' from non-libtool >> objects: /mpathix/informix/lib/esql/libifsql.a >> >> Can you maybe help Tyler? I never seen this one. >> >> BTW Tyler, did you enter this in bug database? You probably should. >> >> BTW 2, I don't think this have anything to do with bug 3386. >> >> > -----Original Message----- >> > From: Tyler Bannister [mailto:tyler@nas.net] >> > Sent: Wednesday, 27 September 2000 07:22 >> > To: afalout@php.net >> > Subject: Bug id #3386 >> > >> > >> > Hi, I saw that you were in charge of bug #3386, so I figured I >> > should send this to you: >> > >> > I received the following error when trying to install PHP 4.0.2 into apache >> > 1.3.11 as a DSO: >> > >> > Syntax error on line 242 of >> > /mpathix/webserver/apache/1.3.11DSO/conf/httpd.conf: Cannot load >> > /mpathix/webserver/apache/1.3.11DSO/libexec/libphp4.so into server: ld.so.1: >> > /mpathix/webserver/apache/1.3.11DSO/bin/httpd: fatal: relocation error: >> > file /mpathix/informix/lib/esql/libifsql.so: symbol ifx_checkAPI: referenced >> > symbol not found That's the checkapi.o file causing trouble again. >> > I use the following configure: >> > >> > ./configure --with-apxs=/mpathix/webserver/apache/httpd/bin/apxs \ >> > >> - --with-config-file-path=/mpathix/webserver/apache/httpd/conf \ >> > --enable-versioning \ >> > --with-informix \ >> > --without-mysql \ >> > --enable-track-vars >> > >> > Unless, I am mistaken those are the symptoms of bug #3386, but when >> I tried >> > your suggested work around, I got the following error: >> > >> > libtool: link: cannot build libtool library `libinformix.la' from >> > non-libtool objects: /mpathix/informix/lib/esql/libifsql.a >> > /mpathix/informix/lib/libifasf.a >> /mpathix/informix/lib/esql/libifgen.a >> > /mpathix/informix/lib/esql/libifos.a >> /mpathix/informix/lib/esql/libifgls.a >> > /mpathix/informix/lib/esql/libifglx.a >> > make[3]: *** [libinformix.la] Error 1 >> > make[3]: Leaving directory >> > `/mpathix/home/tbannist/sol26/php-4.0.2/ext/informix' >> > make[2]: *** [all-recursive] Error 1 >> > make[2]: Leaving directory >> > `/mpathix/home/tbannist/sol26/php-4.0.2/ext/informix' >> > make[1]: *** [all-recursive] Error 1 >> > make[1]: Leaving directory >> `/mpathix/home/tbannist/sol26/php-4.0.2/ext' >> > make: *** [all-recursive] Error 1 >> > >> > Any help you can provide would be appreciated... >> >> >> Hi Andrej, any idea what the problem might be? I've found a couple >> other >> bugs that seem similar: >> >> Bug id #2452 >> Bug id #3765 >> Bug id #6163 >> >> I don't know if that will be any help... I did notice that if I have >> a >> working version of PHP3 installed into apache (DSO) then I can run >> apache >> without getting the checkapi.o missing error (Even though it will >> occur if I >> stop loading PHP3). >> >> In case you didn't get my last message: >> >> Informix IDS: 7.31.UC6 >> Informix SDK: v2.40 uc1.1 >> >> Solaris 2.6 on a Sun Sparc Ultra-5 >> PHP 4.0.2 >> Apache 1.3.11 >> gcc 2.95.2 >> >> uname -a gives: >> SunOS maximus 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra-5_10 >> >> - -- >> Tyler Bannister >> tbannister@mpathix.com -- Yours, Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"