Re: Informix-ESQLC non-functional on RedHat 9?

There are actually 2 separate causes for the error messages listed in Jay Hannah's original mail. For the "incorrectly built binary" messages, PTS 162102 (for the engine side) is fixed in IDS 9.40.UC2. The ESQL/C (client side) problem is fixed in CSDK 2.81.UC2. Both are currently targeted to be released end of June. The "undefined reference to `__ctype_b`" messages are due to a different problem with the glibc 2.3.2 in RedHat 9. __ctype_b has been renamed to __ctype_b_loc in RedHat 9 and this is causing our ESQL/C which is built on an earlier Kernel/glibc version to be incompatible. The only workaround we know at this time is to use SuSE 8.2 which also has glibc 2.3.2, but ESQL/C is working there. Helen Ronald Cole <ronald@forte-int To: informix-list@iiug.org l.com> cc: Sent by: Subject: Re: Informix-ESQLC non-functional on RedHat 9? owner-informix-li st@iiug.org 05/02/2003 03:32 PM Please respond to Ronald Cole jhannah@omnihotels.com (Jay Hannah) writes: > "Madison Pruet" <mpruet@attbi.com> wrote in message news:<nvDia.301993$F1.51963@sccrnsc04>... > > Thanks for pointing out this issue. It appears to be a change in the libc > > library used in RH 9 that is leading to the message. We have opened a bug > > on the problem (162102). At this time, we think that it is a cosmetic > > problem. > > How is 162102 coming? Can I see Informix/IBM's bug statuses online > somewhere? > > We appear to be dead in the water on RedHat 9. The current CSDK > installs OK, but then running the utilities throws "Incorrectly built > errors": > > [root@royal informix]# 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 > > Earlier posters have pointed out that this is a problem for PHP. Like > them, I would insist that this is more than a cosmetic problem. Perl's > DBD::Informix is refusing to get off the ground (after some basic > hackery): IMO, this message isn't cosmetic. Glibc-2.3.2 in RHL9 has switched to using thread-local storage for errno (as defined by the TLS ABI). As you can see: # ldd /opt/informix/bin/oninit libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4002c000) libdl.so.2 => /lib/libdl.so.2 (0x4003a000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4003e000) libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x4006c000) libm.so.6 => /lib/tls/libm.so.6 (0x400ae000) libc.so.6 => /lib/tls/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x400d0000) What the error means is that IDS has at least one: extern int errno; where it should have the proper incarnation: #include <errno.h> This threading change also kills Java in the server on RHL9. So, obviously, I don't consider the problem of IDS-9.4 possibly not getting the correct errno when an error occurs or not having Java in the server on RHL9 to be "cosmetic". If an engine problem occurs, I expect to get the proper errno reported in the log. -- Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412 Ronald Cole <ronald@forte-intl.com> Phone: (760) 499-9142 President, CEO Fax: (760) 499-9152 My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084 4A88 8851 E6C8 69E3 B00B