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

[Duncan]

Michael Weyershäuser <thedude0001@×××.de> posted 4564F0D8.8030904@×××.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@g.o mailing list