Upgrade to glibc 2.3.4 breaks Linux ifort binaries

Dear all,

I've just upgraded my home and work desktop Linux boxen to glibc
2.3.4.20040808, and this appears to have broken one of my programs that
was compiled with ifort.

I had a hell of a job tracking down the source of this problem. The
binary suddenly stopped working a couple of days ago, crapping out with
a segmentation fault upon entering a particular routine. At first, I
thought it was a CPU architecture problem, since the program still
worked on my Pentium 4 laptop (the desktop machines are Athlon XPs).

However, I found that if I recompiled  on my laptop, and used static
linking, then the program would work fine on the desktop machines. This
indicates that one or more of the dynamic libraries on the desktops is
borked, and the recent upgrade of the desktops (but not the laptop) to
glibc 2.3.4 is the smoking gun.

I'm writing about this here as a heads up to those who may encounter
similar problems. For reference, ldd gives this for the program:

rhdt@cmell boojum $ ldd boojum_lite.IA32
linux-gate.so.1 =>  (0xffffe000)
libg2c.so.0 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libg2c.so.0
(0x4001f000)
libm.so.6 => /lib/libm.so.6 (0x4003c000)
libcxa.so.5 => /opt/intel/intel_fc_81/lib/libcxa.so.5 (0x4005d000)
libunwind.so.5 => /opt/intel/intel_fc_81/lib/libunwind.so.5 (0x40083000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40089000)
libc.so.6 => /lib/libc.so.6 (0x400d9000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

It appears that the problem involves one of libm, libpthread, libc or
ld-linux.

cheers,

Rich

PS Note to Steve Lionel: how should I go about submitting this problem
to Intel? The source for the program is c. 30,000 lines of
preprocessor-mangled code -- is that acceptable?

--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware

[ Delete VOID for valid email address ]

"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:ckjpm7$i25$1@scrotar.nss.udel.edu...
> Dear all,
>
> I've just upgraded my home and work desktop Linux boxen to glibc
> 2.3.4.20040808, and this appears to have broken one of my programs that
> was compiled with ifort.
>
If you make a major change in glibc, such as 2.2.x to 2.3.x, without
re-installing the compiler, or figuring out how to re-configure it, you can
expect such problems.  I don't know how many people on this list could be
expected to recognize specific sub-versions of glibc; the versions I've had
to deal with overflow my aged brain.

Tim Prince wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:ckjpm7$i25$1@scrotar.nss.udel.edu...
> 
>
> If you make a major change in glibc, such as 2.2.x to 2.3.x, without
> re-installing the compiler, or figuring out how to re-configure it, you ca
n
> expect such problems.  I don't know how many people on this list could be
> expected to recognize specific sub-versions of glibc; the versions I've ha
d
> to deal with overflow my aged brain.
>
>

But surely the whole idea of a library is that, even though it may
evolve internallly, its external API remains the same? I'd be amazed if
the code emitted by ifort had any reliance on the *internal*
organization of glibc; and therefore I'm stumped by the actual cause of
the problems I encountered.

For the record, my glibc was upgraded from 2.3.3 -- a pretty minor
increment.

cheers,

Rich

--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware

[ Delete VOID for valid email address ]