[gentoo-amd64] Re: Another package that doesn't like GCC 4

[Duncan <1i5t5.duncan@cox.net>]

Jan Jitse Venselaar <janjitse@gmail.com> 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