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.
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.
And of course the gcc build fails (log file available on request).
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.
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.
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 .
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.
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.