I had installed an amd64 system (debian unstable) a few weeks back (this
is the system I am on now), I got most of my applications (both 32 and 64)
working (using ia32-libs version-1.5).  When I tried to do the same on a
friend's laptop I got ALOT of problems with 32-bit applications (from
big EDA companies) complaining about GLIBC_2.0 not being defined.  On
the advice of 'mrvn' (from #debian-amd64) I downgraded the laptop's
ia32-libs from 1.6 to 1.4 (sarge -- we didn't know how to grab 1.5) and
the complaints ceased and all functions properly now.

The issue as it stands is, what changed in glibc between 1.5 and 1.6 relating
to GLIBC_2.0 and could this "GLIBC_2.0" tag be reintroduced ?  Fedora/RH seem
to be handling this problem somehow since other friends note things working
for them with the latest beta releases (akin to debian's unstable) without
any issues.

BTW: the laptop's system info is pasted below post the change-over from 1.6
     back to 1.4 on its ia32-libs.

Please post the full error message instead of paraphrasing.

--- Steve Langasek <vorlon-at-debian.org> wrote:

Unfortunately I don't have immediate access to the laptop in order to
reinstall version-1.6 of the lib (to break things again :-) - I should
have saved-off the message, oops.  I'll attempt to get access to the
laptop in the next few days.  The error as I remember it though was,

  symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time
reference

What's interesting is that version 1.5 works perfectly fine where-as
1.6 doesn't.  Let me know if you need more info or supply me with debug
instructions for when I get 1.6 installed as I get the feeling I won't
be able to go back to 1.6 too often.

Thanks & Regards,

 - Nadim

severity 364698 wishlist
thanks

Ok, this isn't a symbol that's coming back.  Any applications that declare
"extern int errno" instead of including the errno.h header file have been
buggy for some time, because errno is not guaranteed to be implemented as an
int in glibc -- and indeed, with NPTL versions of glibc (which is the
default, and preferred, implementation on Linux 2.6 kernels), it cannot be
implemented as an int.

Now, the ia32-libs maintainers *could* include a non-NPTL build of glibc in
ia32-libs, and then you could use LD_ASSUME_KERNEL=2.4.1 to force the use of
this backwards-compatible glibc with the errno@GLIBC_2.0 symbol; but given
that even the i386 port of etch isn't going to support these applications by
default, I'm not sure I see the point...

Anyway, downgrading as this bug only affects a particular set of (misbuilt)
applications, it doesn't make ia32-libs completely unusable.  It's up to the
ia32-libs maintainers whether they want to implement this for etch.

Steve Langasek <vorlon@debian.org> writes:

No, we can't. We don't provide any libc at all anymore. :)

Glibc builds a 32bit libc6 for amd64 and ia32-libs has depended on it
for the last few versions.


If you need this ancient, broken errno variable then you have to stick
with stable I guess. But it is out of our hands and in the hands of
the glibc team. reassigning the bug there.

MfG
        Goswin

current libc6 is built with kernel version 3.2.0, so
`LD_ASSUME_KERNEL=2.4.1` is pretty  much impossible to run these days.