gtk+-2.8.17 compiled with CFLAGS="-O3 -march=pentium-m -mtune=pentium-m -fomit-frame-pointer -pipe" causes crashes in several programs 1. gedit: enable Modelines Plugin, close, open, open file -> crash 2. gaim: random crash after about 30 seconds compiling gtk+-2.8.17 with CFLAGS="-O2 -march=pentium-m -mtune=pentium-m -fomit-frame-pointer -pipe" resolves that issue reproduced several times when recompiling gtk+ with those two different CFLAGS lines I would recommend replacing -O3 flag by -O2 in ebuild
> CFLAGS="-O3 -march=pentium-m -mtune=pentium-m -fomit-frame-pointer -pipe" > 2. gaim: random crash after about 30 seconds That happens here, net-im/gaim-2.0.0_beta3 x11-libs/gtk+-2.8.17 CFLAGS="-march=athlon-xp -O3 -pipe -g" I'm not saying this is even related to this issue. Yet.
I can second that, and I think this is a severe Problem, I experienced this after upgrading to gcc-4.1.1, building for gtk+-2.8.17 with -O3 resulted for me in: *) gedit crashing whenever I try to type or select text *) Bluefish: Same thing *) Meld: even just scrolling crashes it, rest the same as the others *) Tomboy: Not able to view notes or create new ones That's just what I use daily, so there might be a lot more. Rebuilding gtk+ with -O2 solved all of these...
The same problems occurs with gtk+-2.8.18
Could you guys get backtraces (gdb) of those crashes?
Created attachment 88294 [details] gdb backtraces of gedit and GAIM crashes Having the same problem I recompiled both with "debug" and I hope this helps... here are my backtraces, Samuli. Thanks, brian
i havent seen any of these issues on amd64 but im also using gcc 4.1 the only random crashing i had seen was with liferea and it is due to issues with gtkhtml switching to mozilla backend fixed that if the flag is filtered id suggest making it arch or gcc specific Portage 2.1_rc4-r3 (default-linux/amd64/2005.0, gcc-4.1.1, glibc-2.3.6-r3, 2.6.17-rc4-git10 x86_64) ================================================================= System uname: 2.6.17-rc4-git10 x86_64 AMD Athlon(tm) 64 Processor 2800+ Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r4 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O3 -pipe -fweb -ftracer -ftree-vectorize" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -O3 -pipe -fweb -ftracer -ftree-vectorize" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks fixpackages metadata-transfer nostrip parallel-fetch sandbox sfperms userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1" MAKEOPTS="" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/mdhd/portage.local" SYNC="rsync://vox.net/gentoo-portage" USE="amd64 X a52 aac alsa avi berkdb bitmap-fonts bzip2 cairo canna cdda cddb cdr cjk cli crypt cups dbus dri dts dv dvb dvd dvdread eds emboss encode esd fam fbcon fbdev firefox fits flac foomaticdb geos glitz gml gnome gstreamer gtk gtk2 gtkhtml hdf hdf5 imagemagick imlib ipv6 isdnlog jpeg kde live lzw lzw-tiff mad matroska mng mp3 mp4 mpeg musepack ncurses netcdf nls nptl nptlonly ogg oggvorbis opengl pam pcre pda pdf pdflib perl png pppd python qt quicktime readline reflection rtsp sdl session speex spell spl ssl stream svg tcpd theora tiff truetype truetype-fonts type1-fonts unicode usb userlocales v4l v4l2 vcd vorbis wmf x264 xine xml xml2 xmms xorg xpm xv xvmc zlib elibc_glibc input_devices_mouse input_devices_keyboard kernel_linux userland_GNU video_cards_radeon" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LINGUAS
It seems that gdm-2.14.8 has the same problems, compiling it with -O3 makes gdm unusable. -O2 solves these problems.
I just experienced this today. I have segfaults on gaim2 and gedit just after upgrading to gtk+-2.8.19 (I just changed to -O3) Here is the backtrace of gaim #0 0xb7d43567 in gtk_text_insert () from /usr/lib/libgtk-x11-2.0.so.0 #1 0xb7d5c0c9 in gtk_text_iter_forward_to_line_end () from /usr/lib/libgtk-x11-2.0.so.0 #2 0xb7d611e8 in gtk_text_layout_get_iter_at_line () from /usr/lib/libgtk-x11-2.0.so.0 #3 0xb7d6532a in gtk_text_layout_get_iter_at_position () from /usr/lib/libgtk-x11-2.0.so.0 #4 0xb7d653de in gtk_text_layout_get_iter_at_pixel () from /usr/lib/libgtk-x11-2.0.so.0 #5 0xb7d794d2 in gtk_text_view_get_iter_at_location () from /usr/lib/libgtk-x11-2.0.so.0 #6 0x08106cbc in gtk_imhtml_set_editable () #7 0xb7cbc650 in gtk_marshal_BOOLEAN__VOID () from /usr/lib/libgtk-x11-2.0.so.0 #8 0xb7a29119 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #9 0xb7a28ddb in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #10 0xb7a3e1eb in g_signal_has_handler_pending () from /usr/lib/libgobject-2.0.so.0#11 0xb7a3f31d in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #12 0xb7a3f8c6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #13 0xb7de0a44 in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0#14 0xb7cb79fa in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #15 0xb7b1b650 in gdk_window_is_viewable () from /usr/lib/libgdk-x11-2.0.so.0 #16 0xb7b1b71f in gdk_window_process_all_updates () from /usr/lib/libgdk-x11-2.0.so.0 #17 0xb7c13b36 in gtk_container_add_with_properties () from /usr/lib/libgtk-x11-2.0.so.0 #18 0xb79be751 in g_child_watch_add () from /usr/lib/libglib-2.0.so.0 #19 0xb79bb497 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #20 0xb79bce35 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0 #21 0xb79bd15a in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #22 0xb7cb7231 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #23 0x08110868 in main () I won't copy the one from gedit (unless told to) but it also fails on gtk_text_insert () when I try to select text. here is my emerge --info Portage 2.1.1_pre1-r1 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.16-suspend2-r8 i686) ================================================================= System uname: 2.6.16-suspend2-r8 i686 Mobile Intel(R) Pentium(R) III CPU - M 800MHz Gentoo Base System version 1.12.1 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [disabled] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r2 dev-util/confcache: 0.4.2-r1 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17.50.0.2 sys-devel/gcc-config: 2.0.0_rc1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -msse -mtune=pentium-m -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/NX/etc /usr/NX/home /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O3 -msse -mtune=pentium-m -pipe" DISTDIR="/var/tmp/distfiles" FEATURES="autoconfig distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.gentoo.gr.jp http://85.25.128.62 http://ftp.heanet.ie/pub/gentoo/" LANG="fr_FR.UTF-8" LC_ALL="fr_FR.UTF-8" LDFLAGS="-Wl,--as-needed" LINGUAS="en fr ja zh" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/overlays/portage /usr/portage/local/layman/liferea_overlay /usr/portage/local/layman/musicbrainz /usr/portage/local/layman/gentopia /usr/portage/local/layman/flameeyes-overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acl acpi alsa avahi avi bash-completion bitmap-fonts bogofilter bzip2 cairo canna cjk cli crypt cups daap dbus dri drm eds emboss exif firefox foomaticdb freewnn fuse gif glitz gnome gnutls gphoto2 gpm gstreamer gstreamer010 gtk gtk2 gtkhtml hal iproute2 ipv6 irda isdnlog jpeg kde libg++ libnotify libwww logrotate mad matroska mikmod mmx mp3 mpeg musicbrainz nautilus ncurses nls nptl nptlonly nsplugin ogg oggvorbis opengl pam pcmcia pcre pdflib perl png pppd python quicktime readline reflection samba sasl sdk session spell spl sse ssl svg tcpd theora threads truetype truetype-fonts type1-fonts udev unicode usb userlocales vorbis xml xmms xorg xv zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev input_devices_wacom kernel_linux linguas_en linguas_fr linguas_ja linguas_zh userland_GNU video_cards_i810" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS I also tryed with no LDFLAGS but it didn't helped. I'll report back if -O2 helps me too.
Ok the -O2 fixed my problem. Maybe this would be interesting for upstream to know ?
*** Bug 138489 has been marked as a duplicate of this bug. ***
We need at least a backtrace with full debugging information.
Reopen w/ a useful backtrace from something else than gaim. Gaim is b0rked like hell itself (http://tinyurl.com/n69xa) - no proof of gtk breakage there.
Well, if gtk+ is compiled with USE="debug", the crashes disappear. Maybe you know how to get more info... This is from gedit, gtk+ was compiled WITHOUT USE="debug" #0 0xb7b19c14 in gtk_text_insert () from /usr/lib/libgtk-x11-2.0.so.0 #1 0xbfc06dc8 in ?? () #2 0xbfc06dd0 in ?? () #3 0xbfc06db0 in ?? () #4 0x0845bdd8 in ?? () #5 0xb7be22c2 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #6 0xb7c691a7 in gtk_interface_age () from /usr/lib/libgtk-x11-2.0.so.0 #7 0x00000001 in ?? () #8 0x082e8b08 in ?? () #9 0x082e8a50 in ?? () #10 0x00000001 in ?? () #11 0x00000001 in ?? () #12 0x00000001 in ?? () #13 0xffffffff in ?? () #14 0x034fd241 in ?? () #15 0xa0d705d2 in ?? () #16 0x083f6a68 in ?? () #17 0x083f6a68 in ?? () #18 0x00000001 in ?? () #19 0x00000001 in ?? () #20 0xb7118e10 in ?? () from /usr/lib/libpython2.4.so.1.0 #21 0xb6a967c7 in init_gtk () from /usr/lib/python2.4/site-packages/gtk-2.0/gtk/_gtk.so #22 0xbfc06da4 in ?? () #23 0x00000001 in ?? () #24 0x2e597763 in ?? () #25 0xb7015765 in g_type_get_qdata () from /usr/lib/libgobject-2.0.so.0 #26 0xb7118e10 in ?? () from /usr/lib/libpython2.4.so.1.0 #27 0xb7074c30 in PyDescr_NewMethod () from /usr/lib/libpython2.4.so.1.0 #28 0x00000000 in ?? ()
I have the same bug, wich also diappear when compiling with -O2 (on a athlonxp machine). It happens in almost al the gtk-apps (all the ones wich have an editor) and gdb say it happens in gtk_text_backward_delete. I will play with gdb and ddd to see if I can find more about this bug. (note: Ihave gtk-2.8.19 and gcc4.1.1, but it was already present with gcc4.0 and gtk2.8.18)
Here's a usable backtrace from gedit (the crash is in the same function in gaim and meld, I didn't check others yet; gtk+-2.8.19, glib-2.10.3, pango-1.12.3, but happened with older ones as well): #0 0xb7a08f56 in _gtk_text_btree_get_chars_changed_stamp () from /usr/lib/libgtk-x11-2.0.so.0 #1 0xb7a2167c in gtk_text_iter_ends_line () from /usr/lib/libgtk-x11-2.0.so.0 #2 0xb7a21908 in gtk_text_iter_forward_to_line_end () from /usr/lib/libgtk-x11-2.0.so.0 #3 0xb7a1c8be in gtk_text_layout_draw () from /usr/lib/libgtk-x11-2.0.so.0 #4 0xb7a41b2d in gtk_text_view_expose_event () from /usr/lib/libgtk-x11-2.0.so.0 #5 0xb7f59412 in gtk_source_view_expose () from /usr/lib/libgtksourceview-1.0.so.0 #6 0x080a2468 in gedit_view_expose () #7 0xb798356e in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #8 0xb7444719 in g_type_class_meta_marshal () from /usr/lib/libgobject-2.0.so.0 #9 0xb7445ee9 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #10 0xb7456b4e in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 #11 0xb7457abd in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #12 0xb7457e99 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #13 0xb7aa5a88 in gtk_widget_event_internal () from /usr/lib/libgtk-x11-2.0.so.0 #14 0xb797eb23 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #15 0xb77e41db in gdk_window_process_updates_internal () from /usr/lib/libgdk-x11-2.0.so.0 #16 0xb77e42b7 in gdk_window_process_all_updates () from /usr/lib/libgdk-x11-2.0.so.0 #17 0xb78db712 in gtk_container_idle_sizer () from /usr/lib/libgtk-x11-2.0.so.0 #18 0xb73d11a1 in g_idle_dispatch () from /usr/lib/libglib-2.0.so.0 #19 0xb73d5929 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #20 0xb73d6168 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #21 0xb73d6507 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #22 0xb797e373 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #23 0x0806716b in main () As reported by ohers, I also don't get the crash with neither gcc-4.1 with -O2 nor gcc-3.4.6.
Created attachment 92118 [details] eclipse crashlog Confirmed, I get segfaults from a (private (non-portage) binary installation) of eclipse, since I have x11-libs/gtk+ 2.8.19 compiled with gcc 4.1.1 and -O3. I attached the error log, in case this is of use to you guys. So long, Alexander >>Flexx<< Wessel
*** Bug 136740 has been marked as a duplicate of this bug. ***
*** Bug 141084 has been marked as a duplicate of this bug. ***
x11-libs/gtk+-2.8.19 and "-ftree-vectorize" on GCC 4.1.1 causes segfaults with any app that tries to start a color picker. For example, when choosing a color in the Gnome About Me preferences, choosing a color for the desktop background, or changing the font color in GAIM all cause segfaults in the mentioned applications. Compiling without ftree-vectorize causes this problem to go away.
I have those settings : CFLAGS="-O2 -march=pentium3 -ftree-vectorize -pipe" on an up to date unstable box and the problem you mention didn't show up yet. Can you please add more details about your setup.
It was gtk+ compiled with -finline-functions that cause my GAIM to crash onece I open a second window (eg:chat/log) with my mouse moving. Remove the option and re-compile gtk+ prevent the problem. Suggest ebuild filter.
no, flag filtering will not be done
Can you at least tell us a reason you think it's a good thing that everybody with -finline-functions should have all of their gtk+ apps crashing like crazy? It's confirmed and widespread. Why would you do nothing about it?
Simply because these are non trivial bugs. Tracking the exact cause of such bugs takes huge amount of time : going through pre-compiler/compiler/linker output is tedious. Both gcc and gtk are projects with very large code bases, which increases difficulty. As for flag filtering itself, only common flags (-O2, -g, ...) are usually filtered if they break a package. My recommendation (as a non dev) is to either take the flag off your CFLAGS or keep an overlay with the filter-flag command.
Re comment #24: but isn't -O3 a common flag? I guess I haven't read the docs in a long time but I thought that O3 was fairly conservative. If O3 is not a "common flag" then I agree (and also I'll stop using O3).
Ok, I did a bit of reading and I guess an upstream bug that's problably appropriate here is: http://bugzilla.gnome.org/show_bug.cgi?id=120118 It says that GNOME marks anything with -O3 or higher as NOTABUG, so I guess I'll start using -O2 for everything from now on. Sorry for the bugnoise!
-O3 isn't remotely conservative. There isn't a higher optimization setting for gcc. GNOME is probably right about its policy, and the problem is almost certainly with gcc. However, if -O3 and -finline-functions can easily be filtered out for the gtk+ ebuild, I fail to see a good reason that it shouldn't be. No, it's not a solution to the problem; it's not a patch to gtk+ or gcc, but it does prevent a few thousand more aggravated users and duplicate bug reports.
Neither GNOME upstream nor the Gnome herd supports CFLAGS beyone -march and -O2. Please rebuild with valid CFLAGS. See the policy at http://www.gentoo.org/proj/en/desktop/gnome/gnome-policy.xml
I do NOT agree with your policy. Only because gnome upstream does not support anything beyond -O2 this is no reason to _force_ ALL gentoo users who use gnome to set their flags to -O2. -O3 is a widely accepted flag, most packages respect it, so why should I not be able to use it? Because this is your policy? Many other packages, for example mplayer, filter CFLAGS that are not supported by the package, in the latest mplayer ebuild you can find these lines: # ugly optimizations cause MPlayer to cry on x86 systems! if use x86 ; then replace-flags -O0 -O2 replace-flags -O3 -O2 filter-flags -fPIC -fPIE fi I think this is very little additional expense as it could be easily included in the gnome eclass (as far as I understand eclasses) if it affects all gnome packages. But it's definitely no solution to force all gentoo gnome users to set their optimization level to -O2 or less.
The number one reason for not doing it is that the gnome2 eclass is used by a *lot* of packages, some that are not even officially part of Gnome. Filtering flags in the eclass only hides the problems, which is _exactly_ what the Gnome Herd wants to avoid. As to -O3 being ok for most packages but not for Gnome, you should convince the Gnome people to change their policy _and_ you should give them a hand too fixing these bugs too. As far as Gentoo is concerned, it's a matter of not having the ressources to resolve such problems. The Gnome Herd already has enough work on their hands as it is. I too wish things were different, but unless you (and others, 'cause you're not alone) are willing to help fix these bugs, the Gnome Herd policy is a sane way to keep focused on the real issues : making Gnome rock on Gentoo.
(In reply to comment #30) > The number one reason for not doing it is that the gnome2 eclass is used by a > *lot* of packages, some that are not even officially part of Gnome. Filtering > flags in the eclass only hides the problems, which is _exactly_ what the Gnome > Herd wants to avoid. OK, then I was wrong about adding these lines to the eclass. > As to -O3 being ok for most packages but not for Gnome, you should convince the > Gnome people to change their policy _and_ you should give them a hand too > fixing these bugs too. As far as Gentoo is concerned, it's a matter of not > having the ressources to resolve such problems. It's surely true that these problems are hard to solve and that Gentoo lacks the ressources for doing this. But the solution of such bugs is not to fix the code the way that it works with all flavors of CFLAGS, but to filter CFLAGS that are known by bug reports like this one here to not work. The community, we are helping to discover and fix these issues with bug reports like this one. > I too wish things were different, but unless you (and others, 'cause you're not > alone) are willing to help fix these bugs, Isn't it a fix to include the line replace-flags -O3 -O2 into the ebuild of gtk+ and maybe other ebuilds suffering this bug? It's the same fix as if you say "Neither GNOME upstream nor the Gnome herd supports CFLAGS beyond -march and -O2." but you would not _force_ the users to set their *system-wide* CFLAGS to -O2 . > the Gnome Herd policy is a sane way > to keep focused on the real issues : making Gnome rock on Gentoo. One of the main efforts of Gentoo as Gentoo states it on the start page of the homepage: "We produce Gentoo Linux, a special flavor of Linux that can be automatically optimized and customized for just about any application or need. Extreme performance, [...]" is the opportunity to optimize your system. One central approach to this is customizing the CFLAGS. And Gentoo does IMHO only "rock" when I have any advantages of using my own compiled packages. Saying we make all Gentoo users set their CFLAGS to -O2 is IMHO not very far away from saying: please use binary packages as we have too much work making compiling work on every system. portage has functions like replace_flags and filter_flags for exactly this reason: To modify on a per package basis the CFLAGS that are not supported because they cause issues that are hard or even not to fix.
Is there any ongoing discussion on this issue in the GNOME herd? Shall I bring this discussion up somewhere else? Could someone from the GNOME herd please take stand on the arguments I gave?
Upstream. Disclaimer: I am not a Gnome herd member.
No, since if you read my statements above, I'm not requesting a generally GNOME support for -O3 which should be discussed upstream, there you would be right, but I'm requesting the use of replace-flags in GNOME ebuilds in Gentoo, which is definitely a Gentoo issue, especially the care of the GNOME herd. What arguments exist against using replace-flags for -O in ebuilds?
Allow me to play the devil's advocate. One could argue that he lost his password to the portage tree check-in. Or that, since e-builds are FOSS, those who want the e-build to work correctly should fix it themselves and provide a patch. Or that one can't possibly _enjoy_ being an e-build maintainer, so destroying the entire distribution's reputation by refusing to make a simple fix to a reproducible bug that will affect thousands of users is actually a positive move, from an Objectivist standpoint.
I had thought I'd covered this already, but that was apparently in a different bug. We (the gnome herd) won't support -O > 2. We also won't do flags-replace. If people report bugs with these problems, we politely tell them to re-compile. Generally, people can do what they want with their flags on gentoo, and lots and lots of packages that generally work fine use the gnome2 eclass, so we cannot do it there. We don't run with these CFLAGS, so we can't catch problems on an individal basis ourselves, and the resulting bug war for "Works for me" "well fails for me" would be enormous, in my opinion. At any rate, we've decided to handle things this way. Feel free to drop into #gentoo-desktop and try to change our minds. We might be convinced to make an exception for gtk+, since so much uses it.
Whatever the right solution is, this isn't it. gtk+ is a very popular package, probably more popular than gnome. I would bet there are only a handful of non-kde X-users who don't have it and a lot of kde users who do. I wouldn't exactly call -finline-functions || -O3 uncommon, either. If there was a simple way in portage for a user to do this himself, that would be fine. A CFLAGS equivalent of package.use would suffice. /etc/portage/bashrc is not good enough. It requires way too much background information for the average person who is going to experience this problem (and it's not exactly well-advertised). Just recompiling is not good enough for the user who updates or recompiles frequently. I've already had this bug regress on me, and I was not pleased. gtk+ is not the fastest thing in the world to compile, and all gtk+ programs are almost completely unusable in the interim. If the problem here is that it would be difficult to filter CFLAGS because of a dependence on the gnome2 eclass, then this is an area where portage should be improved. So, either way, perhaps this should be reassigned to the portage development team. We can allow them to make an informed decision about the proper way to resolve this.
I figured I'd add my $0.02 here as well. I strongly agree with Mark Tiefenbruck here. I feel the most appropriate solution to this issue is the filter -O3 down to -O2 in the gtk+ ebuild. I mean that's the point of having the filter-flag command in ebuilds right? to filter out flags known to break things in that ebuild? I just spent 3 days trying to track down my gaim crashing bug when i finally found this bug report. If it were filtered, I certainly could have spent this time better :-P Also as far as filtering at a more general level. I can see why you wouldn't want to filter at the gnome2 eclass level, but why not have a seperate eclass for official gnome packages which both inherits from the current gnome2.eclass AND filters out -O3 since it is not "supported" by the gnome team. This way packages not part of the official gnome tree can still have more agressive flags AND you effectivly eliminate all "false" bug reports related to it. Basically, the bottom line is, I see no point in allowing the user to use flags on a given ebuild which will only lead to a broken binary. If we are really dead set on not filtering, perhaps we can at least put a warning notification "you are building with cflags known to break this package" kinda adeal when you try to emerge it? Evan Teran
I agree with Evan Teran and Mark Tiefenbruck, filtering out O3 would be the best option, otherwise a BIG FAT warning (with BEEP....) would be at least better than nothing. A lot of the bugreports about gnome/gtk programs are probably related to this, they just don't know it, b/c this error is not easy to track down. (for normal users). Reopening bug (sorry, but otherwise users will have even more trouble to find this bug when they encounter it), the current solution "Well, let the user figure out the error, we don't even tell them that GNOME doesn't support O3" is not acceptable, a warning should be the minimum.
The backtrace in comment 15 looks like http://bugzilla.gnome.org/show_bug.cgi?id=347585 (which has a working patch attached).
Sylpheed crashes if GTK 2.8.19 is compiled using GCC 4.1.1. Solved it by usung GCC 3.4.6 to build GTK libraries.
Just to add my thoughts: /etc/make.conf.example contains -O3 in CFLAGS and CXXFLAGS. flag-o-matic.eclass's strip-flags function does not filter -O3 for ~arch. -O3 is simply supposed to be supported on Gentoo, even if that means replacing the flag with -O2 for ebuilds that are known to break with it.
I think adding a workaround in gtk+ ebuild is a wise idea, *but* replacing -O3 with -O2 is inadequate for two reasons: - it is overkill - it won't handle the cases where -finline-functions is present in CFLAGS. IMHO the proper (and verified) workaround is to simply append "-fno-inline-functions" to CFLAGS. With current (unmodified) ebuild, this can be done as follows: mkdir -p /etc/portage/env/x11-libs echo 'CFLAGS="${CFLAGS} -fno-inline-functions"' >/etc/portage/env/x11-libs/gtk+ Please test this :-)
Looks good, seems to work, now if this could be put into the ebuild ASAP, this bug could finally be closed.
Joels solution worked for me too (GTK+ 2.8.19, GCC 4.1, x86) - all my GTK-aps were crashing after selecting text in text-box (for example - select text in GEdit). Problem disappeared after compiling GTK with "-fno-inline-function"... but I have wasted a couple of days for searching this solution. :/ Is it a problem to make a BIG FAT WARNING about "-f-inline-function" in GTK compilation?
@ Krzysztof Kozlowski: A BIG FAT warning should also include every flag which itself includes -finline-functions (i.e. -O3) The best solution would be adding -fno-inline-functions to CFLAGS in the ebuild like Jo
@ Krzysztof Kozlowski: A BIG FAT warning should also include every flag which itself includes -finline-functions (i.e. -O3) The best solution would be adding -fno-inline-functions to CFLAGS in the ebuild like Joël pointed out. (an additional warning (explanation) would be nice too) BTW, is this error still present in gtk-2.10.x ?
Everyone is told to recompile an application with sane CFLAGS before reporting bugs, okay. But as for the people here, not "GTK" crashed, but GAIM did. Or Bluefish (those were the two for me), so rebuilding them did not lead anywhere. Now rebuilding the whole dependency tree just to find one messed up ebuild isn't fun either. Replacing or filtering the CFLAGS if they breeak this ebuild or append another CFLAG to fix this would have saved a lot of time to the people reporting dupes of this bug or wondering in the forums, especially after stabilizing gcc-4.1.1. I don't want to blame anyone here (doesn't help anyway :-), but looking ahead in this issue, I'd say: If it can easily be fixed (in the gtk ebuild?), then why don't? For other arguments, I'd go with comments #43, #38 and #37.
We've talked this over, and decided it's a good idea to filter CFLAGS for gtk+. I've done this now.
(In reply to Andreas Proschofsky from comment #2) > I can second that, and I think this is a severe Problem, I experienced this > after upgrading to gcc-4.1.1, building for gtk+-2.8.17 with -O3 resulted for > me in: > > *) gedit crashing whenever I try to type or select text not reproducible anymore > *) Bluefish: Same thing not reproducible anymore > *) Meld: even just scrolling crashes it, rest the same as the others not reproducible anymore > *) Tomboy: Not able to view notes or create new ones not reproducible anymore
Can we add a custom-cflags USE flag (with the usual warnings about no support) to gtk+ ebuilds? I've been running gtk+-3.x with -O3 since forever and have not had a single issue. Maybe it's time to reevaluate this.
I've removed it for 3.22.9. If I see some stream of weird bugs appearing, it will go back to how it was, but lets give it a chance after 10 years then.
