After successfully compiling glibc-2.3.3.20040420 or glibc-2.3.4-20040605-r1 with gcc-3.4.0-r6 and nptl in my USE flags, running ldconfig produces a segmentation fault. Works fine without nptl USE flag. Reproducible: Always Steps to Reproduce: 1. compile glibc >= 2.3.3.20040420 with gcc-3.4.0-r6 and USE="nptl" 2. run ldconfig Actual Results: Segmentation Fault. Expected Results: not segfaulted :-) Portage 2.0.50-r8 (default-x86-2004.0, gcc-3.4.0, glibc-2.3.4.20040605-r1, 2.6.7-gentoo-r6) ================================================================= System uname: 2.6.7-gentoo-r6 i686 Intel(R) Pentium(R) M processor 1600MHz Gentoo Base System version 1.5.1 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium-m -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium-m -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://mirror.datapipe.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/home" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi alsa apm arts avi berkdb caps crypt cups encode esd foomaticdb gcj gdbm gif gnome gpm gtk gtk2 imlib jack jack-tmpfs java jpeg libg++ libwww mad mikmod mmx mozilla moznocompose moznoirc moznomail mpeg ncurses nls oggvorbis opengl pam pdflib perl png python qt quicktime readline sdl slang spell sse sse2 ssl svga tcpd truetype x86 xml2 xmms xv zlib"
have you tested this with gcc 3.3.3?
Yes, no segfault with gcc-3.3.3-r6 and USE="nptl", using the following: CFLAGS="-O2 -mcpu=pentium4 -pipe -fomit-frame-pointer" Since I have heard of others using gcc-3.4 without issue, perhaps it has something to do with the pentium-m flag?
Some further testing does seem to indicate that the -march=pentium-m flag may be the culprit. I compiled glibc-2.3.4.20040605 with USE="nptl" and gcc-3.4.0-r6 successfully (no ldconfig segfault) using: CFLAGS="-O2 -mtune=pentium4 -pipe -fomit-frame-pointer" I have searched through some of the forum threads on gcc 3.4, and it has been suggested that the pentium-m flag is not yet functional. Is that correct?
Trying out gcc-3.4.1 produces the same effect - ldconfig segfaults with -march=pentium-m (which is functioning).
for now i've made the ebuilds change pentium-m to pentium4 if using gcc 3.4.x... though i strongly suggest mentioning this problem to upstream where it can be fixed. please file a bug at http://gcc.gnu.org/bugzilla/ ...while you're at it, make sure you file -another- bug with us if this ever gets fixed in gcc so we can remove this line. :)
booo, hiss! pentium-m is a pentium3 core with a smaller die and added sse2 instructions. it is *not* a pentium4 by any strech of the imagination. Could this be -march=pentium3 ?
segfault also happens with gcc-3.4.1-r1, glibc-3.3.4-20040619, USE="nptl" CFLAGS="-Os -march=pentium4 -fomit-frame-pointer -pipe" CXXFLAGS="${CFLAGS}" Additionally, prelink segfaults.
I've also switched from the pentium-m to pentium4 CFLAG only receive the same segfault in ldconfig. I don't think it's a CFLAG problem. AS for whether or not pentium4 is correct or incorrect. That debate has been going on for a while, but I've been using pentium4 for the past year+ and I have never run intoo problems.
....right-o
pentium-m is a pumped up pentium3, and should take -march=pentium3 (you might try ('-march=pentium3 -mcpu=pentium4 -msse2', but I am not 100% sure nothing will break), as you can see from the mails below: --- From: Mikael Pettersson <mikpe@csd.uu.se> To: linux-kernel@vger.kernel.org, lkml@kcore.org Subject: Re: Pentium-M? Date: Sat, 23 Aug 2003 14:36:22 +0200 (MEST) On Sat, 23 Aug 2003 13:50:02 +0200, Jan De Luyck <lkml@kcore.org> wrote: >Just a short question. For the Pentium-M as used in the centrino platform, >what do I select in the 2.6.0-test4 kernel configuration as the CPU? > >I figure it's not a PIV, but is it a P3? Or is it something special? The P-M core is PIII, to which SSE2, some P4-like model-specific registers, and (it seems) a P4 bus were added. For now, treat it simply as a PIII. /Mikael --- From: Mikael Pettersson <mikpe@csd.uu.se> To: smiler@lanil.mine.nu, zwane@linuxpower.ca Cc: barryn@pobox.com, linux-kernel@vger.kernel.org, lkml@kcore.org Subject: Re: Pentium-M? Date: Sun, 24 Aug 2003 22:59:38 +0200 (MEST) On Sun, 24 Aug 2003 22:20:13 +0200, Christian Axelsson <smiler@lanil.mine.nu> wrote: >Hmm.. I have compiled my whole system with -march=pentium4 and yet not >had a single breakage. Are you sure that this is p3? Oh yes. The core is most definitely P6+tweaks and not NetBurst. This can be deduced from facts like: - CPUID family is 6 not 15 - performance counter architecture is like PIII with some minor tweaks but definitely nothing like P4 - treated separately from NetBurst in code optimization manual The reason compiling with -march=pentium4 doesn't break is that the differences ISA-wise are almost nil. /Mikael
I recall a thread somewhere that compared all of the non-pentium-m options (i.e. pentium3, pentium4, etc.) and determined that -mtune=pentium4 to be the most efficient on a pentium-m. But that is a bit besides the point. In response to comment #8, my test case doesn't segfault when I use -mtune=pentium4 instead of -march=pentium-m, I haven't tried -march=pentium4.
ok, re-opening. i dont have a pentium-m to test this on, so there's really not much i can do unless one of you tell me what works with 100% certainty. also, please make sure to poke at upstream to make sure they know there's a problem... cuz I sure dont know enough about what's going on to fix it. is anyone here experiencing trouble with -march=pentium3?
Yes, I am getting this error using -march=pentium3, and very conservative CFLAGS. Here's my 'emerge info'. shrimp root # emerge info Portage 2.0.50-r9 (default-x86-2004.0, gcc-3.4.1, glibc-2.3.4.20040619-r0, 2.6.7) ================================================================= System uname: 2.6.7 i686 Intel(R) Pentium(R) M processor 1300MHz Gentoo Base System version 1.5.1 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium3 -w -s -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -w -s -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache digest sandbox sfperms userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.ccccom.com ftp://gentoo.ccccom.com http://mirror.datapipe.net/gentoo http://mirror.tucdemonic.org/gentoo/" MAKEOPTS="" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X acpi alsa berkdb crypt cups dga dvd dvdr flac gnome gnutls gpm gstreamer gtk2 gtkhtml jpeg kerberos ldap mad ncurses nptl oggvorbis opengl pam perl pic png python readline samba spell sse ssl tcpd tiff truetype x86 xinerama xv zlib"
Just in case anyone would like to add their experiences to it, I have also opened a bug with gcc on this issue: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16466 And just to reiterate, -march=pentium-m causes a segfault for me, but -mtune=pentium4 works as expected.
I just recompiled glibc a couple of times, and came up with these CFLAG setups/results. WORKING: CFLAGS="-O2 -march=pentium3 -mtune=pentium4 -pipe -w -s -fomit-frame-pointer" CFLAGS="-O2 -mtune=pentium4 -pipe -w -s -fomit-frame-pointer" NOT WORKING CFLAGS="-O2 -march=pentium3 -pipe -w -s -fomit-frame-pointer" CFLAGS="-O2 -march=pentium-m -pipe -w -s -fomit-frame-pointer"
ok, the ebuild should now change -march=pentium-m to -mtune=pentium3 if using gcc 3.4. this isnt a real fix, and more of an ugly workaround... but there's not much i can do without a fix upstream.
I just went ahead and commented out the workaround so I could try building a true -march=pentium-m nptlonly glibc 2.3.5-r1 using gcc 3.4.4-r1. Result: success! Looks like the bug has vanished somewhere in between the glibc and gcc updates... time to remove the workaround?
