I've been trying for several days to emerge libstdc++-v3-3.3.4, and it fails every time at the following point: checking whether the C compiler ( /var/tmp/portage/libstdc++-v3-3.3.4/work/build/gcc/xgcc -B/var/tmp/portage/libstdc++-v3-3.3.4/work/build/gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -O2 -O2 -march=pentium3m -pipe ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. make: *** [configure-target-libiberty] Error 1 !!! ERROR: sys-libs/libstdc++-v3-3.3.4 failed. !!! Function src_compile, Line 178, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. Reproducible: Always Steps to Reproduce: 1. type 'emerge -uv libstdc++-v3-3.3.4' 2. wait... 3. cuss... Actual Results: emerge failure for libstdc++-v3-3.3.4 Expected Results: successful emerge of libstdc++-v3-3.3.4 Gentoo Base System version 1.5.3 Portage 2.0.51_rc1 (gcc34-x86-2004.2, gcc-3.4.2, glibc-2.3.4.20040808-r0, 2.6.8-gentoo-r4 i686) ================================================================= System uname: 2.6.8-gentoo-r4 i686 Pentium III (Coppermine) ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.8.1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="" ANT_HOME="/usr/share/ant-core" ARCH="x86" AUTOCLEAN="yes" BASH_ENV="/etc/spork/is/not/valid/profile.env" CC="gcc" CFLAGS="-O2 -march=pentium3m -mfpmath=sse -mmmx -msse -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CLASSPATH="." CLEAN_DELAY="5" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CVS_RSH="ssh" CXX="g++" CXXFLAGS="-O2 -march=pentium3m -mfpmath=sse -mmmx -msse -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" EDITOR="/bin/nano" FEATURES="autoaddcvs ccache sandbox" FETCHCOMMAND="/usr/bin/wget -t 5 --passive-ftp -P ${DISTDIR} ${URI}" GDK_USE_XFT="1" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http://mirrors.tds.net/gentoo http://gentoo.mirrors.pair.com/" GRP_STAGE23_USE="ipv6 pam tcpd readline nls ssl gpm perl python berkdb acl ncurses" GUILE_LOAD_PATH="/usr/share/guile/1.6" G_BROKEN_FILENAMES="1" HOME="/root" HOSTNAME="wan-mmayne-19" INFOPATH="/usr/share/info:/usr/share/gcc-data/i686-pc-linux-gnu/3.4/info" JAVAC="/opt/blackdown-jdk-1.4.2_rc1/bin/javac" JAVA_HOME="/opt/blackdown-jdk-1.4.2_rc1" JDK_HOME="/opt/blackdown-jdk-1.4.2_rc1" LESS="-R" LESSOPEN="|lesspipe.sh %s" LOGNAME="root" MAIL="/var/mail/root" MAKEOPTS="-j1" MANPATH="/usr/share/man:/usr/local/share/man:/usr/share/gcc-data/i686-pc-linux-gnu/3.4/man:/usr/X11R6/man:/usr/share/man:/usr/local/share/man:/usr/share/gcc-data/i686-pc-linux-gnu/3.4/man:/usr/X11R6/man::/opt/blackdown-jdk-1.4.2_rc1/man:/usr/qt/3/doc/man:/opt/blackdown-jdk-1.4.2_rc1/man:/usr/qt/3/doc/man" MOZILLA_FIVE_HOME="/usr/lib/mozilla" NOCOLOR="false" OLDPWD="/usr/portage/profiles/gcc34-x86-2004.2" PAGER="/usr/bin/less" PATH="/usr/lib/ccache/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.4:/usr/X11R6/bin:/opt/blackdown-jdk-1.4.2_rc1/bin:/opt/blackdown-jdk-1.4.2_rc1/jre/bin:/usr/qt/3/bin" PKGDIR="/usr/portage/packages" PORTAGE_ARCHLIST="alpha amd64 arm hppa ia64 macos mips ppc ppc64 s390 sparc x86 x86-obsd x86-fbsd ppc-macos" PORTAGE_BINHOST_CHUNKSIZE="3000" PORTAGE_CALLER="emerge" PORTAGE_GID="250" PORTAGE_MASTER_PID="4042" PORTAGE_NICENESS="3" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" PRELINK_PATH="" PRELINK_PATH_MASK="" PWD="/root" PYTHONDOCS="/usr/share/doc/python-docs-2.3.4/html" QMAKESPEC="linux-g++" QTDIR="/usr/qt/3" RESUMECOMMAND="/usr/bin/wget -c -t 5 --passive-ftp -P ${DISTDIR} ${URI}" RPMDIR="/usr/portage/rpm" RSYNC_RETRIES="3" RSYNC_TIMEOUT="180" SHELL="/bin/bash" SHLVL="1" SYNC="rsync://rsync.gentoo.org/gentoo-portage" SmartEiffel="/usr/lib/SmartEiffel/SmartEiffel.conf" SmartEiffelDirectory="/usr/lib/SmartEiffel" TERM="linux" USE="X aalib acl acpi acpi4linux alsa apm avi berkdb bindist bitmap-fonts bonobo bootsplash cdr crypt cups doc dvd dvdr emacs emacs-w3 encode esd foomaticdb gdbm gif gimp gimpprint gnome gphoto2 gpm graphviz gtk gtk2 guile imlib java jpeg lcms libg++ libwww mad mikmod mmx mng motif mozilla mpeg mysql nas ncurses nls nptl oggvorbis pam pcmcia pda pdflib perl pic pie png pnp ppds python qt quicktime readline ruby sdl slang spell sse ssl svg svga tcltk tcpd tetex tiff truetype trusted wmf x86 xml2 xmms xprint xv zlib" USER="root" USERLAND="GNU" USE_EXPAND="VIDEO_CARDS INPUT_DEVICES LINGUAS" XARGS="xargs -r" XINITRC="/etc/X11/xinit/xinitrc" _="/usr/bin/emerge"
Created attachment 39691 [details] full output of failed emerge
Created attachment 39692 [details] List of all packages currently installed per qpkg -I -v
Ahh... I found a bypass, and likely a really good pointer to the problem. I tried to re-emerge the already installed libstdc++-v3-3.3.3-r1 and it *also* failed the same way. Hmmmm. I went back into /var/db/pkg/sys-libs/libstdc++-v3-3.3.3-r1 and looked at the CFLAGS and CXXFLAGS that it previously compiled successfully with, which were both "-O2 -mcpu=i686 -pipe", and I re-ran the emerge with 'CFLAGS="-O2 -mcpu=i686 -pipe" CXXFLAGS="-O2 -mcpu=i686 -pipe" emerge -uv libstdc++-v3' - lo and behold, success!! There's got to be something in the CFLAGS and CXXFLAGS that this package doesn't like, and also that the ebuild doesn't filter out or convert correctly. Where does this go next? (I'm new at this, this is the first bug I've posted against Gentoo..) -Mike
i dont think pentium3m is a valid arch...
From the GCC 3.4.2 manual: 3.17.1 Intel 386 and AMDx86-4 Options These `-m' options are defined for the i386 and x86-64 family of computers: -mtune=cpu-type Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. The choices for cpu-type are: ... (snip) ... pentium3, pentium3m Intel Pentium3 CPU based on PentiumPro core with MMX and SSE instruction set support. ... (snip) ... -march=cpu-type Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for `-mtune'. Moreover, specifying `-march=cpu-type ' implies `-mtune=cpu-type '.
That problem does not only affect x86. I had the same with PPC. So using CFLAGS="-O3 -mcpu=G4 -mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -funroll-loops -pipe" would not build libstdc++-v3 (I know, the CFLAGS are over-optimized, but that's on the shiny PegasosPPC we got for testing). With the recommended CFLAGS="-O3 -mcpu=powerpc -pipe" for any PPC the package has been built. As I'm still in the installation of Gentoo on that machine, I just tested, if -O3 is the problem and replaced with -O2. But that didn't solved it. So, probably one of the -f-flags or the -mcpu/-mtune could cause the fail.
hm i have normaly -march=k8, resulting in the same bug descripted above. i check my last compileable flags also and there i see -mach=athlox-xp. i test compile with this and it compile fine.
The solution to comment #6 would be to add a check in to change G3, G4 or G5 to a flag that 3.3 actually has or strip them, since they were added to 3.4 like pentium-m was and opteron/athlon64/k8.
Dealing with G3, G4, G5, flags gcc3.4 introduced but gcc3.3 doesnt know Should you encounter further CFLAGS triggering this bug, reopen it and add CFLAGS and CXXFLAGS from beginning of merge to your comment resync in 35 minutes and merge libstdc++-v3 Thank you for reporting this
Created attachment 42886 [details, diff] Patch against libstdc++-v3-3.3.4.ebuild,v 1.5 2004/10/27 03:44:37 OK, this is the SECOND TIME I HAVE REOPENED THIS BUG. As the old saying goes, "If you want something done right, then you have do it yourself". I have created a patch that makes the ebuild work on my system. However, I also feel that someone who is more familiar than I with gcc could fine-tune it much further (see embedded comments). Now, I'll just post the following comment, and leave it at that (I'm really, really tempted to do an absolutely world-class rant, but, A - it wouldn't be polite, and B - it would serve no purpose). The comment: I have over 28 years of experience in the IT field and as this is my first experience with Gentoo support, I can only say that I'm totally and completely underwhelmed. I would feel almost mortally embarrased to have provided this level of (lack of) support to anyone and if I didn't think that I could get better in a hurry, I'd give it up and take up some other profession. If this level of support is common in the Gentoo community, it's a miracle that it runs at all...
Created attachment 42887 [details] Output of successful emerge with above patch.
Reopening (must have mised it the first time).
that patch would be -great- if it didnt break support for the one arch that the ebuild's maintainer actually uses. gentoo is a community-supported and community-developed operating system. you have maybe 4 active toolchain devs handling hundreds of bugs in their free time... mostly as a hobby. cvs is down, so i cant do anything for this right now.. but the universal fix for all archs would be to filter -march, -mtune, and -mcpu until someone gets bored enough to map out the flags supported by gcc 3.3 and allow only those.
i've updated the ebuild with a table of known valid arch settings for i386/x86-64, mips, and rs6000/ppc/ppc64. yes... i actually poked through the gcc source for them, though i probably could have just looked up the docs. please test the new ebuilds to see if they're to your liking.
I was under the impression all left were the ppc arches, and i asked to reopen it if there are others that need handling, why you comment out what does not pertain to your problem/arch and already worked is beyond me, it must be i just lack your 28yrs of IT experience to comprehend such an action, sorry you had to reopen it twice i guess.
Daniel, I assume that you are referring to the following lines ! # gcc 3.3 doesn't support the -mtune= flag, so convert that into its' ! # equivalent -march= flag... ! replace-flags -mtune=? -march=? ! ! # gcc 3.3.x doesn't recognize several -march= flags for x86 that gcc 3.4.x ! # does, so replace them with their closest gcc 3.3 equivalents... ! # ! # NOTE!!! This patch should not be considered complete until someone who ! # is familiar with all of the flag differences between gcc 3.3.x and 3.4.x ! # *and* is also familiar with all of the various processor architechtures ! # updates, modifies and checks it!!! ! # ! replace-flags -march=pentium3m -march=pentium3 replace-flags -march=pentium-m -march=pentium3 + replace-flags -march=prescott -march=pentium4 + replace-flags -march=nocona -march=pentium4 + #replace-flags -march=k8 -march=? FIXME - replace with closest gcc 3.3.x equivalent + #replace-flags -march=opteron -march=? FIXME - replace with closest gcc 3.3.x equivalent + #replace-flags -march=athlon64 -march=? FIXME - replace with closest gcc 3.3.x equivalent + #replace-flags -march=athlon-fx -march=? FIXME - replace with closest gcc 3.3.x equivalent + replace-flags -march=c3-2 -march=c3 Did I say it was a final and perfect patch? No. Are there comments in here that say it still needs work? Yes. Do they say what that work should be? Looks like yes to me. There has always been a difference (in my book) between something 'working' and something 'working correctly, optimally, and efficiently'. I was not attempting to 'break' what was 'fixed', I was attempting to show that there may be a better way to do it (in terms of staying as close as possible to the intent of the users supplied gcc 3.4 compiler flags). That being, instead of simply stripping any offending flag (why not just strip all of them and have done with it, then?), but instead to try and map the users supplied gcc 3.4 flags to their closest gcc 3.3 equivalents. The thing that set me off was that my initial post reporting the problem (a true problem, accurately reported to the best of my ability) was blown off and closed inside of just a few days with a cheap comment and hardly a second look. Then, after I reopened the problem, it sat there for almost a month with no significant activity, and then was closed *again*, without ever addressing and fixing the problem that I opened it for!! I mean, seriously, with this kind of response, why bother to even open a bug at all? If all I wanted was frustration and abuse, I can get more of it and of better quality closer to home. And I'm sorry if my 28 years of experience offends you. I've fixed 100 times more bugs in software over the last 28 years than the years you've been alive (however many they may be). I think that gives me, at minimum, authority to comment on the topic. Do we understand each other now? -Mike
apologies. does the current ebuild work for you?
<snip> OK, this is the SECOND TIME I HAVE REOPENED THIS BUG. As the old saying goes, "If you want something done right, then you have do it yourself". </snip> <snip> I have over 28 years of experience in the IT field </snip> <snip> I've fixed 100 times more bugs in software over the last 28 years than the years you've been alive (however many they may be). </snip> In my short life time i have heard one phrase in nummerous areas of work, "don't fix what aint broken" and that you haven't, had surprised me, which is what i failed to convey in the previous comment. Since the ebuild is now wonderfully fixed by our masterous Travis i am sure you will be glad to see him close this soon again, like i said i have not noticed someone had closed it w/o fixing pentium3m and misinterpreted it needing fixing on ppc only which i did and closed it, and from your comments i concluded you would show us how it's done and it wasnt, so sorry from the bottom of my heart i made a mistake, i hope we can still be friends
Daniel, I *do* know the phrase "If it ain't broke, don't fix it". What you maybe haven't heard is the corollary of this that applies to software: "Software is always broken, you just don't know where yet". ;) I will test the updated ebuild this morning and post results as soon as I have them. -Mike ----------------------------------------------- Murphy's Law: "Anything that can go wrong, will go wrong". O'Toole's Commentary: "Murphy was an optimist". Finagle's Commentary: "O'Toole was an optimist".
Created attachment 43001 [details] output log of emerge of libstdc++-v3-3.3.4 using latest ebuild
I verify and concurr that the latest ebuild does indeed correct the problem for my arch: -mtune=pentium3m was properly replaced with -march=pentium3, and the ebuild completed and installed normally with no apparent problems. How about the other archs? Lars Weiler? Daniel Ehlers? Mark Loeser?
<snip> "Software is always broken, you just don't know where yet". </snip> since you code by that credo im glad you are close to retirement, the above does not imply it is ok to remove or alter working parts if you have no means of verifying your changes, submitting patches that alter parts of an ebuild not pertaining to the issue at hand are harder to use that those which only work on the parts required, the only problem was noone had yet taken care of pentium3m, something i didnt notice, amd64 was quite happy with what they had (even if it wasnt perfect only taking care of march not mcpu/mtune) im trying to say, it helps more to do the 20% right than to do the 80% mediocre, which is what your "i'm just gonna have to show them how it's done"-patch looked like to me
Re: your comment on "Software is always broken, you just don't know where yet": If you don't believe that, then you haven't been around software very long. Also, a general recommendation to all who handle bug reports and fix things (and this is a rule I practice as well as preach, and it is also the rule with all of the vendors who I get support from commercially): never close a bug without first seeking positive confirmation from those affected by it that you have indeed fixed the problem. After all, it's not the quantity of bugs that you fix (unless you're getting paid by commission or are in a race ;) but the quality of the fixes you create that counts. (p.s. Daniel, sorry to dissapoint you, but I am nowhere near close to retirement. Now, let's see if you've just absolutely got to have that last word again, or if you're actually smarter than that...)
daniel, please stop :/ i'm closing this bug now that it's pretty certain to be fixed for good... the ebuild has been updated with a table of 3.3 arch settings and simply wont allow for anything not in that table. there are probably more archs we should be translating to older settings, but that is a task for another day and another bug.
