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

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

[Peter Humphrey]

I've just tried:

# USE=-ldap emerge gnupg

and got a compilation failure (wrong format of parameters passed to 
functions). So I created a file thus:

# cat /etc/portage/env/app-crypt/gnupg
CFLAGS=${CFLAGS//-combine}

and tried again and got the same result.

Just to be sure, I emerged gnupg with the ldap USE flag and that same env 
file, and it worked ok. I thought it should, since that's the same as the 
existing version. Next I changed the env file thus:

# cat /etc/portage/env/app-crypt/gnupg
CFLAGS="-march=k8 -O2 -pipe"
CXXFLAGS="${CFLAGS}"

Now gnupg compiled just fine with USE=-ldap. 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. Unless anyone else has already done the work, of course...

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

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

[Hemmann, Volker Armin]

On Wednesday 22 November 2006 17:28, Peter Humphrey wrote:


which one are you talking about?
because:
[ebuild     U ] app-crypt/gnupg-1.9.94 [1.9.22] USE="X 
nls -doc -gpg2-experimental -ldap -openct -pcsc-lite (-selinux) -smartcard" 
3,780 kB

so gnupg installed at least once with gcc4 and without ldap.

And I have pretty 'experimental' Cflags.
-- 
gentoo-amd64@gentoo.org mailing list

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

[Michael Weyershäuser]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

Peter Humphrey wrote:

> # cat /etc/portage/env/app-crypt/gnupg
> CFLAGS="-march=k8 -O2 -pipe"
> CXXFLAGS="${CFLAGS}"
> 
> Now gnupg compiled just fine with USE=-ldap. 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. Unless anyone else has already done the work, of course...
> 
Don't bother finding out which CFLAGS hurt gnupg. The ones posted above
are about all that is supported by Gentoo. Anything else and you're on
your own if stuff breaks. Such a bug report will most likely get closed
as INVALID.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Jack Lloyd]

On Wed, Nov 22, 2006 at 07:39:12PM +0100, Michael Weyersh?user wrote:

> Don't bother finding out which CFLAGS hurt gnupg. The ones posted above
> are about all that is supported by Gentoo. Anything else and you're on
> your own if stuff breaks. Such a bug report will most likely get closed
> as INVALID.

I would think it would still be useful to have know, so the ebuild
could use filter-flags to prevent this problem from occuring for
others (if it is in fact a CFLAGS problem).

-J



-- 
gentoo-amd64@gentoo.org mailing list

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

[Michael Weyershäuser]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

Jack Lloyd wrote:
> I would think it would still be useful to have know, so the ebuild
> could use filter-flags to prevent this problem from occuring for
> others (if it is in fact a CFLAGS problem).

It might depend on the flag we're talking about, but filter-flags and
replace-flags is mostly used for ebuilds that don't work with supported
flags (like an ebuild that doesn't like -Os but needs -O2). There has
been a debate a couple of weeks back if ebuilds should even filter
-ffast-math as this is a flag that breaks dozens of packages, sometimes
in sneaky, hard-to-debug ways, or if the ebuild should just die if it
finds that flag.

You're free to try, but the idea is that while you have a lot of choices
when using Gentoo it is not the devs duty to stop you from making bad
choices or protect you from their effects.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Duncan]

Michael Weyershäuser <thedude0001@gmx.de> posted 4564F0D8.8030904@gmx.de,
excerpted below, on  Thu, 23 Nov 2006 01:52:40 +0100:

> Jack Lloyd wrote:
>> I would think it would still be useful to have know, so the ebuild
>> could use filter-flags to prevent this problem from occuring for
>> others (if it is in fact a CFLAGS problem).
> 
> It might depend on the flag we're talking about, but filter-flags and
> replace-flags is mostly used for ebuilds that don't work with supported
> flags (like an ebuild that doesn't like -Os but needs -O2). There has
> been a debate a couple of weeks back if ebuilds should even filter
> -ffast-math as this is a flag that breaks dozens of packages, sometimes
> in sneaky, hard-to-debug ways, or if the ebuild should just die if it
> finds that flag.
> 
> You're free to try, but the idea is that while you have a lot of choices
> when using Gentoo it is not the devs duty to stop you from making bad
> choices or protect you from their effects.

FWIW, while I use somewhat "interesting" cflags, I'd certainly be for
dieing at a global portage level (so the ebuild doesn't have to worry
about it at all) with -ffast-math.  That one's simply not safe for general
use, as the gcc manpage makes quite clear.  Individual builds can and do
often add it themselves if it's safe and useful for the package to do (as
is the case with many video or visualization packages, for instance).

