The glibc-2.3.3_pre20040207 ebuild needs an additional patch in order to build on my alpha, which runs Gentoo 2004.0 and Linux 2.6.5. Suprisingly, I couldn't find any bug reports about this problem. Apart from nptl in my USE flags, I don't know what would cause this ebuild to fail. I upgraded gcc-3.3.2-r5 to gcc-3.3.3-r3, but it didn't help. Maybe one of the Gentoo alpha glibc maintainers can try reproducing the failure, so that the fix can go into portage? The fix is this patch, which went into the glibc mainline in March 2004, http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/alpha/sysdep.h.diff?r1=1.16&r2=1.17&cvsroot=gl$ Reproducible: Always Steps to Reproduce: 1. emerge =sys-libs/glibc-2.3.3_pre20040207 Actual Results: Below is the build failure. [snip] gcc -nostdlib -nostartfiles -o /var/tmp/portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/ buildhere/iconv/iconv_prog -Wl,-dynamic-linker=/lib/ld-linux.so.2 -Wl,-z,combreloc /var/tmp/ portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/buildhere/csu/crt1.o /var/tmp/portage/glibc -2.3.3_pre20040207/work/glibc-2.3.2/buildhere/csu/crti.o `gcc --print-file-name=crtbegin.o` /var/ tmp/portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/buildhere/iconv/iconv_prog.o /var/tmp/ portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/buildhere/iconv/iconv_charmap.o /var/tmp/ portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/buildhere/iconv/charmap.o /var/tmp/portage/ glibc-2.3.3_pre20040207/work/glibc-2.3.2/buildhere/iconv/charmap-dir.o /var/tmp/portage/glibc -2.3.3_pre20040207/work/glibc-2.3.2/buildhere/iconv/linereader.o /var/tmp/portage/glibc -2.3.3_pre20040207/work/glibc-2.3.2/buildhere/iconv/dummy-repertoire.o /var/tmp/portage/glibc -2.3.3_pre20040207/work/glibc-2.3.2/buildhere/iconv/simple-hash.o /var/tmp/portage/glibc -2.3.3_pre20040207/work/glibc-2.3.2/buildhere/iconv/xstrdup.o /var/tmp/portage/glibc -2.3.3_pre20040207/work/glibc-2.3.2/buildhere/iconv/xmalloc.o -Wl,-rpath-link=/var/tmp/ portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/buildhere:/var/tmp/portage/glibc -2.3.3_pre20040207/work/glibc-2.3.2/buildhere/math:/var/tmp/portage/glibc-2.3.3_pre20040207/ work/glibc-2.3.2/buildhere/elf:/var/tmp/portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/ buildhere/dlfcn:/var/tmp/portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/buildhere/nss:/var/ tmp/portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/buildhere/nis:/var/tmp/portage/glibc -2.3.3_pre20040207/work/glibc-2.3.2/buildhere/rt:/var/tmp/portage/glibc-2.3.3_pre20040207/ work/glibc-2.3.2/buildhere/resolv:/var/tmp/portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/ buildhere/crypt:/var/tmp/portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/buildhere/nptl /var/ tmp/portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/buildhere/libc.so.6.1 /var/tmp/portage/ glibc-2.3.3_pre20040207/work/glibc-2.3.2/buildhere/libc_nonshared.a -lgcc -lgcc_eh `gcc --print- file-name=crtend.o` /var/tmp/portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/buildhere/csu/ crtn.o /var/tmp/portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/buildhere/libc.so.6.1: undefined reference to `__GI___pwrite64' collect2: ld returned 1 exit status make[2]: *** [/var/tmp/portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/buildhere/iconv/conv_pro g] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2/iconv' make[1]: *** [iconv/others] Error 2 make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.3_pre20040207/work/glibc-2.3.2' make: *** [all] Error 2 !!! ERROR: sys-libs/glibc-2.3.3_pre20040207 failed. !!! Function src_compile, Line 528, Exitcode 2 !!! (no error message)
That URL got mangled, here it is again. http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/alpha/sysdep.h.diff?r1=1.16&r2=1.17&cvsroot=glibc
if you'd like to see this in portage, done close
....does this bug still exist?
Yes, it is still open. Martin mean to say "if you'd like to see this in portage, don't close". That was because I (wrongly) changed the status and he had to change it back. So I guess this bug is waiting for someone to reproduce it.
Would the alpha guys mind testing the newer ebuilds (preferably 2.3.4.20040605-r1 is at all possible), and let us know of any oddities that may arise? (And maybe lets us close this bug).
Created attachment 33365 [details] gzipped emerge log from glibc-2.3.4.20040605-r1 Compilation fails in the same way with or without the patch. I'll try adding the patch to older versions of glibc to see if that makes any difference.
I checked your build log. The failure may be caused by old kernel headers? __NR_stat64 is not declared in vanilla 2.6.1 headers, but it is in 2.6.5.
I just found that the glibc-2.3.4.20040605-r1 build problem under older kernels (which Bryan referred to), came up on a glibc mailing list in May. The patch was rejected by Mr Drepper and hence the bug is still in the glibc mainline at present. http://sources.redhat.com/ml/libc-alpha/2004-05/threads.html#00101 That bug is also in Gentoo's bugzilla (apparently it appears in pre20040420 as well), http://bugs.gentoo.org/show_bug.cgi?id=50301
This bug still alive on glibc-2.3.4.2004XXXX. When i compile glibc without bug?
patch works with glibc-2.3.4-20041102
Created attachment 46848 [details, diff] cleaned-up version of the patch from glibc mailinglist since the author appearently didn't post a clean version of his patch i gave it a try, and this is the outcome
Created attachment 47258 [details, diff] cleaned-up version of the patch from glibc mailinglist, take #2 small fix, stat64 syscalls are available on linux >=2.6.4 (and not 2.6.5)
ive added the write patch to glibc-2.3.2-r12 now that i had a chance to test it it isnt needed by glibc-2.3.4.20040808-r1/glibc-2.3.4.20041102
should be fixed now then
