Summary: | glibc-2.3.5 fails build with "unrecognized option `-fno-stack-protector'" | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dizzy <dizzy> |
Component: | New packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | dmr, fmccor, jan, lichte, martin.klaffenboeck, more.on, ornati, peterk2, smidge_nihilist, spamlover |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Fix toolchain eclass to add stub patches when gcc emerged with USE=vanilla |
Description
Dizzy
2005-08-05 12:17:52 UTC
re-emerge your gcc *** Bug 102678 has been marked as a duplicate of this bug. *** Created attachment 66701 [details, diff]
Fix toolchain eclass to add stub patches when gcc emerged with USE=vanilla
Steps I took when I got the following error: 1) Used a stage3 tarball 2) Added "vanilla" to USE flags and emerged gcc-3.4.4 3) Bootstrapped with gcc-3.4.4 4) Attempted to emerge -e world The compile failed on glibc because of '-fno-stack-protector' being an unrecognized option. I've attached a patch against the toolchain.eclass which applies the stub patches (for ssp and htb) if USE=vanilla is specified. I believe this is the proper thing to do, otherwise I don't see how you could built your system successfully with a vanilla compiler, unless a "nossp" flag was added to glibc. My emerge -e world completely successfully after re-emerging gcc with the changes to toolchain.eclass. Full error: i686-pc-linux-gnu-gcc ../sysdeps/unix/sysv/linux/ssp.c -c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -march=prescott -pipe -mpreferred-stack-bounda ry=4 -fno-stack-protector -I../include -I. -I/var/tmp/portage/glibc-2.3.5-r1/work/build-default-i686-pc-linux-gnu-nptl/csu -I.. -I../libio -I../nptl -I/var/tmp/portage /glibc-2.3.5-r1/work/build-default-i686-pc-linux-gnu-nptl -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../np tl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../nptl/sysdeps/unix/sysv -I../nptl/sysdeps/unix -I../nptl/sysdeps/i386/i686 -I../nptl/sysdeps /i386 -I../libidn/sysdeps/unix -I../sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdep s/unix/inet -I../sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i6 86 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/d bl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include -isys tem /usr/include -D_LIBC_REENTRANT -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DHAVE_INITFINI -o /var/tmp/portage/glibc-2.3.5-r1/work/build-default-i686-p c-linux-gnu-nptl/csu/ssp.o -MD -MP -MF /var/tmp/portage/glibc-2.3.5-r1/work/build-default-i686-pc-linux-gnu-nptl/csu/ssp.o.dt -MT /var/tmp/portage/glibc-2.3.5-r1/work/bui ld-default-i686-pc-linux-gnu-nptl/csu/ssp.o cc1: error: unrecognized command line option "-fno-stack-protector" make[2]: *** [/var/tmp/portage/glibc-2.3.5-r1/work/build-default-i686-pc-linux-gnu-nptl/csu/ssp.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.5-r1/work/glibc-2.3.5/csu' make[1]: *** [csu/subdir_lib] Error 2 make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.5-r1/work/glibc-2.3.5' make: *** [all] Error 2 emerge --info: Gentoo Base System version 1.12.0_pre6 Portage 2.0.51.22-r2 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r1, 2.6.11.12 i686) ================================================================= System uname: 2.6.11.12 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=prescott -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=prescott -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 apm avi bitmap-fonts crypt cups eds emboss encode foomaticdb gif gstreamer gtk2 imlib jpeg libg++ libwww mad mikmod motif mp3 mpeg ncurses nptl nptlonly ogg oggvorbis opengl pdflib perl png python quicktime readline sdl truetype truetype-fonts type1-fonts unicode vanilla vorbis xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY Comment on attachment 66701 [details, diff]
Fix toolchain eclass to add stub patches when gcc emerged with USE=vanilla
USE=vanilla support in toolchain.eclass is for debugging, not general use
(In reply to comment #5) > (From update of attachment 66701 [details, diff] [edit]) > USE=vanilla support in toolchain.eclass is for debugging, not general use > Great, thats exactly why I built this chroot, for debugging and development work. Isn't it conceivable that debugging would require building important libraries such as glibc with a clean version of gcc? Particularly if one suspected the problem was upstream and not with a gentoo patch? (or just to verify that is the case). I'm having problems with a program I'm working on and -fstack-protector. I don't know yet whether SSP is to blame or the library I'm using. Anyway, if USE=vanilla is only for debugging use, please alter the description in use.desc accordingly, I suggest changing it from: vanilla - Do not add extra patches which change default behaviour to: vanilla - Do not add extra patches which change default behavior. For debugging work only. WARNING breaks compiles of certain packages such as glibc. I think that it's reasonable to assume that a USE flag which doesn't have an explicit warning stating otherwise is "meant for general use." But, why bother? Why make debugging work harder than it is by building a gcc that is going to purposely fail at the compilation of certain packages? maybe, but i think i'd like to take it to a lower level and be able to tell the gcc-config wrapper to eat the ssp option *** Bug 106562 has been marked as a duplicate of this bug. *** I want to leave a short gripe about the "vanilla" USE flag naming/grouping. I had this use flag set (for mutt) without having any idea that it would affect gcc. I certainly don't think that both these packages should use the name vanilla for a USE flag (where in one case it leaves a vital system tool virtually useless for general use, and the other merely keeps out - as the name implies - unwanted patches so that the package keeps its default behavior). re adding 'vanilla' to USE - I suggest you do this as a per-package USE flags rather than setting it globally in make.conf. For flags like 'vanilla', which remove stuff the rest of Gentoo expects to see and thus is likely to create breakage, this is very useful. Look up package.use in 'man portage' - it's particularly useful for local use flags, but there's no reason not to use it for global flags as well. echo "mail-client/mutt vanilla" >> /etc/portage/package.use I know you can do it that way (and I did to solve my problem), but I just wanted to make the suggestion (that probably won't get adopted, but I still want to make it :) ) to split the current vanilla USE flag in two (one with a different name, of course) - one for packages like mutt, and another (maybe a local flag) for something like gcc (that ordinary users should not use without a good reason). *** Bug 106783 has been marked as a duplicate of this bug. *** why doesn't the vanilla flag leave glibc as normal? i had to use vanilla from the start to solve a problem with apache2 and php, as far as i remember. the 2.3.5-r0 built also with vanilla flag. *** Bug 107369 has been marked as a duplicate of this bug. *** *** Bug 107859 has been marked as a duplicate of this bug. *** *** Bug 108280 has been marked as a duplicate of this bug. *** *** Bug 108362 has been marked as a duplicate of this bug. *** *** Bug 108280 has been marked as a duplicate of this bug. *** *** Bug 108665 has been marked as a duplicate of this bug. *** *** Bug 110879 has been marked as a duplicate of this bug. *** *** Bug 111329 has been marked as a duplicate of this bug. *** *** Bug 114443 has been marked as a duplicate of this bug. *** Having read over this bug and having noticed the long chain of duplicates (including one that I submitted on behalf of someone), I'd like to make a suggestion. It would be a good thing if the ebuild of gcc would put out a stream of warnings when it sees USE=vanilla: Something like WARNING: The compiler you are building will not be able to build your system because of USE=vanilla a few times in a row first thing might make things clearer. (Assuming it doesn't, and a glance at it suggests it doesn't.) After all, it is not intuitively obvious that 'USE=vanilla emerge gcc' will result in a compiler that cannot build perl. *** Bug 115431 has been marked as a duplicate of this bug. *** *** Bug 115639 has been marked as a duplicate of this bug. *** But wouldn't be easier to split the vanilla flag as proposed above? IMHO this is a semantics problem: checking the vanilla use flag I (the user) expected to compile a system with no added patches at all and not a broken one.. Now, AFAIK gcc should be able to compile without extra stuff, so why don't fix the vanilla flag in the proper way and deploy another flag for debugging purposes only? |