Bug 81005 - Binaries referring errno compiled on RedHat 8.0 does no longer work
Binaries referring errno compiled on RedHat 8.0 does no longer work
Status: CLOSED NOTABUG
Product: Red Hat Public Beta
Classification: Retired
Component: glibc (Show other bugs)
phoebe
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-03 06:45 EST by Need Real Name
Modified: 2016-11-24 09:51 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-03 06:49:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2003-01-03 06:45:05 EST
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
:
Comment 1 Jakub Jelinek 2003-01-03 06:49:41 EST
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.
Comment 2 Need Real Name 2003-01-03 08:38:03 EST
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.
Comment 3 Jakub Jelinek 2003-01-03 09:33:25 EST
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@GLIBC_2.0 etc).
A big problem here is also that most of the broken binaries will have COPY
relocs against errno@GLIBC_2.0, 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.

Note You need to log in before you can comment on or make changes to this bug.