Bug #50833 for DBD-Informix: DBD-Informix 2008.0513 is not working on perl 5.10

Mon Oct 26 08:58:24 2009 pevik [...] seznam.cz - Ticket created

Subject:	DBD-Informix 2008.0513 is not working on perl 5.10
Date:	Mon, 26 Oct 2009 13:57:58 +0100 (CET)
To:	bug-DBD-Informix [...] rt.cpan.org
From:	Petr Vorel <pevik [...] seznam.cz>

Hi there, DBD-Informix 2008.0513 is not working on perl 5.10.1 (working on 5.10.0). Script dies with: symbol lookup error: /usr/lib/perl5/auto/DBD/Informix/Informix.so: undefined symbol: ifx_getbigserial Original bug which I posted on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544519 was tested on 5.10.1~rc2, now tested on stable 5.10.1. Thanks a lot for your time. If you want any help with testing just let me know. Regards, Petr Vorel ------------------------------- jabber: pevik@jabber.cz PGP: http://sipe.cz/pevik@seznam.cz.asc

Mon Oct 26 11:46:02 2009 j.leffler [...] acm.org - Correspondence added 10 min

Dear Petr, As I noted in a direct answer to you, I need to know which version of ClientSDK or ESQL/C you are using. In theory, the ESQLC_BIGINT #define ($define) should be present in esqlinfo.h if the ESQL/C supports BIGINT data type. It should be undefined if it is not supported. There's just one reference to the missing function - in dbdimp.ec - and it is surrounded by #ifdef ESQLC_BIGINT, as is all the other code working with BIGINT. -- Jonathan Leffler <jleffler@earthlink.net> <jleffler@us.ibm.com> Guardian of DBD::Informix 2008.0513 -- see http://dbi.perl.org/ "I don't suffer from insanity - I enjoy every minute of it!"

Mon Oct 26 11:46:03 2009 The RT System itself - Status changed from 'new' to 'open'

Mon Oct 26 12:02:51 2009 pevik [...] seznam.cz - Correspondence added

