Bug 148997 - broken glibc-headers and glibc-kernheaders after consistently yum upgrading
broken glibc-headers and glibc-kernheaders after consistently yum upgrading
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-17 15:23 EST by Jason Vas Dias
Modified: 2014-01-21 17:51 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-18 09:50:55 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)
diffs between my headers and porky's (99.14 KB, patch)
2005-02-17 19:28 EST, Jason Vas Dias
no flags Details | Diff

  None (edit)
Description Jason Vas Dias 2005-02-17 15:23:18 EST
Description of problem:

Having yum upgraded to FC4/Rawhide of 2005-02-17, ld now fails
to link objects with references to the 'inet_*' functions that
are defined in glibc (eg. inet_ntop, inet_pton, inet_ntoa...
and many others (list appended)) .  This breaks many builds
and makes my FC4 development system unusable.

Version-Release number of selected component (if applicable):
How reproducible:
100%
Steps to Reproduce:  
Actual results:
Relevant versions:
gcc-3.4.3-19.i386
glibc-2.3.4-10.i686
glibc-common-2.3.4-10.i386
binutils-2.15.94.0.2-1.i386
kernel-2.6.10-1.1143_FC4.i686

For instance, this program generated during the 'configure' of BIND
fails to link:

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
main() {
    char a[16],b[64];
    return( inet_ntop(AF_INET6, (const void*)a, b, sizeof(b))
            == (char*)0
          );
}

Attempting to compile this program produces an error:
$ gcc -o inet_ntop_test inet_ntop_test.c
/tmp/cc6Pfg89.o(.text+0x29): In function `main':
inet_ntop_test.c: undefined reference to `__inet_ntop'
collect2: ld returned 1 exit status

Yet I can see inet_ntop is defined in /lib/tls/libc-2.3.4.so :
$ nm /lib/tls/libc-2.3.4.so |grep inet_pton
000d43f0 t __GI_inet_pton
000d43f0 T inet_pton

And unpacking /usr/lib/libc.a with 'ar x' produces the file
 inet_pton.o
defining this symbol. Specifying inet_pton.o on the command line
also fails:

$ gcc -o inet_ntop_test inet_ntop_test.o libc/dl-tsd.o \
                                         libc/inet_ntop.o
inet_ntop_test.o(.text+0x29): In function `main':
inet_ntop_test.c: undefined reference to `__inet_ntop'
collect2: ld returned 1 exit status
$ gcc -o inet_ntop_test libc/dl-tsd.o libc/inet_ntop.o \
                                      inet_ntop_test.o
inet_ntop_test.o(.text+0x29): In function `main':
inet_ntop_test.c: undefined reference to `__inet_ntop'
collect2: ld returned 1 exit status
$ nm libc/inet_ntop.o
         U __errno_location
00000000 r fmt.0
00000000 T inet_ntop
         U sprintf
         U strcpy

The commands:
  $ gcc -o inet_test_ntop.o -c inet_test_ntop.c
  $ gcc -o inet_test_ntop inet_test_ntop.o
Generate the ld commmand:

/usr/bin/ld --eh-frame-hdr -m elf_i386 -dynamic-linker
/lib/ld-linux.so.2 -o inet_ntop_test
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../crt1.o
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../crti.o
/usr/lib/gcc/i386-redhat-linux/3.4.3/crtbegin.o
-L/usr/lib/gcc/i386-redhat-linux/3.4.3
-L/usr/lib/gcc/i386-redhat-linux/3.4.3
-L/usr/lib/gcc/i386-redhat-linux/3.4.3/../../.. inet_ntop_test.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/i386-redhat-linux/3.4.3/crtend.o
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../crtn.o

which fails with exit status 1 and outputs:

inet_ntop_test.o(.text+0x29): In function `main':
inet_ntop_test.c: undefined reference to `__inet_ntop'
collect2: ld returned 1 exit status

Expected results:

