Bug 81005

Only programs/libs compiled against glibc 2.0.x may refer to errno directly,
and the dynamic linker handles it.
The rest are just buggy programs or libraries.
They need to be fixed, ie. use #include <errno.h> when they want to access
errno instead of declaring it themselves.
If such bugs are in phoebe packages, please file a bugzilla report against them,
otherwise tell the authors to fix it.
As a workaround, you can use LD_ASSUME_KERNEL=2.2.5 /usr/local/bin/ez-ipupdate
etc. to make it work.

Thanks for the clarification.

I'm sure that Phoebe pachages are fine in this respect.

In the real world, where people tend to use RPM packages from other sources than
Red Hat proper, then this behaviour, if maintained, is going to create serious
headache. 

When you upgrade an existing machine, and find that many of the programs that
used to work fine no longer does so, then this is a serious problem IMHO.

For instance, I can find no dosemu or wine RPM package out there that will run
with Phoebe. Including stuff from Red Hat Power tools, Red Hat contrib, and
other sources. These packages cause no complaint with respect to RPM
dependencies, and IMHO I thought we had a situation were backward compatibility
was a goal! 

I predict major uproar if this situation is retained, since this will cause lack
of backward compatibility for very many people. 

I'm sure that in theory you are right: That on Alpha Centauri there has been a
rule that stated "thou shalt not dedclare errno yourself". But in the real
world, people have been doing that since 1979 or thereabouts. 

Since a workaround seems to be so simple, I would really, really urge you to let
the workarond happen automatically so that backward compatibility is assured.

This is nothing you have to read from stars, standards like ISO C, POSIX
or Unix98 etc. require including the header before using the variable.
Let me e.g. cite from ISO C99, 7.5/2:
"It is unspecified whether errno is a macro or an identifier declared with
external linkage. If a macro definition is suppressed in order to access an
actual object, or a program defines an identifier with the name errno, the
behavior is undefined."
glibc declares errno as *__errno_location () since early 1998.

The removal of {errno,h_errno,_res}@GLIBC_2.0 from /lib/tls/libc.so.6
was done because the variables really cannot be supported by the thread local
storage implementation, they stay only in the compatibility /lib/libc.so.6
which doesn't use TLS nor supports the new thread library.

It is not possible to make the workaround happen automatically, unless you
simply remove the new thread library and TLS libc, because the decision whether
to use /lib/tls/ or /lib libraries must be done before all the libraries
are mapped and symbol lookup happens (at which point it can be seen if
the program or its libraries access errno etc).
A big problem here is also that most of the broken binaries will have COPY
relocs against errno, ie. even if some magic rules for symbol
lookup were applied (for single threaded programs, multithreaded programs
using errno did not used to work anyway), binaries still want the errno
in their .bss to be used instead of the one glibc gives them.