Summary: | sys-libs/glibc-2.14.1-r3 with gcc-4.3 - ../sysdeps/x86_64/multiarch/init-arch.c:90: error: ‘bit_AVX’ undeclared (first use in this function) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Paweł Rumian <gorkypl> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED OBSOLETE | ||
Severity: | major | CC: | alexanderyt, flow, gorkypl |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Build log |
Description
Paweł Rumian
2012-04-24 23:01:14 UTC
Ah, the only strange thing is that sys-libs/glibc-2.13-r4 compiled fine on this machine with gcc-4.3 on 26.01.2012 Perhaps you should just upgrade sys-devel/gcc to something recent - 4.3.4 went stable for x86 in October 2009. I am doing it currently :) But there was no need to do it earlier - this is a pretty old PIII 866MHz and I do not expect that newer gcc would bring any performance improvement. Also this vintage gcc is still in *stable* portage tree and glibc already has a minimal gcc version in DEPEND, so it simply seems to be too low. older versions of gcc in the tree are provided for convenience, not because we support them being the main system compiler. you can't read anything beyond that. (In reply to comment #4) > older versions of gcc in the tree are provided for convenience, not because > we support them being the main system compiler. you can't read anything > beyond that. I have memorized what has been written in the (as I see now - obsolete) old version of gcc upgrade guide: "you can safely postpone upgrade as long as your GCC version is supported by Gentoo developers." http://www.gentoo.org/doc/en/gcc-upgrading-upto-4.1.xml In the new version there is also nothing written about the need to upgrade to the newest version. Now I do not remember any policy of something being "supported" or not, so I assume that if something has not been wiped out of Portage tree than it is supported. Back to the point - I have no problems with upgrading, but also I think that glibc *should* have a minimal gcc version defined if it won't compile with an older one. And if only newest gcc is supported as the main system compiler then I think it should be mentioned in the docs. (In reply to comment #5) putting a dep in the ebuild wouldn't really help. the user must still manually run `gcc-config <new version>` to select it since we SLOT on the major.minor. going by your own quote, "supported by Gentoo developers", that currently means the latest stable version. (In reply to comment #6) > putting a dep in the ebuild wouldn't really help. the user must still > manually run `gcc-config <new version>` to select it since we SLOT on the > major.minor. This is indeed a good point and I have not considered the gcc-config issue, but with this argumentation I can't understand why we currently have: DEPEND=">=sys-devel/gcc-3.4.4 arm? ( >=sys-devel/binutils-2.16.90 >=sys-devel/gcc-4.1.0 ) x86? ( >=sys-devel/gcc-4.3 ) amd64? ( >=sys-devel/binutils-2.19 >=sys-devel/gcc-4.3 ) ppc? ( >=sys-devel/gcc-4.1.0 ) ppc64? ( >=sys-devel/gcc-4.1.0 ) DEPEND="${DEPEND} !crosscompile_opts_headers-only? ( ${CATEGORY}/gcc )" (In reply to comment #7) the idea is to catch most people, not be bullet proof this is a bug specific to glibc-2.14 which has been fixed in glibc-2.15 (which is now stable). since we no longer care about glibc-2.14, nothing to do here. |