Summary: | sys-libs/glibc-2.12.1 - unrecognized symbol type "gnu_indirect_function" when building with older binutils | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | biohazrd <biohazrd> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | http://sourceware.org/ml/libc-alpha/2010-08/msg00066.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build log of glibc 2.12.1
build log of glibc 2.12.1 |
Description
biohazrd
2010-08-20 02:21:56 UTC
*** Bug 333545 has been marked as a duplicate of this bug. *** *** Bug 333543 has been marked as a duplicate of this bug. *** *** Bug 333563 has been marked as a duplicate of this bug. *** what version of binutils exactly do you have active ? `ld --version` (In reply to comment #4) > what version of binutils exactly do you have active ? `ld --version` > GNU ld (GNU Binutils) 2.19.1 so switch to 2.20.1 (In reply to comment #5) > (In reply to comment #4) > > what version of binutils exactly do you have active ? `ld --version` > > > > GNU ld (GNU Binutils) 2.19.1 > Same error with : GNU ld (GNU Binutils) 2.20.1.20100303 post the full build log as an attachment like you should in every bug report File is over 2000kb.. gonna have to cut it short... one moment. Created attachment 243663 [details]
build log of glibc 2.12.1
Comment on attachment 243663 [details]
build log of glibc 2.12.1
never clip a log. i have no idea what this attachment is ... looks like a lot of garbage. just compress the build.log files itself with something standard like bzip2 and post that.
$ zcat attachment.cgi\?id\=243663 | tar xvf -
build.log
$ file build.log
build.log: gzip compressed data, from Unix, last modified: Fri Aug 20 02:07:28 2010
$ zcat build.log > _build.log
$ file _build.log
_build.log: data
Created attachment 243665 [details]
build log of glibc 2.12.1
dont know why you still used tar for a single file, but whatever ... that log shows that you're still using 2.19: checking version of /usr/libexec/gcc/x86_64-pc-linux-gnu/as... 2.19.1, ok at any rate, ive sent a patch upstream for the issue. i'll wait to see what they have to say about it. (In reply to comment #13 Thanks. Sorry I was pretty tired last night when I reported this bug. lrwxrwxrwx 1 root root 55 Sep 18 2009 addr2line -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.19.1/addr2line lrwxrwxrwx 1 root root 48 Sep 18 2009 ar -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.19.1/ar lrwxrwxrwx 1 root root 48 Sep 18 2009 as -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.19.1/as .........more Something in the configure script for glibc was stopping when it found the old symlinks for binutils 2.19.1 in /usr/libexec/gcc/x86_64-pc-linux-gnu/ Moving all symlinked files out of the directory fixed the problem and glibc configured to use binutils 2.20.1 glibc 2.12.1 built fine. Oh no, you don't get out of it that easily. I consider this bug to be "UNRESOLVED" because my system (even after applying the glibc-2.12.1-r1 patch) *STILL* does not work as it did before upgrading to 2.12.1. The key point currently being that non-super-users can *still* not login. (See Bug #333485). This is *after* I have compiled at least, coreutils, openssh and net-tools with "-static" to allow them to function properly. And that is on top of the fact that ONE CANNOT BUILD 2.12.1-r1 if one has previously (stupidly) installed 2.12.1 with a coreutils in "static" mode. Because /usr/bin/install which is installed by coreutils is "static" and will cause a failure of 2.12.1-r1. This is on top of the fact that one cannot downgrade to glibc-2.11.2 due to "imposed" restrictions, i.e.: * USE: debug elibc_glibc kernel_linux userland_GNU x86 * Sanity check to keep you from breaking your system: * Downgrading glibc is not supported and a sure way to destruction * ERROR: sys-libs/glibc-2.11.2 failed: * aborting to save your system Oh, yes, "Downgrading glibc" is a sure way to break my system. Shall we talk about "upgrading"??? In my experience non-static versions of glibc will work across 3-5 years of Linux software releases. What doesn't appear to work is "static" releases -- when indeed *those* are the releases which should *ALWAYS* work because the 8086 architecture (and ELF formats) have not changed significantly in 15+ years! I suspect I can take a version of sol.exe from 1995 from Windows 95 and still run it (perhaps even from DOS). Why cannot the same be said for Linux? For this bug to be considered "resolved", the glibc-2.12.1-r1 upgrade should work (which it appears to) and *ALL* packages which may depend on this upgrade [which may have "static" build options] (which by my count may amount to 50 or more ebuilds) should be modified so that they are rebuilt if this ebuild is installed. And as a global option, for those of us who are really annoyed that "static" does not really mean "static" it would be nice to know who should be complained to or bug-fixes filed with "upstream" to eliminate this problem from further releases of Linux. I do not believe the problematic functions in glibc involving static buffers are that hard to program around (caller passes address and size of buffer in which information is to be stored) -- and calls to such functions should have been eliminated from all core Linux/GNU/Gnome utilities *LONG* ago. i think you've confused yourself. this bug has nothing to do with static. ive added the patch i sent upstream to 2.12.1-r1 so that older binutils (lacking gnu indirect support) will work properly |