| 1 |
Jan Jitse Venselaar <janjitse@×××××.com> posted |
| 2 |
200611231358.40124.janjitse@×××××.com, excerpted below, on Thu, 23 Nov |
| 3 |
2006 13:58:36 +0100: |
| 4 |
|
| 5 |
> On Thursday 23 November 2006 12:39, Peter Humphrey wrote: |
| 6 |
>> On Wednesday 22 November 2006 16:28, I wrote: |
| 7 |
>> > So now I suppose I have a lot of CFLAGS to juggle to find out which one |
| 8 |
>> > hurts gnupg so that I can report it. |
| 9 |
>> |
| 10 |
>> It didn't take too long after all. I found that omitting, or |
| 11 |
>> removing, -fmerge-all-constants from CFLAGS enabled gnupg to compile |
| 12 |
>> with -ldap. I don't think gnupg uses C++ so I didn't play with CXXFLAGS. |
| 13 |
>> |
| 14 |
>> # grep FLAGS /etc/make.conf |
| 15 |
>> CFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks \ |
| 16 |
>> -freorder-blocks-and-partition -combine -funit-at-a-time \ |
| 17 |
>> -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants" |
| 18 |
>> CXXFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks \ |
| 19 |
>> -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload |
| 20 |
>> -fmerge-all-constants" |
| 21 |
>> |
| 22 |
>> #cat /etc/portage/env/app-crypt/gnupg |
| 23 |
>> CFLAGS=${CFLAGS//-fmerge-all-constants} |
| 24 |
>> |
| 25 |
>> I haven't decided whether it's worth reporting a bug; perhaps it's enough |
| 26 |
>> that people here know what's needed. |
| 27 |
|
| 28 |
> Sorry, but using that flag is just asking for trouble. |
| 29 |
> From the GCC man-page: |
| 30 |
> |
| 31 |
> -fmerge-all-constants |
| 32 |
> "Languages like C or C++ require each non-automatic variable to have distinct |
| 33 |
> location, so using this option will result in non-conforming behavior. " |
| 34 |
|
| 35 |
I'd not report it (tho I use it and haven't seen it cause any problems at |
| 36 |
all -- I have gnupg merged but not with LDAP so I didn't see that one), |
| 37 |
precisely because of the gcc-entry for it. It's not likely to be looked |
| 38 |
upon with favor. |
| 39 |
|
| 40 |
If you recall during the original discussion, I specifically mentioned |
| 41 |
that particular caveat with that flag, that it broke the C standard, so |
| 42 |
/could/ be problematic, altho I personally hadn't seen any problems with |
| 43 |
it after using it for quite some time and including an emerge --emptytree |
| 44 |
world. |
| 45 |
|
| 46 |
Thus, while it doesn't cause many problems, it could cause some, and this |
| 47 |
appears to be one location where it did. However, given the nature of the |
| 48 |
flag, it's nothing I'd bother the developers with, as it's purely at a |
| 49 |
user's own risk that they choose to use flags with such warnings, and I'd |
| 50 |
not expect it to be fixed. |
| 51 |
|
| 52 |
OTOH, check out the following bug for a counter-example, where the problem |
| 53 |
was triggered by simply following portage's own instructions, and the |
| 54 |
problem took months to resolve even tho it was a simple fix, because |
| 55 |
people were more interested in pointing the finger of blame than in simply |
| 56 |
fixing the problem. In fact, I'm sure they spent more time arguing about |
| 57 |
it (it eventually hit the dev list, and no, it wasn't me that posted it |
| 58 |
there) than they did fixing it, once they actually decided to do it. |
| 59 |
|
| 60 |
In the end, tho, it was fixed before modular-X went stable, proof the |
| 61 |
system /can/ work, even if it took awhile. |
| 62 |
|
| 63 |
http://bugs.gentoo.org/show_bug.cgi?id=116698 |
| 64 |
|
| 65 |
-- |
| 66 |
Duncan - List replies preferred. No HTML msgs. |
| 67 |
"Every nonfree program has a lord, a master -- |
| 68 |
and if you use the program, he is your master." Richard Stallman |
| 69 |
|
| 70 |
-- |
| 71 |
gentoo-amd64@g.o mailing list |
Archives