From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021216 Description of problem: Running /usr/local/bin/ez-ipupdate (which is a small program I compiled when I was running 8.0, I get: /usr/local/bin/ez-ipupdate: relocation error: /usr/local/bin/ez-ipupdate: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference Same thing happens with other software, e.g. wine (from rpm package wine-20020605-2), which gives: wine: relocation error: wine: symbol h_errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference Probably ez-ipupdate is a better example since it is a small program with no fancy library references: $ ldd /usr/local/bin/ez-ipupdate libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Version-Release number of selected component (if applicable): $ rpm -q --file /lib/i686/libc.so.6 glibc-2.3.1-21 How reproducible: Always Steps to Reproduce: 1. Run program compiled on RedHat 8.0 referring errno (Probably not as simple as that, I have several programs compiled on RedHat 8.0 that behave just fine) Actual Results: Fails to run :
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.