For others, it depends on the dev/maintainer.  Some of them are OK with
certain flags, some not.  It helps if one is aware of the situation and
already knows to try with the accepted-safe -O2 -pipe -march=<arch> flags,
only, before reporting a bug.  If it's a bug that might be CFLAG
sensitive, I do so.  Only once have I had a bug closed incorrectly, for
CFLAGS that quite obviously had nothing at all to do with the problem. 
(In that case, it was a multilib-strict error due to a file going to lib
that should have gone to lib64, obviously a file placement error unrelated
to CFLAGS.  I refiled at the next version bump when the issue still wasn't
fixed, and it was fixed within minutes... literally.)  The rest of the
time, I've usually tried before filing if it looks to be CFLAG sensitive,
tho I think I've had one closed where it was questionable early on -- I
simply tried with the requested CFLAGS and reopened.

More often, I don't file bugs because there's no way to isolate the issue
given my CFLAGs.  The latest example, I was having issues with glibc-2.5
and reverted to 2.4-r4 (gotta hack portage to do it, due to a sanity check
normally preventing glibc downgrade, but it worked), that I didn't file a
bug on as I could never satisfy myself that there wasn't a dependency I'd
missed and I didn't want to emerge --emptytree the packages in question to
find the issue.  I /suspect/ the problem is a memory allocation race
condition, probably SMP specific and possibly amd64 specific, with
optimizations in glibc-2.5 that weren't there in 2.4.  The affected
packages here were all audio/visual, amarok, xmms (before its removal),
kaffeine, but NOT kmplayer, for whatever reason.  It wasn't xine-lib
specific since xmms was affected and kmplayer wasn't. Note that glibc
itself is already filter-flagged to nearly -O2 -pipe -march=<arch> on its
own, so it's not likely to be the problem. Never-the-less, I remerged
glibc, gcc, kdelibs, kaffeine, amarok, and xine-lib, all with "safe"
cflags, bug still existed with glibc-2.5 but /not/ glibc-2.4-rX, but I
couldn't isolate it beyond that, so I didn't file the bug.  I
package.masked =glibc-2.5, so when 2.5-r1 comes out I'll tackle the
problem again.

-- 
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

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

[Peter Humphrey]

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.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

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

[Jan Jitse Venselaar]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

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.
>
> --
> Rgds
> Peter
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. "

Also, have you benchmarked in any way the effect of all these optimizations on 
the programs you run? You basically do -Os and then turn almost everything on 
which differs -O2 from -Os, negating the size difference, plus some extra 
very experimental flags, which might increase or decrease performance (sorry, 
but GCC works that way, extra optimizations could actually by 
pessimizations), and probably break some programs. 

Playing on your own computer is fine, but don't be surprised if something 
breaks, and please don't bother other people with it. It certainly is not a 
GCC 4.x problem.

Jan Jitse

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Peter Humphrey]

On Thursday 23 November 2006 12:58, Jan Jitse Venselaar wrote:

> ... have you benchmarked in any way the effect of all these
> optimizations on the programs you run? You basically do -Os and then turn
> almost everything on which differs -O2 from -Os, negating the size
> difference, plus some extra very experimental flags, which might increase
> or decrease performance (sorry, but GCC works that way, extra
> optimizations could actually be pessimizations), and probably break some
> programs. 

You may have seen some discussion of compiler optimisations on this list, in 
which a set of flags have been offered and some people have played with 
them. I thought I'd have a go, and was reporting what I'd found. In light 
of what you say, I think I'll just go back to a simple set of flags 
(-march=k8 -Os -pipe) and leave it at that. And no, I hadn't noticed any 
performance improvement with all those flags - another good reason for 
reverting. Better, probably. Thanks for the advice.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

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

[Duncan]

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