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.62) (envelope-from ) id 1GnKCA-0005Zp-PX for garchives@archives.gentoo.org; Thu, 23 Nov 2006 19:25:15 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kANJLsuj018030; Thu, 23 Nov 2006 19:21:54 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id kANJLrjJ001471 for ; Thu, 23 Nov 2006 19:21:53 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GnK8h-00089Y-5h for gentoo-amd64@lists.gentoo.org; Thu, 23 Nov 2006 20:21:40 +0100 Received: from ip68-230-97-209.ph.ph.cox.net ([68.230.97.209]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Nov 2006 20:21:39 +0100 Received: from 1i5t5.duncan by ip68-230-97-209.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Nov 2006 20:21:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Another package that doesn't like GCC 4 Date: Thu, 23 Nov 2006 19:21:31 +0000 (UTC) Message-ID: References: <200611221628.33584.prh@gotadsl.co.uk> <200611231139.36213.prh@gotadsl.co.uk> <200611231358.40124.janjitse@gmail.com> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-209.ph.ph.cox.net User-Agent: pan 0.120 (Plate of Shrimp) Sender: news X-Archives-Salt: acb5c37c-e2a8-4624-b41d-93cbae0787af X-Archives-Hash: d48f0fefc14fff1815cd1e7f76621352 Jan Jitse Venselaar posted 200611231358.40124.janjitse@gmail.com, excerpted below, on Thu, 23 Nov 2006 13:58:36 +0100: > On Thursday 23 November 2006 12:39, Peter Humphrey wrote: >> On Wednesday 22 November 2006 16:28, I wrote: >> > So now I suppose I have a lot of CFLAGS to juggle to find out which one >> > hurts gnupg so that I can report it. >> >> It didn't take too long after all. I found that omitting, or >> removing, -fmerge-all-constants from CFLAGS enabled gnupg to compile >> with -ldap. I don't think gnupg uses C++ so I didn't play with CXXFLAGS. >> >> # grep FLAGS /etc/make.conf >> CFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks \ >> -freorder-blocks-and-partition -combine -funit-at-a-time \ >> -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants" >> CXXFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks \ >> -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload >> -fmerge-all-constants" >> >> #cat /etc/portage/env/app-crypt/gnupg >> CFLAGS=${CFLAGS//-fmerge-all-constants} >> >> I haven't decided whether it's worth reporting a bug; perhaps it's enough >> that people here know what's needed. > Sorry, but using that flag is just asking for trouble. > From the GCC man-page: > > -fmerge-all-constants > "Languages like C or C++ require each non-automatic variable to have distinct > location, so using this option will result in non-conforming behavior. " I'd not report it (tho I use it and haven't seen it cause any problems at all -- I have gnupg merged but not with LDAP so I didn't see that one), precisely because of the gcc-entry for it. It's not likely to be looked upon with favor. If you recall during the original discussion, I specifically mentioned that particular caveat with that flag, that it broke the C standard, so /could/ be problematic, altho I personally hadn't seen any problems with it after using it for quite some time and including an emerge --emptytree world. Thus, while it doesn't cause many problems, it could cause some, and this appears to be one location where it did. However, given the nature of the flag, it's nothing I'd bother the developers with, as it's purely at a user's own risk that they choose to use flags with such warnings, and I'd not expect it to be fixed. OTOH, check out the following bug for a counter-example, where the problem was triggered by simply following portage's own instructions, and the problem took months to resolve even tho it was a simple fix, because people were more interested in pointing the finger of blame than in simply fixing the problem. In fact, I'm sure they spent more time arguing about it (it eventually hit the dev list, and no, it wasn't me that posted it there) than they did fixing it, once they actually decided to do it. In the end, tho, it was fixed before modular-X went stable, proof the system /can/ work, even if it took awhile. http://bugs.gentoo.org/show_bug.cgi?id=116698 -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list