| View previous topic :: View next topic |
| Author |
Message |
ctt
Tux's lil' helper
Joined: 05 Feb 2005
Posts: 136
|
 Posted: Fri Feb 18, 2005 11:09 pm Post subject: |
 |
|
Wow...this discussion is still going on? If one feels s/he needs to experience the benifits of the quantum leap from -O2 to -O3, go ahead...it just involves a few edits which (as the quality of your comments would tend to suggest) you should have no trouble handling.
Seriously, now; if there's someone this passionate about intentionally causing unpredictable behaviour in emerged programs, doesn't it stand to reason that there will be others who (after setting unsafe CFLAGS) would be just as passionate about such behaviour poping up out of the blue? These guys have a distribution to maintain, which becomes very difficult when things continue to break for well known, avoidable, reasons.
_________________
- chris |
|
| Back to top |
|
 |
Carlo
Developer
Joined: 12 Aug 2002
Posts: 3356
|
| Posted: Sat Feb 19, 2005 1:20 am Post subject: |
|
|
| nightmorph wrote: | | Pythonhead wrote: | Seriously though, what do you propose we do if, for instance, -O3 breaks a package for many people (look in bugzilla, it happens).
Make people edit the ebuild and change it to -O2? I think removing a known problem for many people is a better solution than leaving it because some people think it may work for them. |
I guess that is a problem--if it does come down to an issue of majority, maybe a percentage of users will have to be made unhappy. |
No. Long long before it may be a problem for the majority it's a problem for developers to filter out the amount of "invalid" bug reports, dupes etc. You are always free to have your very own overlay with your very own ebuilds. Saying that a "percentage of users" has to be made unhappy, while implying that you are worth it, is the most barefaced and rediculous sentence I have read in these forums ever.
_________________
Please make sure that you have searched for an answer to a question after reading all the relevant docs. |
|
| Back to top |
|
|
nightmorph
Developer
Joined: 23 Jan 2005
Posts: 1382
Location: SoCal
|
| Posted: Sat Feb 19, 2005 3:00 am Post subject: |
|
|
| Carlo wrote: | | nightmorph wrote: | | I guess that is a problem--if it does come down to an issue of majority, maybe a percentage of users will have to be made unhappy. |
No. Long long before it may be a problem for the majority it's a problem for developers to filter out the amount of "invalid" bug reports, dupes etc. You are always free to have your very own overlay with your very own ebuilds. Saying that a "percentage of users" has to be made unhappy, while implying that you are worth it, is the most barefaced and rediculous sentence I have read in these forums ever. |
You have completely misunderstood me. What I meant was that I was trying to see it from the side of a developer--I was saying that I understood that sometimes (if not all the time) the majority needs will be placed over the desires of the minoroty--in this case, I am in the minority. If some level of flag stripping is truly necessary to the Gentoo distribution as a whole, than I (and others who don't want it to happen) will just have to knuckle under and get to work on our own overlays and whatnot.
I was not implying that my needs/desires/input is more valuable than several thousand other users, or even one other user. I was not saying that it is a necessity for my needs to be met; far from it. I try to have a realistic view about such things. I did not imply that other users need to be disadvantaged for my benefit. Please don't misunderstand me in this regard.
_________________
<UzzaDead> What is CONFIG_USB_MON?
<petteyg> A Jamaican USB configuration?
dirtyepic: "We have more cupholders."
GDP || PR |
|
| Back to top |
|
|
nightmorph
Developer
Joined: 23 Jan 2005
Posts: 1382
Location: SoCal
|
| Posted: Sat Feb 19, 2005 3:21 am Post subject: |
|
|
| teknomage1 wrote: | | Isn't this the opposite side of the coin that causes people to complain, "The quality of ebuilds is dropping, I'm going to leave gentoo cause it's too buggy!" ? I mean honestly, those flags are disabled so the package will compile on most machines and work. If you're into the uber-exact options can't you just use chkinstall and compile it yourself? |
But the point of Gentoo is that it's possible to customize packages and programs for one's own specific machine, not just any generic, vanilla computer. Personally, I've never had a problem with -O3 being compiled into any ebuild, whether in my world file or in my toolchain (which I was able to complete last night using Bob P's redundant install method). Indeed, for my first install I only had "-O3 -pipe -march=pentium3 -fomit-frame-pointer" set, and the last CFLAG was just a redundant CFLAG (it's implied in -O3) to make sure I took advantage of that optimization. Never had a single problem, whether that's because my processor is known to be pretty stable or for some other reason.
If it's possible to specifically filter out flags in an ebuild, would it be possible for developers to slightly modify their approach to this by including a script run at compile time that examines make.conf with an "if-then" approach? I mean, one that's a bit more intelligent than the current blind flag stripping. Maybe it could even use the optimizations made in a specific package a baseline; i.e., if critical system package XXYY was compiled using some CFLAG, then it might be safe to use that CFLAG in this particular ebuild? It just seems like there has to be some workaround in the ebuild before it starts building the source. Gentoo isn't about being plain-vanilla; it's about being tailored. With respect to platform, isn't source code more or less identical? OOo for Pentium II is OOo for Pentium IV is OOo for AMD K6-2. It just seems to me that an ebuild's default behavior should not be to strip flags (especially flags like -O3; I haven't seen that many legitimate reports on bugzilla filed by users who knew what they were doing) by force of habit. I have read of certain bits of software that won't be compiled with one particular flag set, like -ffast-math or OOo not working with -finline-visibility-hidden.
What would be nice (and seems doable, albeit to a nonprogrammer such as myself) would be an additional step in Portage's "calculating dependencies" function, or at least one that appears when -a or -p is part of emerge. It would be a check for known specific flag faults; something to alert the user. For example, "this package is known to fail compilation with -fweb (implied by -O3 on gcc 3.4.3.x) set." Then it's up to the user to decide how much he or she wants to push Gentoo's capabilities. Certainly I haven't had any problems with mid- to advanced-flag settings, if "-O3" is advanced. I'm just trying to find a solution that doesn't involve flag stripping en masse; as Bob P has mentioned, default stripping of -O3 by nearly all ebuilds implies that maybe Gentoo is in over its head if it can't support it, or when too many packages break (whatever that number may be). I agree that it's reasonable (according to ciaranm's guidelines; see the earlier link) to still offer -O3 under a WONTFIX policy; that -O2 will be debugged but not so much anything higher.
_________________
<UzzaDead> What is CONFIG_USB_MON?
<petteyg> A Jamaican USB configuration?
dirtyepic: "We have more cupholders."
GDP || PR |
|
| Back to top |
|
|
teknomage1
Veteran
Joined: 05 Aug 2003
Posts: 1239
Location: Los Angeles, CA
|
| Posted: Sat Feb 19, 2005 4:57 am Post subject: |
|
|
| As the previous poster suggested, if you want to live life on the edge, it's trivial to remove the filer-flags lines from the ebuild on your own machine. Just don't complain if it breaks. |
|
| Back to top |
|
|
nightmorph
Developer
Joined: 23 Jan 2005
Posts: 1382
Location: SoCal
|
| Posted: Sat Feb 19, 2005 6:15 am Post subject: |
|
|
| teknomage1 wrote: | | As the previous poster suggested, if you want to live life on the edge, it's trivial to remove the filer-flags lines from the ebuild on your own machine. Just don't complain if it breaks. |
Wouldn't dream of it, believe me. Same thing if I had actually managed to build a package with -ffast-math (without using overlays); I figure that's my own foolhardiness, and not something to report to bugzilla.
_________________
<UzzaDead> What is CONFIG_USB_MON?
<petteyg> A Jamaican USB configuration?
dirtyepic: "We have more cupholders."
GDP || PR |
|
| Back to top |
|
|
Halcy0n
Developer
Joined: 17 Sep 2003
Posts: 1682
Location: Freehold, NJ
|
| Posted: Sat Feb 19, 2005 6:26 am Post subject: |
|
|
| nightmorph wrote: | | Indeed, for my first install I only had "-O3 -pipe -march=pentium3 -fomit-frame-pointer" set, and the last CFLAG was just a redundant CFLAG (it's implied in -O3) to make sure I took advantage of that optimization. |
Actually, it is only turned on with -O when it does not interfere with debugging on that architecture. x86 needs the frame-pointer for debugging, so -fomit-frame-pointer needs to be specified explicitly on x86 boxes.
As I've said before, and I'll keep saying, if you really want to use every -fsilly-flag out there, then strip all of the filter-flag statements from your tree and emerge whatever you please. You keep saying Gentoo is about the "user's choice". Well, you have the ability to easily strip these statements from your entire portage tree, its not like they are hardcoded in and you can not change them.
_________________
Mark Loeser
http://www.halcy0n.com |
|
| Back to top |
|
|
Carlo
Developer
Joined: 12 Aug 2002
Posts: 3356
|
| Posted: Sat Feb 19, 2005 2:55 pm Post subject: |
|
|
| nightmorph wrote: | | You have completely misunderstood me. |
Apparently yes - sorry. But what you do not understand is, that flags are not filtered for fun. Customability is important, but there won't be "choice at any price". It's far more important to keep the maintenance level for developers at a reasonable state. Flags get filtered when problems arise, when upstream developers accept only bug reports with the default flags they provide, or whatever - but never for no reason.
| nightmorph wrote: | | If it's possible to specifically filter out flags in an ebuild, would it be possible for developers to slightly modify their approach to this by including a script run at compile time that examines make.conf with an "if-then" approach? |
There will always be a fraction of users, who will misuse this and file bug reports because something breaks, even though it would not be supported. I'm strongly against such a "feature".
_________________
Please make sure that you have searched for an answer to a question after reading all the relevant docs. |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Sat Feb 19, 2005 7:52 pm Post subject: |
|
|
| Halcy0n wrote: | | As I've said before, and I'll keep saying, if you really want to use every -fsilly-flag out there, then strip all of the filter-flag statements from your tree and emerge whatever you please. |
can you tell me, does -O3 count as an -fsilly-flag? i'm just wondering about that. i understand the need for filtering cflags, but i wish i could get a clear answer about whether -O3 is going to be stripped in a blanket/across the board fashion on all ebuilds as some devs have suggested.
if -O3 is to be stripped out of every ebuild, then make no bones about it and admit that gentoo does not even support -O3 optimizations. it would be absolutely ludicrous for gentoo to make the claim that it supports -O3 as a legitimate optimization flag while the developers are silently stripping the flag and the user is forced to manually edit every ebuild that he wants to test -O3 with. in that scenario, it could not be more clear that gentoo does not support the -O3 compilation option. choosing to lie about it wouldn't be at all helpful for gentoo's reputation.
in contrast, the developer of a certain app finding it necessary to filter individual flags that specifically bork his ebuild is a very understandable case. such a case of filtering individual flags that are known to cause problems with a specific ebuild could hardlly be something to complain about.
there is a stark difference between these two examples. there is no common ground between them. i hope that the difference is not lost on anyone, and i hope that someday i will get a straight answer.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
teknomage1
Veteran
Joined: 05 Aug 2003
Posts: 1239
Location: Los Angeles, CA
|
| Posted: Sat Feb 19, 2005 8:11 pm Post subject: |
|
|
| Criminey Bob_P just run 'grep 'O3' $(find /usr/portage -name *ebuild)' and count how few packages strip this flag before ranting. |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Sat Feb 19, 2005 8:20 pm Post subject: |
|
|
| teknomage1 wrote: | | Criminey Bob_P just run 'grep 'O3' $(find /usr/portage -name *ebuild)' and count how few packages strip this flag before ranting. |
oops.
| Code: | | -bash: /bin/grep: Argument list too long |
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
teknomage1
Veteran
Joined: 05 Aug 2003
Posts: 1239
Location: Los Angeles, CA
|
| Posted: Sat Feb 19, 2005 8:34 pm Post subject: |
|
|
Fair enough 'find /usr/portage/ -name *ebuild | xargs -- grep 'O3' {} \; |sort |uniq >~/tmp/strippedflags'
Removing duplicates from multiple versions of the same package I only see 123 ebuilds out of thousands that even mention 03. |
|
| Back to top |
|
|
ctt
Tux's lil' helper
Joined: 05 Feb 2005
Posts: 136
|
| Posted: Sun Feb 20, 2005 1:23 am Post subject: |
|
|
| teknomage1 wrote: | | Criminey Bob_P just run 'grep 'O3' $(find /usr/portage -name *ebuild)' and count how few packages strip this flag before ranting. |
Exactly,
I did something similar, and found that 2 .ebuilds use filter-flags to strip out O3, and about 41 explicitly use stripflags. Of the .eclasses, toolchain, mozilla, and mozconfig use either strip-flags or filter-flags in some capacity. This is by no means epidemic, and in most cases is a result of (1) the .ebuilds representing critical tools (2) build breaks due to exotic flags, and (3) obvious gestures by upstream developers which would suggest a lower priority for errors due to high-op. In all of these cases, you can easily take the filter-flags/strip-flags lines out (or, better yet, rewrite flag-o-matic to be more `sane' in your opinion).
And, if you think that 41 is excessive, keep in mind that strip-flags does not filter flags for ~ (unstable) packages, so the number may well be less if you're using the ~x86 architecture (hopefully you don't go on a rant on how they don't make ~x86 the default).
All of this information is way out in the open. It just involves looking through the ebuilds you use. Bob_P, it seems like you're trying to uncover a conspiracy or something...hope this information eases your nerves.
Results (taking the newest ebuild from each package, and grepping for strip- or filter-flags)...
Strip Flags...
| Code: |
$ cd /usr/portage/; for file in */*/; do ls $file/*.ebuild -t | head -n 1 | xargs grep -H 'strip-flags'; done
app-admin/tripwire//tripwire-2.3.1.2-r1.ebuild: strip-flags
app-editors/emacs-cvs//emacs-cvs-22.0.0-r1.ebuild: strip-flags
app-emulation/basiliskII//basiliskII-1.0.0_pre20020115.ebuild: strip-flags -mpowerpc-gfxopt
app-emulation/e-uae//e-uae-0.8.27.ebuild: use x86 && strip-flags "-msse" "-msse2"
app-emulation/e-uae//e-uae-0.8.27.ebuild: use ppc && strip-flags "-maltivec" "-mabi=altivec"
app-emulation/wine//wine-20041019-r3.ebuild: strip-flags
app-office/texmacs//texmacs-1.0.4-r1.ebuild: strip-flags
dev-db/firebird//firebird-1.5.2.ebuild: #strip-flags -funroll-loops
dev-dotnet/mono//mono-1.0.2.ebuild: strip-flags
dev-lang/gauche//gauche-0.8.3.ebuild: strip-flags
dev-lang/gpc//gpc-20040516.ebuild:strip-flags
dev-lang/prc-tools//prc-tools-2.3-r1.ebuild: strip-flags
dev-lang/swig//swig-1.3.21.ebuild: strip-flags
dev-libs/libffi//libffi-3.4.3.ebuild: strip-flags
dev-scheme/gauche-gtk//gauche-gtk-0.4.1.ebuild: strip-flags
dev-util/cmake//cmake-2.0.3.ebuild: strip-flags
dev-util/monotone//monotone-0.16.ebuild: strip-flags
media-libs/gst-plugins//gst-plugins-0.8.5-r1.ebuild: strip-flags
media-libs/gstreamer//gstreamer-0.8.9-r1.ebuild: strip-flags
media-libs/jpeg-mmx//jpeg-mmx-1.1.2-r1.ebuild: is-flag "-march=k6-3" && strip-flags "-fomit-frame-pointer"
media-libs/jpeg-mmx//jpeg-mmx-1.1.2-r1.ebuild: is-flag "-march=k6-2" && strip-flags "-fomit-frame-pointer"
media-libs/jpeg-mmx//jpeg-mmx-1.1.2-r1.ebuild: is-flag "-march=k6" && strip-flags "-fomit-frame-pointer"
media-libs/libsdl//libsdl-1.2.8-r1.ebuild: strip-flags -funroll-all-loops -fpeel-loops # more bug #74608
media-libs/xine-lib//xine-lib-1.0.ebuild: strip-flags
media-sound/gnomad//gnomad-2.6.3.ebuild:strip-flags
media-video/mjpegtools//mjpegtools-1.6.2-r3.ebuild: strip-flags -fstack-protector
media-video/mplayer//mplayer-1.0_pre5-r5.ebuild: strip-flags
media-video/xanim-export//xanim-export-2.80.1-r3.ebuild:strip-flags -finline-functions
net-analyzer/ettercap//ettercap-0.7.0.ebuild: strip-flags
net-im/gaim//gaim-1.1.2.ebuild: strip-flags
net-libs/libotr//libotr-2.0.0.ebuild: strip-flags
sci-libs/djbfft//djbfft-0.76.ebuild: strip-flags
sci-libs/lapack-atlas//lapack-atlas-3.6.0.ebuild: strip-flags
sys-apps/nvram-wakeup//nvram-wakeup-0.97.ebuild: strip-flags
sys-devel/binutils//binutils-2.15.92.0.2-r1.ebuild: strip-flags && replace-flags -O3 -O2
sys-devel/patch//patch-2.5.9-r1.ebuild: strip-flags
sys-libs/glibc//glibc-2.3.4.20050125.ebuild: strip-flags
sys-libs/libstdc++-v3//libstdc++-v3-3.3.3-r1.ebuild: strip-flags
x11-base/kdrive//kdrive-4.3.0-r5.ebuild:strip-flags
x11-base/xorg-x11//xorg-x11-6.8.2.ebuild: strip-flags
x11-libs/qt//qt-3.3.4-r2.ebuild: strip-flags
x11-misc/gtodo//gtodo-0.13.5.ebuild:strip-flags
x11-plugins/gaim-encryption//gaim-encryption-2.32-r1.ebuild: strip-flags
x11-plugins/gaim-otr//gaim-otr-2.0.0.ebuild: strip-flags
|
Filter Flags (only O3)
| Code: |
$ cd /usr/portage; for file in */*/; do ls $file/*.ebuild -t | head -n 1 | xargs grep -H 'filter-flags'; done | grep O3
net-misc/dhcp//dhcp-3.0.1-r1.ebuild: [ "${ARCH}" == "sparc" ] && filter-flags -O3 -O2 -O
x11-misc/ttmkfdir//ttmkfdir-3.0.9-r1.ebuild: filter-flags -O -O1 -O2 -O3
|
| Code: |
$ for file in */*/; do ls $file/*.ebuild -t | head -n 1 ; done | wc -l
8894
|
_________________
- chris |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Sun Feb 20, 2005 3:08 am Post subject: |
|
|
| teknomage1 wrote: | | Fair enough 'find /usr/portage/ -name *ebuild | xargs -- grep 'O3' {} \; |sort |uniq >~/tmp/strippedflags' |
nice code. 
i had to mkdir ~/tmp, but after doing that everything worked fine.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Sun Feb 20, 2005 3:08 am Post subject: |
|
|
| ctt wrote: | | it seems like you're trying to uncover a conspiracy or something... |
conspiracy? no, i'm just quoting an outspoken developer.
| Quote: | Results (taking the newest ebuild from each package, and grepping for strip- or filter-flags)...
Filter Flags (only O3)
| Code: |
$ cd /usr/portage; for file in */*/; do ls $file/*.ebuild -t | head -n 1 | xargs grep -H 'filter-flags'; done | grep O3
net-misc/dhcp//dhcp-3.0.1-r1.ebuild: [ "${ARCH}" == "sparc" ] && filter-flags -O3 -O2 -O
x11-misc/ttmkfdir//ttmkfdir-3.0.9-r1.ebuild: filter-flags -O -O1 -O2 -O3
|
|
that's nice code too.
by searching for the string literal "strip-" or "filter-flags", that method misses all of the ebuilds that use different syntax; more of them use "replace-flags". as a result, it severly underestimates the prevalence of replacing -O3 with -O2.
| Code: | portage # cd /usr/portage; for file in */*/; do ls $file/*.ebuild -t | head -n 1 | xargs grep -H 'replace-flags'; done | grep O3
app-arch/ppmd//ppmd-9.1_p8.ebuild:# replace-flags "-O3" "-O2"
app-emulation/e-uae//e-uae-0.8.27.ebuild: replace-flags "-O3" "-O2"
app-office/openoffice-ximian//openoffice-ximian-1.3.8.ebuild: replace-flags "-O3" "-O2"
app-office/openoffice//openoffice-1.1.3.ebuild: replace-flags "-O3" "-O2"
app-text/tetex//tetex-3.0-r1.ebuild: use amd64 && replace-flags "-O3" "-O2"
dev-lang/gnu-smalltalk//gnu-smalltalk-2.1.8.ebuild: replace-flags '-O3' '-O2'
dev-lang/python//python-2.3.4-r1.ebuild: is-flag -fstack-protector-all && replace-flags -O3 -O2
dev-lang/python//python-2.3.4-r1.ebuild: use hardened && replace-flags -O3 -O2
dev-libs/crypto++//crypto++-5.2-r1.ebuild: replace-flags -O3 -O2
dev-util/glimmer//glimmer-1.2.1-r5.ebuild: replace-flags "-O3" "-O2"
dev-util/monotone//monotone-0.16.ebuild: # replace-flags -O3 -O2
games-emulation/mupen64-glide64//mupen64-glide64-0.7.ebuild: replace-flags -O3 -O2
games-emulation/visualboyadvance//visualboyadvance-1.7.2-r1.ebuild: replace-flags -O3 -O2
games-fps/duke3d//duke3d-20040817.ebuild: replace-flags -O3 -O2
mail-client/evolution//evolution-2.0.3-r2.ebuild: replace-flags -O3 -O2
media-libs/gst-plugins//gst-plugins-0.8.5-r1.ebuild: replace-flags "-O3" "-O2"
media-libs/gstreamer//gstreamer-0.8.9-r1.ebuild: replace-flags "-O3" "-O2"
media-libs/libtheora//libtheora-1.0_alpha3.ebuild: replace-flags -O3 -O2
media-libs/taglib//taglib-1.3.1.ebuild: replace-flags -O3 -O2
media-sound/gnomad//gnomad-2.6.3.ebuild: replace-flags -O3 -O2
media-sound/soundtracker//soundtracker-0.6.7.ebuild: replace-flags "-O3" "-O2"
media-tv/mythfrontend//mythfrontend-0.17.ebuild: is-flag "-march=pentium4" && replace-flags "-O3" "-O2"
media-tv/mythfrontend//mythfrontend-0.17.ebuild: is-flag "-march=athlon-xp" && replace-flags "-O3" "-O2"
media-tv/mythtv//mythtv-0.17.ebuild: is-flag "-march=pentium4" && replace-flags "-O3" "-O2"
media-tv/mythtv//mythtv-0.17.ebuild: is-flag "-march=athlon-xp" && replace-flags "-O3" "-O2"
media-video/mplayer//mplayer-1.0_pre5-r5.ebuild: replace-flags -O3 -O2
media-video/xanim-export//xanim-export-2.80.1-r3.ebuild:replace-flags -O3 -O2
media-video/xanim//xanim-2.80.1-r4.ebuild: replace-flags -O3 -O2
net-analyzer/ethereal//ethereal-0.10.9-r1.ebuild: replace-flags -O3 -O
net-firewall/fwbuilder//fwbuilder-1.1.2.ebuild: use sparc && replace-flags -O3 -O2
sci-biology/ncbi-tools//ncbi-tools-20040616.ebuild: replace-flags '-O3' '-O2'
sci-electronics/xcircuit//xcircuit-2.5.4.ebuild:replace-flags -O3 -O2
sys-apps/fbset//fbset-2.1.ebuild: replace-flags -O3 -O2
sys-apps/procps//procps-3.2.4-r2.ebuild: replace-flags -O3 -O2
sys-devel/binutils//binutils-2.15.92.0.2-r1.ebuild: strip-flags && replace-flags -O3 -O2
x11-libs/gtk+//gtk+-2.4.14.ebuild: replace-flags "-O3" "-O2"
|
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
ctt
Tux's lil' helper
Joined: 05 Feb 2005
Posts: 136
|
| Posted: Sun Feb 20, 2005 5:23 am Post subject: |
|
|
| Bob P wrote: | by searching for the string literal "strip-" or "filter-flags", that method misses all of the ebuilds that use different syntax; more of them use "replace-flags". as a result, it severly underestimates the prevalence of replacing -O3 with -O2.
| ctt wrote: | | Code: | portage # cd /usr/portage; for file in */*/; do ls $file/*.ebuild -t | head -n 1 | xargs grep -H 'replace-flags'; done | grep O3
app-arch/ppmd//ppmd-9.1_p8.ebuild:# replace-flags "-O3" "-O2"
app-emulation/e-uae//e-uae-0.8.27.ebuild: replace-flags "-O3" "-O2"
...
about 20 more ebuilds
...
|
|
|
How very severe  . These numbers are still not too compelling, and looking at the packages (mplayer, mupen64, ooffice, python, etc), they seem to fall into one of {very important (python, binutils, ...), likely to break (mupen64, ooffice, ...), or pending upstream fixes (gnomad*, ...)}. Looking at them case by case, they seem like reasonable choices to me:
- very important packages: It's silly throwing all of the flags on for something like python, which could leave the system in a shambles if it caused sudden random segfaults.
- likely to break: If something breaks with high-op, and it's been confirmed by the ebuild maintainer on a number of configurations, s/he could either just sit back and watch the dupes fill up his/her inbox, or just remove the problem, while in the meantime figuring out where it truely lies.
- upstream: If the problem lies in the actual package developer's hands, the best the Gentoo people can do is let them know. In some cases, the answer is along the lines of `if it hurts when you do this, don't do it', or `I'll put this right above making my program take up 0 bytes of memory in my priority list'. Neither of these give the ebuild maintainer much choice.
Hopefully, I'm not putting words in the Gentoo devs' mouths, but com'on, there's usually a reason for these things.
* -- According the Bugzilla, this is more of a bug in GCC than in gnomad, but `out of Gentoo Devs' hands' nontheless.
_________________
- chris |
|
| Back to top |
|
|
Pythonhead
Developer
Joined: 16 Dec 2002
Posts: 1801
Location: Redondo Beach, Republic of Calif.
|
| Posted: Sun Feb 20, 2005 6:46 am Post subject: |
|
|
| Bob P wrote: |
if -O3 is to be stripped out of every ebuild, then make no bones about it and admit that gentoo does not even support -O3 optimizations.
|
You're semi-quoting a single unkown developer out of 280 or so. I seem to be the sole person around here who hates purple but our website will still be purple in the morning.
| Quote: | | it would be absolutely ludicrous for gentoo to make the claim that it supports -O3 as a legitimate optimization flag |
It would, but... where do we make that claim? We don't support a flag where its known to break things. If you think that needs clarification, file a bug report and the documentation team may add it.
| Quote: |
while the developers are silently stripping the flag and the user is forced to manually edit every ebuild that he wants to test -O3 with. in that scenario, it could not be more clear that gentoo does not support the -O3 compilation option. choosing to lie about it wouldn't be at all helpful for gentoo's reputation.
in contrast, the developer of a certain app finding it necessary to filter individual flags that specifically bork his ebuild is a very understandable case. such a case of filtering individual flags that are known to cause problems with a specific ebuild could hardlly be something to complain about.
there is a stark difference between these two examples. there is no common ground between them. i hope that the difference is not lost on anyone, and i hope that someday i will get a straight answer. |
Get a straight answer about what? You haven't shown any packages that have been nefariously filtered. Theres been no official talk about removing -O3 from every package has there? If so, please supply a link.
There are plenty of bug reports where you can see what a pain it can be to track down obscure errors. Look at what it took to find out why -O3 was filtered from python in certain cases:
http://bugs.gentoo.org/show_bug.cgi?id=50309
There are about as many bug reports about people having packages break from O3 as packages you have listed, but of course developers have filtered flags because they couldn't get a package to compile before it ever got in portage, so no bug report. Is that what you mean by "silently" filtering flags? |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Sun Feb 20, 2005 7:21 am Post subject: |
|
|
| ctt wrote: | | How very severe . These numbers are still not too compelling,... |
aggreed, adding 37 more ebuilds to the count doesn't amount to an enormous figure, but the accurate number shows that the problem is about 20 times more prevelant than one would estimate it to be if one were to accept the number (two) yielded by searching for the wrong term. 
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Sun Feb 20, 2005 7:27 am Post subject: |
|
|
| Pythonhead wrote: | | Theres been no official talk about removing -O3 from every package has there? |
well, if there hasn't than i am guilty of operating under the assumption that such were the case, and i have my foot in my mouth.  i may have been listening to one vocal proponent and mistakenly attributed his statements to reflect some official policy. well, if that's not the case, there's no point in belaboring this. thanks for your input. 
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
Pythonhead
Developer
Joined: 16 Dec 2002
Posts: 1801
Location: Redondo Beach, Republic of Calif.
|
| Posted: Sun Feb 20, 2005 7:40 am Post subject: |
|
|
| Hopefully ciranm's proposal or some form of it gets in the official documentation soon so there is less confusion. |
|
| Back to top |
|
|
nightmorph
Developer
Joined: 23 Jan 2005
Posts: 1382
Location: SoCal
|
| Posted: Mon Feb 21, 2005 5:29 am Post subject: |
|
|
| Bob P wrote: | | teknomage1 wrote: | | Criminey Bob_P just run 'grep 'O3' $(find /usr/portage -name *ebuild)' and count how few packages strip this flag before ranting. |
oops.
| Code: | | -bash: /bin/grep: Argument list too long |
|
^_^
That made me smile.
After reading the latest several posts, it seems that there are a few more ways that developers remove flags than I thought there were. News to me, but I admit that (in the cases mentioned) the stripping/replacing of flags isn't quite as bad as I thought it was.
I plan to check bugzilla for some of the most common flag/package breakage problems. I am still curious about the possibility of intelligent ebuild filtering, or of a line in in an "emerge -pv" command that spits out an ebuild's filtering intent, if it has any. It certainly would save time if I knew what a package would do beforehand, rather than having to search the online package database in advance (assuming such information was even posted). That way I could fire up my trusty gedit with an idea of what to look for, rather than looking through all 50+ packages at the next "emerge -puD world".
_________________
<UzzaDead> What is CONFIG_USB_MON?
<petteyg> A Jamaican USB configuration?
dirtyepic: "We have more cupholders."
GDP || PR |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
