Informix-ESQLC, DBD::Informix, RedHat 9
Jay Hannah
Greetings --
I think this is an Informix-ESQLC and kernel problem, not Perl 5.8.0, DBI, nor DBD::Informix; but I thought I'd post it here in case I'm wrong... (I'm fishing in comp.databases.informix if you're curious to read that.)
Default install of RedHat 9 on Intel. Perl 5.8.0, DBI-1.35, IBM Informix CSDK Version 2.81, IBM Informix-ESQL Version 9.53.UC1, DBD-Informix-2003.04
CSDK installs fine, but running utilities throws "Incorrectly built binary" errors:
--------------------------------------------------------
[root@royal DBD-Informix-2003.04]# esql -V
Incorrectly built binary which accesses errno, h_errno or _res directly. Needs to be fixed.
IBM Informix CSDK Version 2.81, IBM Informix-ESQL Version 9.53.UC1
Software Serial Number RDS#N000000
--------------------------------------------------------
That first line of output confuses lib/DBD/Informix/Configure.pm's read of "esql -V". So, it throws this error:
--------------------------------------------------------
[root@royal DBD-Informix-2003.04]# perl Makefile.PL
*** ExtUtils::AutoInstall version 0.50
*** Checking for dependencies...
[Core Features]
- DBI ...loaded. (1.34 >= 1.33)
[High Resolution Timing]
- Time::HiRes ...loaded. (1.46)
*** ExtUtils::AutoInstall configuration finished.
Subroutine main::WriteMakefile redefined at /usr/lib/perl5/site_perl/5.8.0/ExtUtils/AutoInstall.pm line 439.
Configuring IBM Informix Database Driver for Perl Version 2003.04 (2003-03-05) (aka DBD::Informix)
You are using DBI version 1.34 and Perl version 5.008
Remember to actually read the README file!
Perl: perl5.008 i386-linux-thread-multi dl_dlopen.xs
System: linux stripples.devel.redhat.com 2.4.20-2.48smp #1 smp thu feb 13 11:44:55 est 2003 i686 i686 i386 gnulinux
Compiler: gcc -O2 -march=i386 -mcpu=i686 -g -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm
Unexpected message from esql script -- Incorrectly built binary which accesses errno, h_errno or _res directly. Needs to be fixed.
--------------------------------------------------------
(Why does it think it's Perl version 5.008? The only Perl on the system is 5.8.0. -shrug-)
I hacked Configure.pm up to get past that error, but now I'm hitting this:
--------------------------------------------------------
[root@royal DBD-Informix-2003.04]# perl Makefile.PL
*** ExtUtils::AutoInstall version 0.50
*** Checking for dependencies...
[Core Features]
- DBI ...loaded. (1.34 >= 1.33)
[High Resolution Timing]
- Time::HiRes ...loaded. (1.46)
*** ExtUtils::AutoInstall configuration finished.
Subroutine main::WriteMakefile redefined at /usr/lib/perl5/site_perl/5.8.0/ExtUtils/AutoInstall.pm line 439.
Configuring IBM Informix Database Driver for Perl Version 2003.04 (2003-03-05) (aka DBD::Informix)
You are using DBI version 1.34 and Perl version 5.008
Remember to actually read the README file!
Perl: perl5.008 i386-linux-thread-multi dl_dlopen.xs
System: linux stripples.devel.redhat.com 2.4.20-2.48smp #1 smp thu feb 13 11:44:55 est 2003 i686 i686 i386 gnulinux
Compiler: gcc -O2 -march=i386 -mcpu=i686 -g -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm
Using IBM Informix CSDK Version 2.80, IBM Informix-ESQL Version 9.52.UC2 from /usr/local/informix
Beware: DBD::Informix is not yet aware of all the new IUS data types.
Assert macro will be disabled!
Use of uninitialized value in concatenation (.) or string at Makefile.PL line 1070.
Use of uninitialized value in concatenation (.) or string at Makefile.PL line 1098.
lib/DBD/Informix/Defaults.pm written OK
esqlvrsn.h written OK
esqlinfo.h written OK
Testing whether your Informix test environment will work...
Incorrectly built binary which accesses errno, h_errno or _res directly. Needs to be fixed.
Incorrectly built binary which accesses errno, h_errno or _res directly. Needs to be fixed.
/usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_b'
/usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_toupper'
/usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_tolower'
collect2: ld returned 1 exit status
Failed to link test program esqltest
--------------------------------------------------------
I don't know what to do about libifgls.so, since I'm not a C programmer. Any suggestions?
Thanks for any help!
Jay Hannah
More configuration info:
--------------------------------------------------------
[root@royal DBD-Informix-2003.04]# uname -a
Linux royal.omnihotels.com 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux
[root@royal DBD-Informix-2003.04]# perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.20-2.48smp, archname=i386-linux-thread-multi
uname='linux stripples.devel.redhat.com 2.4.20-2.48smp #1 smp thu feb 13 11:44:55 est 2003 i686 i686 i386 gnulinux '
config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -g -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -march=i386 -mcpu=i686 -g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.2.2 20030213 (Red Hat Linux 8.0 3.2.2-1)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil
libc=/lib/libc-2.3.1.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.1'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Locally applied patches:
MAINT18379
Built under linux
Compiled at Feb 18 2003 22:19:53
@INC:
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
.
Jonathan Leffler
> Greetings --
>
> I think this is an Informix-ESQLC and kernel problem, not Perl
> 5.8.0, DBI, nor DBD::Informix; but I thought I'd post it here in case
> I'm wrong... (I'm fishing in comp.databases.informix if you're curious
> to read that.)
Fundamentally, it is a problem triggered by RedHat getting
(justifiably) stroppy with programs that are careless about how they
declare errno -- and CSDK appears to be such a program. You can also
get the same error from IDS on RedHat 9, too, I believe.
However, to the extent that DBD::Informix does not build when it
could, it is also a problem for that.
Because Perl 5.8.0 tells you it is Perl 5.008 when you ask it what its
version is.
So, the fix is to revise the code in lib/DBD/Informix/Configure.pm so
that it looks for the line which matches Informix and ESQL and Version
and processes the first (or last) such line in the output, ignoring
the others. That's basically what the fix I've got to provide will
have to do - you can get yourself under way by hacking it. The
function in question is get_esqlc_version. You'll need to revise the
code from the unorthodox loop that currently exists into a more
orthodox loop:
while (<ESQL>)
{
if (m/Informix.*Version /i)
{
$infv = $_;
# The code that analyzes $infv goes here...
chomp $infv; ...etc...
}
}
close ESQL;
return $infv, $vers;
> I hacked Configure.pm up to get past that error, but now I'm hitting this:
>
> --------------------------------------------------------
> [root@royal DBD-Informix-2003.04]# perl Makefile.PL
> *** ExtUtils::AutoInstall version 0.50
> *** Checking for dependencies...
> [Core Features]
> - DBI ...loaded. (1.34 >= 1.33)
> [High Resolution Timing]
> - Time::HiRes ...loaded. (1.46)
> *** ExtUtils::AutoInstall configuration finished.
> Subroutine main::WriteMakefile redefined at /usr/lib/perl5/site_perl/5.8.0/ExtUtils/AutoInstall.pm line 439.
>
> Configuring IBM Informix Database Driver for Perl Version 2003.04 (2003-03-05) (aka DBD::Informix)
> You are using DBI version 1.34 and Perl version 5.008
> Remember to actually read the README file!
>
> Perl: perl5.008 i386-linux-thread-multi dl_dlopen.xs
> System: linux stripples.devel.redhat.com 2.4.20-2.48smp #1 smp thu feb 13 11:44:55 est 2003 i686 i686 i386 gnulinux
> Compiler: gcc -O2 -march=i386 -mcpu=i686 -g -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm
>
> Using IBM Informix CSDK Version 2.80, IBM Informix-ESQL Version 9.52.UC2 from /usr/local/informix
>
> Beware: DBD::Informix is not yet aware of all the new IUS data types.
>
> Assert macro will be disabled!
>
> Use of uninitialized value in concatenation (.) or string at Makefile.PL line 1070.
> Use of uninitialized value in concatenation (.) or string at Makefile.PL line 1098.
Hmmmmmmmmm; that means you have not got $INFORMIXSERVER set in the
environment. That is the one environment variable that is absolutely
compulsory - no excuses, ifs or buts. I need to fix Makefile.PL to
complain vehemently if it is not set!
> lib/DBD/Informix/Defaults.pm written OK
> esqlvrsn.h written OK
> esqlinfo.h written OK
>
> Testing whether your Informix test environment will work...
> Incorrectly built binary which accesses errno, h_errno or _res directly. Needs to be fixed.
> Incorrectly built binary which accesses errno, h_errno or _res directly. Needs to be fixed.
Ick!
> /usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_b'
> /usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_toupper'
> /usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_tolower'
> collect2: ld returned 1 exit status
> Failed to link test program esqltest
> --------------------------------------------------------
Please rerun with DBD_INFORMIX_DEBUG_ESQLTEST set to 1 or 'yes' in the
environment -- I need to see what's going on here. I may end up
needing more information still; I'll let you know.
> I don't know what to do about libifgls.so, since I'm not a C programmer. Any suggestions?
The libif*.so libraries are usually Informix libraries, and this one
is specifically the Informix GLS library. I wonder where the values
are expected to come from? Probably an older version of GLIBC...
Have you checked whether there is a compatibility mode compiler and
library set for RH9? If so, you probably need to use them - but that
isn't the end of the story -- you'd have to rebuild Perl too...
Frankly, RH is as bad as MS on the upgrade game -- they routinely
break code compiled to work with previous versions of their system.
One day, they'll mature enough to provide seamless automatic upgrades
for old software, but until then, every upgrade seems to break that
which used to work on the previous release of the o/s. And they seem
to be arrogant enough not to be vastly worried by it. Arguably,
IBM/Informix should be using the Linux Standard Base libraries, but
then you'd have to have Perl built with that, and you'd have to use
the correct compiler, etc. It's very frustrating!
There could also be some fun to be had with the libraries - that's a
threaded Perl, so probably you need to force the use of shared and
thread-safe ESQL/C libraries (DBD_INFORMIX_ESQLC_LINKAGE to "-shared
-thread"), and set the relevant environment variable for ESQL/C - I
think it is THREADLIB=posix, but check the release notes and machine
notes (for CSDK).
I probably need to do some checking in Makefile.PL for threaded Perls,
something which has not previously been a major problem but which is
clearly about to become rampant in the mainstream (of Linux, anyway).
--
Jonathan Leffler (jlef...@earthlink.net, jlef...@us.ibm.com)
#include <disclaimer.h>
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
Jay Hannah
Sorry for the delayed response. I've been swamped...
> -----Original Message-----
> From: Jonathan Leffler [mailto:jlef...@earthlink.net]
> Sent: Thursday, May 01, 2003 11:14 PM
> > /usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_b'
> > /usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_toupper'
> > /usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_tolower'
> > collect2: ld returned 1 exit status
> > Failed to link test program esqltest
>
> Please rerun with DBD_INFORMIX_DEBUG_ESQLTEST set to 1 or 'yes' in the
> environment -- I need to see what's going on here. I may end up
> needing more information still; I'll let you know.
Ok. Here it is (after hacking lib/DBD/Informix/Configure.pm to get past the "esql -V" garbage.)
----------------------------------------------------
[root@royal DBD-Informix-2003.04]# perl Makefile.PL
*** ExtUtils::AutoInstall version 0.50
*** Checking for dependencies...
[Core Features]
- DBI ...loaded. (1.34 >= 1.33)
[High Resolution Timing]
- Time::HiRes ...loaded. (1.46)
*** ExtUtils::AutoInstall configuration finished.
Subroutine main::WriteMakefile redefined at /usr/lib/perl5/site_perl/5.8.0/ExtUtils/AutoInstall.pm line 439.
Configuring IBM Informix Database Driver for Perl Version 2003.04 (2003-03-05) (aka DBD::Informix)
You are using DBI version 1.34 and Perl version 5.008
Remember to actually read the README file!
Perl: perl5.008 i386-linux-thread-multi dl_dlopen.xs
System: linux stripples.devel.redhat.com 2.4.20-2.48smp #1 smp thu feb 13 11:44:55 est 2003 i686 i686 i386 gnulinux
Compiler: gcc -O2 -march=i386 -mcpu=i686 -g -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm
Using IBM Informix CSDK Version 2.81, IBM Informix-ESQL Version 9.53.UC1 from /usr/local/informix
Beware: DBD::Informix is not yet aware of all the new IUS data types.
Assert macro will be disabled!
lib/DBD/Informix/Defaults.pm written OK
esqlvrsn.h written OK
esqlinfo.h written OK
Testing whether your Informix test environment will work...
+ INFORMIXC='/usr/bin/perl esqlcc' ESQLCC='gcc' esql -c -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -DESQLC_VERSION=953 -DNDEBUG esqltest.ec
Incorrectly built binary which accesses errno, h_errno or _res directly. Needs to be fixed.
+ INFORMIXC='/usr/bin/perl esqlcc' ESQLCC='gcc' esql -c -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -DESQLC_VERSION=953 -DNDEBUG esqlc_v6.ec
Incorrectly built binary which accesses errno, h_errno or _res directly. Needs to be fixed.
+ INFORMIXC='/usr/bin/perl esqlcc' ESQLCC='gcc' esql -o esqltest esqltest.o esqlc_v6.o
/usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_b'
/usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_toupper'
/usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_tolower'
collect2: ld returned 1 exit status
Failed to link test program esqltest
-------------------------------------------
> > I don't know what to do about libifgls.so, since I'm not a
> C programmer. Any suggestions?
>
> The libif*.so libraries are usually Informix libraries, and this one
> is specifically the Informix GLS library. I wonder where the values
> are expected to come from? Probably an older version of GLIBC...
-ponder- My cluelessness abounds.
> Have you checked whether there is a compatibility mode compiler and
> library set for RH9? If so, you probably need to use them - but that
> isn't the end of the story -- you'd have to rebuild Perl too...
Gak. Wow. No thanks. I'm preferring any of these courses of action first: (1) switch to Slackware (2) switch to Gentoo (3) wait for IBM/Informix to release CSDK 2.81.UC2, which fixes the problem according to this article:
> Frankly, RH is as bad as MS on the upgrade game -- they routinely
> break code compiled to work with previous versions of their system.
Hence my options (2) and (3) above. -grin-
> One day, they'll mature enough to provide seamless automatic upgrades
> for old software, but until then, every upgrade seems to break that
> which used to work on the previous release of the o/s. And they seem
> to be arrogant enough not to be vastly worried by it. Arguably,
> IBM/Informix should be using the Linux Standard Base libraries, but
> then you'd have to have Perl built with that, and you'd have to use
> the correct compiler, etc. It's very frustrating!
-ponder- Still vastly less frustrating than Bill's world, IMHO.
> There could also be some fun to be had with the libraries - that's a
> threaded Perl, so probably you need to force the use of shared and
> thread-safe ESQL/C libraries (DBD_INFORMIX_ESQLC_LINKAGE to "-shared
> -thread"), and set the relevant environment variable for ESQL/C - I
> think it is THREADLIB=posix, but check the release notes and machine
> notes (for CSDK).
Wow. Sorry, this is over my head again. I try to stick to default install of Linux distro X, plus CPAN.pm'ing all the latest modules... Seems to keep me (relatively) out of trouble. I'm a data monkey, not a system/C/libc/kernel guru. -grin-
> I probably need to do some checking in Makefile.PL for threaded Perls,
> something which has not previously been a major problem but which is
> clearly about to become rampant in the mainstream (of Linux, anyway).
Thanks for the help! Did you want me to send you a patch for Configure.pm to try to survive this stupidity?:
--------------------
[root@royal DBD-Informix-2003.04]# esql -V
Incorrectly built binary which accesses errno, h_errno or _res directly. Needs to be fixed.
IBM Informix CSDK Version 2.81, IBM Informix-ESQL Version 9.53.UC1
Software Serial Number RDS#N000000
--------------------
Cheers,
j
jha...@omnihotels.com
----------------------------------------------------------------------
This is a repost. My Outlook client has mysteriously decided to start
line wrapping, regardless of the encoding type I tell it. I have
punted/upgraded to pine for this repost. My apologies! -Jay
-----------------------------------------------------------------------
-ponder- My cluelessness abounds.
Hence my options (1) and (2) above. -grin-
> One day, they'll mature enough to provide seamless automatic upgrades
> for old software, but until then, every upgrade seems to break that
> which used to work on the previous release of the o/s. And they seem
> to be arrogant enough not to be vastly worried by it. Arguably,
> IBM/Informix should be using the Linux Standard Base libraries, but
> then you'd have to have Perl built with that, and you'd have to use
> the correct compiler, etc. It's very frustrating!
-ponder- Still vastly less frustrating than Bill's world, IMHO.
> There could also be some fun to be had with the libraries - that's a
> threaded Perl, so probably you need to force the use of shared and
> thread-safe ESQL/C libraries (DBD_INFORMIX_ESQLC_LINKAGE to "-shared
> -thread"), and set the relevant environment variable for ESQL/C - I
> think it is THREADLIB=posix, but check the release notes and machine
> notes (for CSDK).
Wow. Sorry, this is over my head again. I try to stick to default install
of Linux distro X, plus CPAN.pm'ing all the latest modules... Seems to
keep me (relatively) out of trouble. I'm a data monkey, not a
system/C/libc/kernel guru. -grin-
Thanks for the help! Did you want me to send you a patch for Configure.pm
Jonathan Leffler
> ----------------------------------------------------------------------
> This is a repost. My Outlook client has mysteriously decided to start
> line wrapping, regardless of the encoding type I tell it. I have
> punted/upgraded to pine for this repost. My apologies! -Jay
> -----------------------------------------------------------------------
Thanks for the repost.
>>>/usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_b'
>>>/usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_toupper'
>>>/usr/local/informix/lib/esql/libifgls.so: undefined reference to `__ctype_tolower'
>>>collect2: ld returned 1 exit status
>>>Failed to link test program esqltest
>>
[...the same result...]
>
>>>I don't know what to do about libifgls.so, since I'm not a
>>>C programmer. Any suggestions?
>>
>>The libif*.so libraries are usually Informix libraries, and this one
>>is specifically the Informix GLS library. I wonder where the values
>>are expected to come from? Probably an older version of GLIBC...
>
> -ponder- My cluelessness abounds.
>
>>Have you checked whether there is a compatibility mode compiler and
>>library set for RH9? If so, you probably need to use them - but that
>>isn't the end of the story -- you'd have to rebuild Perl too...
>
>
> Gak. Wow. No thanks. I'm preferring any of these courses of action first:
> (1) switch to Slackware (2) switch to Gentoo (3) wait for IBM/Informix to
> release CSDK 2.81.UC2, which fixes the problem according to this article:
>
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=b8v8ij%246dp%241%40terabinaries.xmission.com
Fair enough - but its fair to assume that where RH leads, the others
will follow sooner rather than later. That is, the shelf life of the
9.40.UC1 release for Linux is limited because of the changes being
made to the GNU C Library. And the defective use of errno in the
ESQL/C code.
>>Frankly, RH is as bad as MS on the upgrade game -- they routinely
>>break code compiled to work with previous versions of their system.
>
>
> Hence my options (1) and (2) above. -grin-
>
>
>>One day, they'll mature enough to provide seamless automatic upgrades
>>[...]
>
> -ponder- Still vastly less frustrating than Bill's world, IMHO.
Yes!
>>[...]
> I'm a data monkey, not a system/C/libc/kernel guru. -grin-
OK - choose option 3, probably. Or 1 or 2 if the need is urgent.
> Thanks for the help! Did you want me to send you a patch for Configure.pm
> to try to survive this stupidity?:
I've hacked Configure.pm to pull the version from the first output
line that contains version information, rather than just the first
output line. For the rest, the failure to build the test program
speaks volumes - it isn't the best possible way of resolving the
problem, but it does work.
> --------------------
> [root@royal DBD-Informix-2003.04]# esql -V
> Incorrectly built binary which accesses errno, h_errno or _res directly. Needs to be fixed.
> IBM Informix CSDK Version 2.81, IBM Informix-ESQL Version 9.53.UC1
> Software Serial Number RDS#N000000
> --------------------