If one attempts to build metacity for verbose debugging (possibly required for Bug #277361) one will get a build which will segfault if one tries to debug it. Reproducible: Always Steps to Reproduce: 1. Attempt to build metacity with debug + xinerama USE flags + -ggdb, nostrip 2. Stop after ebuild configures, make a copy of the build directory, reconfigure using the --enable-static and --enable-verbose-mode=yes options. 3. Adjust ones .profile to include: export METACITY_USE_LOGFILE=1 export METACITY_VERBOSE=1 export METACITY_DEBUG=1 export METACITY_SYNC=1 4. Try to run metacity Actual Results: Metacity segfaults. Expected Results: 1) One should be able to use the USE flags to build metacity with "verbose" and "static" without having to jump through hoops -- this is an ebuild configuration problem. 2) One should be able to get verbose trace output from metacity. I think I managed to pin this down to METACITY_SYNC option (which might be necessary to debug Bug #277361 if its due to synchronization / race condition problems) but am not absolutely certain.
Created attachment 200175 [details] emerge --info and related version information
Please provide a backtrace of the crash. Also, what do you expect --enable-static to do actually ? FTR, it is expected that most libs above glib/gtk+ level will fail in various ways since they are not tested for that purpose most of the time.
Gilles, what the Gentoo "static" USE flag "should" do is pass --enable-static to the configure script. Now, what should be done at that level is open to discussion. For libraries (e.g. gtk+) it should produce the ".a" files that allow one to build real static executables with the (-s/-static gcc options). For target executable packages (e.g. gimp, metacity, mplayer, firefox, etc.) it should build *really* static programs -- i.e. if one does "ldd" on the executable, it produces a message that it is not a dynamic executable, not a library list which includes /lib/libdl.so.2. Now, there are several reasons for this: 1) Disk space is cheap and getting cheaper (so storing static programs which are tested and known to work reliably for years or more is not unreasonable). 2) People time is expensive and more difficult to come by esp. if deep levels of knowledge are required due to increasing program complexity. Time I spend debugging system level problems (the openrc upgrade, the recent breaking of "/bin/mount" in the course of a an e2fsprogs/e2fsprogs-libs unmerge/re-emerge upgrade, the 3 gtk+ bugs in Firefox (two of which may be due to library upgrades), etc. all make me want *static* executables. 3) Dynamic loading generally speaking will slow down program startup time (metacity requires loading 50+ libraries, firefox something like 70+. If one has a lot of memory (I have upgraded my machine to 3GB) then startup time may be the scarce resource vs. DRAM or disk blocks. Now, for "mixed" packages which are large (e.g. ncbi-tools/ncbi-tools++) one may need two USE/configuration options, "static" and "static-exe" (which appear to currently be in the NCBI configure script). The "static" option would produce a ncbi-tools.a option but still link the executables with ncbi-tools.so and only when one used the static-exe option would the non-dynamic executables be produced. It looks like the current ncbi-tools default configuration produces "static" executables by default which is probably not desired since they range in size from 2-8 MB and there are something like 50 of executables. This is one of the rare cases where there are many rarely used components in the package and so disk space conservation may take priority over long term program reliability or program startup time. It should be noted, that from a scientific standpoint, if one wants to be able to reproduce results, retaining a "static" version of a program is really a requirement. One cannot trust 5 years down the road one will get the same results if the program makes use of lots of shared libraries (and one has not saved all of the precise versions). Also note that the Gentoo "static" use flag is somewhat overloaded, as for many system libraries one would like the ability to build or not-build (a) shared libraries; (b) archive libraries; (c) shared executables; (d) static executables. This may be further complicated by the fact that some packages may be difficult when one wants "both" --enable-static *and* --enable-shared. I seem to recall encountering this with either gtk+ or glib at some point in the past though I am not sure if it is still true. Also, as far as metacity goes, I don't think --enable-static will produce a real static executable. This is a real bug in the metacity configuration/build that should be bumped up to the Metacity developers (the same may applies to all of the core gnome executables). One finds the --enable-static option in almost all package configure scripts -- now whether or not it does anything (esp. what the user would desire (according to the above discussion) seems to be a package by package situation.
Boy are you late to the party. And for the record, _by_design_ most of Gnome cannot be built as static. You're just wasting your time by doing that. Everyone is working on getting rid of static libraries for most of the portage tree, except for a very few packages (glib for instance). So that part of your bug report is WONTFIX. Now, back to the metacity bug, do you have a backtrace of some sort? Thanks
yeah, the dynamic vs. static debate is old, if you really want to revive it, just go to the dev ml. About metacity, I'm pretty sure it will not change anything to pass --enable-static, that or it will actually do harm the result.
The problem is definitely with the METACITY_SYNC flag. If one modifies ones .profile, so it includes "export METACITY_SYNC=1" in addition to setting "METACITY_USE_LOGFILE=1 METACITY_VERBOSE=1 META_CITY_DEBUG=1" metacity will segfault. The gdb results show: (gdb) run Starting program: /usr/bin/metacity [Thread debugging using libthread_db enabled] [New Thread 0xb7030700 (LWP 3277)] Opened log file /home/firefox/.tmpdir/metacity-3277-debug-log-XYZYXU Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7030700 (LWP 3277)] 0x0805f562 in meta_set_syncing (setting=1) at core/display.c:4004 4004 XSynchronize (meta_get_display ()->xdisplay, is_syncing); (gdb) thread apply all bt Thread 1 (Thread 0xb7030700 (LWP 3277)): #0 0x0805f562 in meta_set_syncing (setting=1) at core/display.c:4004 #1 0x0806fbbd in main (argc=1, argv=0xbf85d894) at core/main.c:422 (gdb) list 3999 { 4000 if (setting != is_syncing) 4001 { 4002 is_syncing = setting; 4003 4004 XSynchronize (meta_get_display ()->xdisplay, is_syncing); 4005 } 4006 } 4007 4008 /** This is a "Programming 101" error -- using the result of a function as a pointer without properly testing that it is valid and suggests the metacity developers haven't bothered to test their code completely.
I am reopening this bug as the build uses the "standard" as distributed sources with only the debug (and xinerama) USE options. The segfault is clearly documented and a look at the code suggests there are some problems with sequencing when and how the display access is setup and when the debug file (which needs to log various interactions with the display) is setup. For example, if one doesn't have "METACITY_USE_LOGFILE" set, then the output should go to stderr (?) which in theory should output to the display unless some redirection to a file has been setup (which is presumably hard to do unless one hacks the gnome-session setup files). Regarding the static vs. shared debate, if the configure script includes: --enable-shared[=PKGS] build shared libraries [default=yes] --enable-static[=PKGS] build static libraries [default=yes] options, and the package installs: /usr/lib/libmetacity-private.so.0.0.0 /usr/lib/libmetacity-private.a then the question should be raised as to *what* utility references these? (/usr/bin/metacity itself does not!) Why is Gentoo wasting disk space with unused libraries? (Metacity is a good example of a program where a "static" executable is what should be the result of --enable-static (or --enable-static-exe)) given that it takes 20-30 seconds for a gnome-session to start on my machine (when other gnome sessions are running and presumably all of the shared libraries are sitting in memory). Of course one would want "static" gnome-session, gnome-panel, metacity and some of the panel applet executables to verify what the real minimum gnome-session start times are.)
(In reply to comment #7) > Regarding the static vs. shared debate, if the configure script includes: > --enable-shared[=PKGS] build shared libraries [default=yes] > --enable-static[=PKGS] build static libraries [default=yes] > options, and the package installs: > /usr/lib/libmetacity-private.so.0.0.0 > /usr/lib/libmetacity-private.a > then the question should be raised as to *what* utility references these? > (/usr/bin/metacity itself does not!) Why is Gentoo wasting disk space with > unused libraries? > > (Metacity is a good example of a program where a "static" executable is what > should be the result of --enable-static (or --enable-static-exe)) given that it > takes 20-30 seconds for a gnome-session to start on my machine (when other > gnome sessions are running and presumably all of the shared libraries are > sitting in memory). Of course one would want "static" gnome-session, > gnome-panel, metacity and some of the panel applet executables to verify what > the real minimum gnome-session start times are.) Listen, if you want us to actually help you, then please stay on topic with bug reports. We all have between 200 and 300 bugs on our watch lists and this dynamic vs static debate is just _noise_ for bugzilla. Please get in touch with us on IRC if you want to discuss this with us, bugzilla is not the place for such discussions. Thanks
please report this error upstream and paste the url here.