The program should link without error.
Comment 1 Jason Vas Dias 2005-02-17 16:23:37 EST
Recompiling & installing binutils-2.15.94.0.2-1 didn't help.
I'm now recompiling gcc & glibc to try to get a working FC4 
build environment.
Comment 2 Jason Vas Dias 2005-02-17 17:02:40 EST
And of course the gcc build fails (log file available on request).
Comment 3 Jason Vas Dias 2005-02-17 19:26:27 EST
At last I finally found the root cause of this problem . It appears
to be an issue with RPM, or yum, or glibc-headers, or glibc-kernheaders.
 
I noticed that this version of the configure test function compiles
into an executable fine :
---
const char *inet_ntop
(int af, const void *src, char *dst, unsigned cnt);
main() {
   char a[16],b[64];
   return
   (inet_ntop(10, (const void*)a, b, sizeof(b)) == (const char*)0);
}
---
ie. with no headers included .
I found that even the original function compiled fine on the 'porky'
build server in its dist-fc4-build buildroot, so it looks like porky
has working headers while my machine did not.

This is very strange because they both report the SAME versions of
glibc-headers and glibc-kernheaders :

hostname --fqdn; rpm -q glibc-kernheaders glibc-headers --queryformat
'%{NAME} %{VERSION} %{RELEASE} %{ARCH} %{BUILDTIME} %{BUILDHOST}\n'
porky.build.redhat.com
glibc-kernheaders 2.4 9.1.89 i386 1106222014 decompose.build.redhat.com
glibc-headers 2.3.4 10 i386 1108213652 porky.build.redhat.com

$ hostname --fqdn; rpm -q glibc-kernheaders glibc-headers
--queryformat '%{NAME} %{VERSION} %{RELEASE} %{ARCH} %{BUILDTIME}
%{BUILDHOST}\n'
jvdias.boston.redhat.com
glibc-kernheaders 2.4 9.1.89 i386 1106222014 decompose.build.redhat.com
glibc-headers 2.3.4 10 i386 1108213652 porky.build.redhat.com


Yet there are vast differences between the files in each package
on each machine.

Either my machine has been hacked (unlikely, since it never leaves
the office) or yum / RPM has failed to upgrade the packages properly.
(I've been consistently using only 'yum upgrade' since installing a
pre-FC3 rawhide) .

The output of this command showing the differences between the 
files from porky (in include/) and in my /usr/include is attached:

rpm -ql glibc-headers glibc-kernheaders | while read f; do
F=${f#/usr/}; if [ -f $F ] && ! diff -q $f $F >/dev/null; then echo
`perl -e 'print "-"x80,"\n";'`; echo diff -u $F $f':';  diff -u $F $f;
fi;  done > /tmp/broken_headers.patch

I've preserved the original broken /usr/include if anyone is
interested, but now my /usr/include is patched to have the files
as they are on porky, everything works OK again.





Comment 4 Jason Vas Dias 2005-02-17 19:28:48 EST
Created attachment 111188 [details]
diffs between my headers and porky's

differences between my headers and porky's, when both machines have the same
glibc-headers & glibc-kernheaders packages installed.
Comment 5 Jason Vas Dias 2005-02-17 19:32:14 EST
I'm moving this to yum, because that's the only tool I've been using
to update the glibc header packages.
But perhaps the maintainer of these packages could please check that
there are no reasons why new headers would not be installed during 
a yum upgrade of glibc-headers and glibc-kernheaders .

Comment 6 Jason Vas Dias 2005-02-17 19:50:11 EST
I know this is a very weird bug, and probably will never be solved.
But I never used any tool to update the glibc-headers and 
glibc-kernelheaders packages except yum, and it finally left me
with an unusable build environment and vast differences between
the header files on my machine and those in the dist-fc4-build 
buildroot on porky, even though the same  glibc-headers and
glibc-kernelheaders package versions were installed on both machines. 
Comment 7 Jason Vas Dias 2005-02-18 09:50:55 EST
AARGH! It seems that while I was testing building and installing the
BIND 'libbind' package, doing an install of libbind wiped out these
system header files . Very Sorry! Please ignore this bug.

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