Subject:	Re: [rt.cpan.org #50833] DBD-Informix 2008.0513 is not working on perl 5.10
Date:	Mon, 26 Oct 2009 17:02:28 +0100 (CET)
To:	bug-DBD-Informix [...] rt.cpan.org
From:	Petr Vorel <pevik [...] seznam.cz>

Hello Jonathan, Show quoted text

> > As I noted in a direct answer to you, I need to know which version of > ClientSDK or ESQL/C you ae using.

> > In theory, the ESQLC_BIGINT #define ($define) should be present in > esqlinfo.h if the ESQL/C supports BIGINT data type. It should be > undefined if it is not supported. There's just one reference to the > missing function - in dbdimp.ec - and it is surrounded by #ifdef > ESQLC_BIGINT, as is all the other code working with BIGINT.

As I'm not building itself but using package provided by debian, I have no esqlinfo.h. So you think it's Debian's issue? Petr

Mon Oct 26 13:51:38 2009 jonathan.leffler [...] gmail.com - Correspondence added

CC:	Petr Vorel <pevik [...] seznam.cz>
Subject:	Re: [rt.cpan.org #50833] DBD-Informix 2008.0513 is not working on perl 5.10
Date:	Mon, 26 Oct 2009 10:51:03 -0700
To:	bug-DBD-Informix [...] rt.cpan.org
From:	Jonathan Leffler <jonathan.leffler [...] gmail.com>

On Mon, Oct 26, 2009 at 9:02 AM, Petr Vorel via RT < bug-DBD-Informix@rt.cpan.org> wrote: Show quoted text

> Queue: DBD-Informix > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=50833 > > > Hello Jonathan, >

> > > > As I noted in a direct answer to you, I need to know which version of > > ClientSDK or ESQL/C you ae using.

> > > > In theory, the ESQLC_BIGINT #define ($define) should be present in > > esqlinfo.h if the ESQL/C supports BIGINT data type. It should be > > undefined if it is not supported. There's just one reference to the > > missing function - in dbdimp.ec - and it is surrounded by #ifdef > > ESQLC_BIGINT, as is all the other code working with BIGINT.

> As I'm not building itself but using package provided by debian, I have no > esqlinfo.h. > So you think it's Debian's issue? >

Not sure - but possibly. OTOH, probably not. Let's do some checking... There should be a library $INFORMIXDIR/lib/esql/libisql.a - on that, run: nm -g $INFORMIXDIR/lib/esql/libisql.a | grep ifx_getbigserial This should show the function being defined. With ESQL/C 3.50, I got this: 00001a73 T ifx_getbigserial The number doesn't matter; the 'T' is important. If that appears, then we're into some trickier debugging. If it does not appear, then we have a simple problem - what happened to ifx_getbigserial... I dug up CSDK 3.00.FC1 on Solaris 10; there aren't any bigint symbols in the library, whereas there are in CSDK 3.50.FC1. So, it appears that DBD::Informix was built with a newer version of CSDK than you have installed. This is probably not something that Debian can do much about - it looks like your problem. You probably need to be using 3.50 - or you need to rebuild DBD::Informix for the CSDK you have. Both techniques should work. -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

Mon Oct 26 14:54:07 2009 pevik [...] seznam.cz - Correspondence added

Subject:	Re: [rt.cpan.org #50833] DBD-Informix 2008.0513 is not working on perl 5.10
Date:	Mon, 26 Oct 2009 19:53:46 +0100 (CET)
To:	bug-DBD-Informix [...] rt.cpan.org
From:	Petr Vorel <pevik [...] seznam.cz>

Hello Jonathan, there must be something strange, probably on my side. First of all, there is no libisql.a in whole $INFORMIXDIR. That will be probably the problem. But I tried to find the deffinition in all static libraries: /opt/informix $ for i in `find |grep lib.*sql*.a`; do echo $i; nm -g $i | grep ifx_getbigserial; done ./lib/esql/libiffgisql.a ./lib/esql/libthsql.a ./lib/esql/libsql.a ./lib/esql/libifsql.a ./lib/esql/libfgisql.a ./lib/esql/libcobsql.a ./lib/esql/libdb2sql.a ./lib/esql/libdb2ifsql.a ./lib/esql/libifcobsql.a By the way, I've got other versions installed: * version 2.90.UC2 behaves the same as 3.00.UC3DE (no libisql.a, working on perl 5.10.0, not working on perl 5.10.1, no result of grep ifx_getbigserial). * version 3.50.UC1DE (which is not working for some other reason) does not have libisql.a either, but it has ifx_getbigserial with T: /opt/_informix_3.50.UC1DE # for i in `find |grep lib.*sql*.a`; do echo $i; nm -g $i | grep ifx_getbigserial; done ./lib/esql/libifsql.a 00001a73 T ifx_getbigserial ./lib/esql/libiffgisql.a 00001c4e T ifx_getbigserial ./lib/esql/libifcobsql.a 00001a73 T ifx_getbigserial ./lib/esql/libthsql.a 00001b11 T ifx_getbigserial ./lib/esql/libdb2ifsql.a ./lib/esql/libsql.a 00001a73 T ifx_getbigserial ./lib/esql/libfgisql.a 00001c4e T ifx_getbigserial ./lib/esql/libcobsql.a 00001a73 T ifx_getbigserial ./lib/esql/libdb2sql.a Are we closer in finding where is the problem? Thank a lot for your time spent on this. Regards, Petr Show quoted text

> Not sure - but possibly. OTOH, probably not. Let's do some checking... > There should be a library $INFORMIXDIR/lib/esql/libisql.a - on that, run: > > nm -g $INFORMIXDIR/lib/esql/libisql.a | grep ifx_getbigserial > > This should show the function being defined. With ESQL/C 3.50, I got this: > > 00001a73 T ifx_getbigserial > > The number doesn't matter; the 'T' is important.

Mon Oct 26 15:15:23 2009 jonathan.leffler [...] gmail.com - Correspondence added

CC:	Petr Vorel <pevik [...] seznam.cz>
Subject:	Re: [rt.cpan.org #50833] DBD-Informix 2008.0513 is not working on perl 5.10
Date:	Mon, 26 Oct 2009 12:14:33 -0700
To:	bug-DBD-Informix [...] rt.cpan.org
From:	Jonathan Leffler <jonathan.leffler [...] gmail.com>

Apologies Petr - the stray 'i' in libisql.a was a typo -- I meant 'libsql.a'. On Mon, Oct 26, 2009 at 11:54 AM, Petr Vorel via RT < bug-DBD-Informix@rt.cpan.org> wrote: Show quoted text

> Queue: DBD-Informix > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=50833 > > > Hello Jonathan, > > there must be something strange, probably on my side. > First of all, there is no libisql.a in whole $INFORMIXDIR. That will be > probably the problem. > > But I tried to find the deffinition in all static libraries: > /opt/informix $ for i in `find |grep lib.*sql*.a`; do echo $i; nm -g $i | > grep ifx_getbigserial; done > ./lib/esql/libiffgisql.a > ./lib/esql/libthsql.a > ./lib/esql/libsql.a > ./lib/esql/libifsql.a > ./lib/esql/libfgisql.a > ./lib/esql/libcobsql.a > ./lib/esql/libdb2sql.a > ./lib/esql/libdb2ifsql.a > ./lib/esql/libifcobsql.a > > By the way, I've got other versions installed: > * version 2.90.UC2 behaves the same as 3.00.UC3DE (no libisql.a, working on > perl 5.10.0, not working on perl 5.10.1, no result of grep > ifx_getbigserial). >

OK - so BIGINT support was added in CSDK 3.50. Show quoted text

> * version 3.50.UC1DE (which is not working for some other reason) does not > have libisql.a either, but it has ifx_getbigserial with T: > /opt/_informix_3.50.UC1DE # for i in `find |grep lib.*sql*.a`; do echo $i; > nm -g $i | grep ifx_getbigserial; done > ./lib/esql/libifsql.a > 00001a73 T ifx_getbigserial > ./lib/esql/libiffgisql.a > 00001c4e T ifx_getbigserial > ./lib/esql/libifcobsql.a > 00001a73 T ifx_getbigserial > ./lib/esql/libthsql.a > 00001b11 T ifx_getbigserial > ./lib/esql/libdb2ifsql.a > ./lib/esql/libsql.a > 00001a73 T ifx_getbigserial > ./lib/esql/libfgisql.a > 00001c4e T ifx_getbigserial > ./lib/esql/libcobsql.a > 00001a73 T ifx_getbigserial > ./lib/esql/libdb2sql.a > > Are we closer in finding where is the problem? > Thank a lot for your time spent on this. >

Yes - we are much closer to finding the issue. It is an 'environment' issue, in the broad sense of the term. The DBD::Informix you have was built using CSDK 3.50 and needs to be run using that. I'm curious to know what your trouble is with the CSDK 3.50. As I said at the end of the previous email, you really have two choices.. (1) Configure the environment to use the CSDK 3.50 libraries. (2) Rebuild DBD::Informix using CSDK 3.00. Now, there is one other thing to worry about - during the build. You can build DBD::Informix with a fixed INFORMIXDIR location (which is the default) or you can build it with a relocatable INFORMIXDIR. To build it relocatably: DBD_INFORMIX_RELOCATABLE_INFORMIX=1 perl Makefile.PL The advantage of a relocatable INFORMIXDIR is that you can copy the software around and get at different locations for INFORMIXDIR without a recompilation. The downside is the you need to set $INFORMIXDIR and $LD_LIBRARY_PATH before running programs, and programs run by root can have problems. The default allows root and web servers to use DBD::Informix more easily - which is why the default is the default. Show quoted text

> Not sure - but possibly. OTOH, probably not. Let's do some checking...

> > There should be a library $INFORMIXDIR/lib/esql/libisql.a - on that, run: > > > > nm -g $INFORMIXDIR/lib/esql/libisql.a | grep ifx_getbigserial > > > > This should show the function being defined. With ESQL/C 3.50, I got

> this:

> > > > 00001a73 T ifx_getbigserial > > > > The number doesn't matter; the 'T' is important.

-- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

Mon Oct 26 15:54:34 2009 pevik [...] seznam.cz - Correspondence added

Subject:	Re: [rt.cpan.org #50833] DBD-Informix 2008.0513 is not working on perl 5.10
Date:	Mon, 26 Oct 2009 20:54:11 +0100 (CET)
To:	bug-DBD-Informix [...] rt.cpan.org
From:	Petr Vorel <pevik [...] seznam.cz>

Hello Jonathan, Show quoted text

> > Yes - we are much closer to finding the issue. > > It is an 'environment' issue, in the broad sense of the term. > > The DBD::Informix you have was built using CSDK 3.50 and needs to be run > using that.

I'm still surprised why it's working on perl 5.10.0 and not on 5.10.1 ( DBD::Informix is the same package). But that's not important. Show quoted text

> I'm curious to know what your trouble is with the CSDK 3.50.

It's 14503. $ finderr -14503 -14503 CSS error loading <csm-name> Communication Support Services failed to load the library that contains a Communications Support Module. Check the path name of the CSM library in CSS configuration file, and Make sure it is a valid shared library. ------------------------------------------------ I suppose it's another 'environment' issue (my fault). Is that $LD_LIBRARY_PATH issue? To clarify my environment first, I must say I have locations like $ ls _informix_* -d _informix_2.90.UC2 _informix_3.00.UC3DE _informix_3.50.UC1DE and use symlink to use the "right" version: $ ls -l informix lrwxrwxrwx 1 root root 21 Oct 26 21:25 informix -> _informix_3.50.UC1DE/ Can this cause problem? My $LD_LIBRARY_PATH for informix: $ echo $LD_LIBRARY_PATH | tr ':' '\n' |grep informix /opt/informix/lib/ /opt/informix/lib/c++ /opt/informix/lib/cli /opt/informix/lib/client /opt/informix/lib/dmi /opt/informix/lib/esql /opt/informix/lib/ I have other variables defined ($INFORMIXSERVER, $INFORMIXSQLHOSTS, $INFORMIXSQLHOSTS - these are the default ones, and other...) in /etc/profile, so even apache server knows about them. $ env |grep -i inform INFORMIXDIR=/opt/informix/ INFORMIXSERVER=sund5 INFORMIXSQLHOSTS=/etc/informix/sqlhosts Show quoted text

> > As I said at the end of the previous email, you really have two choices.. > (1) Configure the environment to use the CSDK 3.50 libraries. > (2) Rebuild DBD::Informix using CSDK 3.00.

I'd prefer to use (1). Regards, Petr

Tue Oct 27 00:52:42 2009 jonathan.leffler [...] gmail.com - Correspondence added

CC:	Petr Vorel <pevik [...] seznam.cz>
Subject:	Re: [rt.cpan.org #50833] DBD-Informix 2008.0513 is not working on perl 5.10
Date:	Mon, 26 Oct 2009 21:52:02 -0700
To:	bug-DBD-Informix [...] rt.cpan.org
From:	Jonathan Leffler <jonathan.leffler [...] gmail.com>

On Mon, Oct 26, 2009 at 12:54 PM, Petr Vorel via RT < bug-DBD-Informix@rt.cpan.org> wrote: Show quoted text

> Queue: DBD-Informix > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=50833 >

> > Yes - we are much closer to finding the issue. > > > > It is an 'environment' issue, in the broad sense of the term. > > > > The DBD::Informix you have was built using CSDK 3.50 and needs to be run > > using that.

> I'm still surprised why it's working on perl 5.10.0 and not on 5.10.1 ( > DBD::Informix is the same package). But that's not important. >

That is puzzling; I don't have a good explanation for it yet. So, you reinstalled DBD::Informix in a 5.10.1 specific directory, or you're using the same build in some common directory shared by both 5.10.0 and 5.10.1? Mostly curiosity - I never use other people's packaged Perl for long (and I don't modify it - period; not even by adding extensions). Show quoted text

> I'm curious to know what your trouble is with the CSDK 3.50. > It's 14503. > $ finderr -14503 > -14503 CSS error loading <csm-name> > > Communication Support Services failed to load the library that contains a > Communications Support Module. > > Check the path name of the CSM library in CSS configuration file, and > Make sure it is a valid shared library. >

Show quoted text

> ------------------------------------------------ > I suppose it's another 'environment' issue (my fault). Is that > $LD_LIBRARY_PATH issue? >

Well, yes, and no. And I don't like it much. It is a setup problem of some sort, but not LD_LIBRARY_PATH. It is an issue with the concsm.cfg file, normally located in $INFORMIXDIR/etc, unless you set the INFORMIXCONCSMCFG environment variable. The sqlhosts file is also a part of the issue - it identifies the CSM entry in the concsm.cfg file. It would be helpful to see the entry from the sqlhosts file for server sund5, and the concsm.cfg file. To clarify my environment first, I must say I have locations like Show quoted text

> $ ls _informix_* -d > _informix_2.90.UC2 _informix_3.00.UC3DE _informix_3.50.UC1DE >

Interesting. GNU getopt() reorders options like '-d' so that they appear ahead of non-options like the expansion of '*'; I uses systems where I could not do what you just did. (GNU getopt() behaves in the ordinary way if you set environment variable POSIXLY_CORRECT.) Show quoted text

> and use symlink to use the "right" version: > $ ls -l informix > lrwxrwxrwx 1 root root 21 Oct 26 21:25 informix -> _informix_3.50.UC1DE/ > Can this cause problem? >

Not if everything is set up correctly - I do this all the time. Show quoted text

> My $LD_LIBRARY_PATH for informix: > $ echo $LD_LIBRARY_PATH | tr ':' '\n' |grep informix > /opt/informix/lib/ > /opt/informix/lib/c++ > /opt/informix/lib/cli > /opt/informix/lib/client > /opt/informix/lib/dmi > /opt/informix/lib/esql > /opt/informix/lib/ >

Unless you are working with all those various sub-systems, you normally only need $INFORMIXDIR/lib and $INFORMIXDIR/lib/esql on the LD_LIBRARY_PATH. Certainly, that's all I have unless I'm using the DMI, C++ or ODBC (CLI) libraries. However, this is just an 'optimization'; it avoids searching too many directories. Show quoted text

> I have other variables defined ($INFORMIXSERVER, $INFORMIXSQLHOSTS, > $INFORMIXSQLHOSTS - these are the default ones, and other...) in > /etc/profile, so even apache server knows about them. > $ env |grep -i inform > INFORMIXDIR=/opt/informix/ > INFORMIXSERVER=sund5 > INFORMIXSQLHOSTS=/etc/informix/sqlhosts > >

> > As I said at the end of the previous email, you really have two choices.. > > (1) Configure the environment to use the CSDK 3.50 libraries. > > (2) Rebuild DBD::Informix using CSDK 3.00.

> I'd prefer to use (1). >

Fair enough. I'd prefer you to be able to do so. I still don't have an explanation for 5.10.0 OK and 5.10.1 not-OK. That worries me - I must be overlooking something. -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

Tue Oct 27 05:50:42 2009 pevik [...] seznam.cz - Correspondence added

Subject:	Re: [rt.cpan.org #50833] DBD-Informix 2008.0513 is not working on perl 5.10
Date:	Tue, 27 Oct 2009 10:50:20 +0100 (CET)
To:	bug-DBD-Informix [...] rt.cpan.org
From:	Petr Vorel <pevik [...] seznam.cz>

Show quoted text

> That is puzzling; I don't have a good explanation for it yet. > So, you reinstalled DBD::Informix in a 5.10.1 specific directory, or you're > using the same build in some common directory shared by both 5.10.0 and > 5.10.1? > Mostly curiosity - I never use other people's packaged Perl for long (and I > don't modify it - period; not even by adding extensions).

I'm using it as a package http://packages.debian.org/sid/libdbd-informix-perl, files are http://packages.debian.org/sid/i386/libdbd-informix-perl/filelist - so just like you wrote - common directory shared by both 5.10.0 and 5.10.1. Show quoted text

> Well, yes, and no. And I don't like it much. It is a setup problem of some > sort, but not LD_LIBRARY_PATH. > It is an issue with the concsm.cfg file, normally located in > $INFORMIXDIR/etc, unless you set the INFORMIXCONCSMCFG environment variable. > The sqlhosts file is also a part of the issue - it identifies the CSM entry > in the concsm.cfg file.

Oops, my silly mistaque - 3.5 does not have iencs09a.so, but iencs11a.so. And because I made symlinks to concsm.cfg (same file for all versions), it died because file was missing. Error message was clear, but I just didn't get it... Thanks for it and sorry for bothering you with it - now is 3.5 working on both perl versions 5.10.0 and 5.10.1. Show quoted text

> To clarify my environment first, I must say I have locations like

> > $ ls _informix_* -d > > _informix_2.90.UC2 _informix_3.00.UC3DE _informix_3.50.UC1DE > >

> > Interesting. GNU getopt() reorders options like '-d' so that they appear > ahead of non-options like the expansion of '*'; I uses systems where I could > not do what you just did. (GNU getopt() behaves in the ordinary way if you > set environment variable POSIXLY_CORRECT.)

That's what I like on GNU :-) (and dislake on non GNU). Most of the time it really does not matter where I put parameters. So if I'm editing command (using emacs mode) I put them at the end. I'd never set POSIXLY_CORRECT (which works as you said). OT: I care about POSIXLY_CORRECT and avoiding bashisms just in init scripts. Show quoted text

> Unless you are working with all those various sub-systems, you normally only > need $INFORMIXDIR/lib and $INFORMIXDIR/lib/esql on the LD_LIBRARY_PATH. > Certainly, that's all I have unless I'm using the DMI, C++ or ODBC (CLI) > libraries. However, this is just an 'optimization'; it avoids searching too > many directories.

Thanks a lot, I'll clean up a bit my LD_LIBRARY_PATH. Show quoted text

> I still don't have an explanation for 5.10.0 OK and 5.10.1 not-OK. That > worries me - I must be overlooking something.

I'd like to be sure that it's just my mistaque, nor anybody's else. Again thanks a lot for your time. Regards, Petr

Tue Oct 27 09:39:38 2009 j.leffler [...] acm.org - Correspondence added 60 min

After exchanging a number of emails, we have got the system working correctly without any changes required in DBD::Informix. It was a moderately complex setup problem for Informix CSDK - getting the correct version configured correctly. -- Jonathan Leffler <jleffler@earthlink.net> <jleffler@us.ibm.com> Guardian of DBD::Informix 2008.0513 -- see http://dbi.perl.org/ "I don't suffer from insanity - I enjoy every minute of it!"

Tue Oct 27 09:39:40 2009 j.leffler [...] acm.org - Status changed from 'open' to 'resolved'