Michael Weyershäuser <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 -- [email protected] mailing list
