From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E1Rmr-00014B-NN for garchives@archives.gentoo.org; Sat, 06 Aug 2005 16:44:42 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j76GgGVV029057; Sat, 6 Aug 2005 16:42:16 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j76GgFYj024667 for ; Sat, 6 Aug 2005 16:42:15 GMT Received: from localhost ([127.0.0.1]) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1E1RlV-0004C4-VW for gentoo-amd64@lists.gentoo.org; Sat, 06 Aug 2005 16:43:18 +0000 Subject: Re: [gentoo-amd64] gcc-4.0.1 compiled glibc-2.3.5.20050722, SUCCESS! Was: broken (32bit) glibc ? From: Jeremy Huddleston To: gentoo-amd64@lists.gentoo.org In-Reply-To: References: <1123237235.11188.36.camel@echelon.zagamma.vpn> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-x+vuiRUeFQwcbuJANIm2" Date: Sat, 06 Aug 2005 09:43:17 -0700 Message-Id: <1123346597.11655.11.camel@cloud.outersquare.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Archives-Salt: a32083a7-093f-40d9-a590-4af17088dafb X-Archives-Hash: de814edc0483bc296c0193ea03db9f5d --=-x+vuiRUeFQwcbuJANIm2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > I haven't looked at the gcc ebuilds to verify, but I'm guessing the > pro-police stack-protector (and therefore the normal default no- flag tha= t > would turn it off if a hardened profile enabling it by default was in use= ) > stuff isn't in the default gcc-3.4.x either, but rather a patch added by > the ebuild. gcc4 hasn't gotten to the point yet where hardened is lookin= g > at it much, so the equivalent patches haven't been added there, yet, so > gcc4 ebuilds don't recognize the stack-protector flags. Yeah. I'm prolly not going to consider unmasking gcc4 for atleast 6 months, and even then it'd be within testing profiles only. I think halcy0n is the only one *really* following gcc4 development closely among those maintaining the gentoo toolchain. I've tried it out every few months, but it's still too slow for your average applications (huge/complex C++ applications get speed boosts), and it still pushes out too much buggy code. This is expected, though, with a .0 release. 4.0.1 is better, but there's still many regressions. > OTOH, I found yet another package that doesn't yet like gcc4, as well.=20 > util-linux emerges fine with gcc4, which is why I hadn't noticed it b4, > but I tried running cfdisk, and it segfaulted every single time I tried t= o > load my hard drive! Interestingly enough, it worked fine as a user (that > is, it protested about device access permissions and quit, as one would > expect trying to run it as a user), and even worked just fine when I > mistakenly pointed it at my DVD burner with a burnt DVD+R loaded (well it > said read-only mode, but I wouldn't have expected it to work on the DVD a= t > all, and it did), but it'd segfault every time I tried to point it at my > hard drive, as root so it could actually read it. I run 100% reiserfs > formatted hard drive partitions, however, and I'm guessing its reiserfs > code isn't gcc4 safe, just yet, tho as I said it emerged fine. Since it > worked with ISO9660 (surprising me), I'm guessing it probably works with > the more common ext2/3 as well. It certainly doesn't like reiserfs, tho, > when compiled with gcc4! As expected, recompiling it with gcc-3.4.4 > worked just fine. (In fact, it was after that remerge that I forgot I ha= d > gcc-3.4.4 selected and did the entire glibc with gcc-3.4.4 instead of the > gcc-4.0.1 I had intended!) reiserfs is buggy when using a good compiler... I don't want to imagine what happens with a beta compiler ;) Also, don't rule out glibc as the culprit for util-linux failing. Recompile it with gcc3.4 with a gcc4 glibc to rule that out and make sure it's code generated by gcc4 IN util-linux that's the problem. --=-x+vuiRUeFQwcbuJANIm2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBC9OilOpjtAl+gMRURAoTuAKC+0NXEpF/nFWUHSfaoX3DKbLyVxACeKQF/ TfoLnU/IZbVF/UXN0JLwEsA= =NLNZ -----END PGP SIGNATURE----- --=-x+vuiRUeFQwcbuJANIm2-- -- gentoo-amd64@gentoo.org mailing list