Re: macppc: firefox 3.6.8 crashing (same as 3.6.7)
On Sun, Aug 1, 2010 at 11:53 PM, patrick keshishian pkesh...@gmail.com wrote: On Sun, Aug 1, 2010 at 11:12 PM, Matthieu Herrb mhe...@gmail.com wrote: On Mon, Aug 2, 2010 at 7:24 AM, patrick keshishian pkesh...@gmail.com wrote: Hi, On Fri, Jul 30, 2010 at 5:49 AM, David Coppa dco...@gmail.com wrote: Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 0x221152f8 in dlsym () from /usr/libexec/ld.so (gdb) bt full #0 0x221152f8 in dlsym () from /usr/libexec/ld.so No symbol table info available. #1 0x2214af94 in ?? () from /usr/libexec/ld.so No symbol table info available. #2 0x2214af94 in ?? () from /usr/libexec/ld.so No symbol table info available. Previous frame identical to this frame (corrupt stack?) [2] Very simple program that calls dlopen() $ ./so_loader $ echo $? 20 $ gdb so_loader GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-unknown-openbsd4.7... (gdb) break main Breakpoint 1 at 0x1800a64: file so_loader.c, line 35. (gdb) r Starting program: /home/sidster/src/so_loader Breakpoint 1, main (argc=1, argv=0xfffdd2c4) at so_loader.c:35 35 dh = dlopen(SOFILE, RTLD_NOW); (gdb) n Program exited with code 024. This problem was identified as a gcc4 problem, mis-compiling ld.so. The following commit fixes it. umm.. the problem remains. unless i misunderstood what was fixed. ff3.6.8 crashes as before and my test program still exits abnormally. --patrick Excellent news! I'll wait for my mirror of choice to pick up this change. Thanks for the update, --patrick Date: Sun, 1 Aug 2010 11:55:28 -0600 (MDT) From: Mark Kettenis kette...@cvs.openbsd.org To: source-chan...@cvs.openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2010/08/01 11:55:28 Modified files: gnu/gcc/gcc/config/rs6000: rs6000.c Log message: Make __builtin_return_address(0) work with -fstack-protector. Old diff from Jakub Jelinek that never made it into upstream GCC. Fixes ld.so. Found by drahn@ and me; ok miod@ -- Matthieu Herrb
Re: macppc: firefox 3.6.8 crashing (same as 3.6.7)
On Tue, Aug 3, 2010 at 12:44 AM, patrick keshishian pkesh...@gmail.com wrote: On Sun, Aug 1, 2010 at 11:53 PM, patrick keshishian pkesh...@gmail.com wrote: On Sun, Aug 1, 2010 at 11:12 PM, Matthieu Herrb mhe...@gmail.com wrote: On Mon, Aug 2, 2010 at 7:24 AM, patrick keshishian pkesh...@gmail.com wrote: Hi, On Fri, Jul 30, 2010 at 5:49 AM, David Coppa dco...@gmail.com wrote: Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 0x221152f8 in dlsym () from /usr/libexec/ld.so (gdb) bt full #0 0x221152f8 in dlsym () from /usr/libexec/ld.so No symbol table info available. #1 0x2214af94 in ?? () from /usr/libexec/ld.so No symbol table info available. #2 0x2214af94 in ?? () from /usr/libexec/ld.so No symbol table info available. Previous frame identical to this frame (corrupt stack?) [2] Very simple program that calls dlopen() $ ./so_loader $ echo $? 20 $ gdb so_loader GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-unknown-openbsd4.7... (gdb) break main Breakpoint 1 at 0x1800a64: file so_loader.c, line 35. (gdb) r Starting program: /home/sidster/src/so_loader Breakpoint 1, main (argc=1, argv=0xfffdd2c4) at so_loader.c:35 35 dh = dlopen(SOFILE, RTLD_NOW); (gdb) n Program exited with code 024. This problem was identified as a gcc4 problem, mis-compiling ld.so. The following commit fixes it. umm.. the problem remains. unless i misunderstood what was fixed. ff3.6.8 crashes as before and my test program still exits abnormally. Hmm.. interesting enough, at least my test program will randomly succeed every once in a while. I didn't try running it multiple times in a row before, so I don't know if this change is attributed to the commit you reference or not. --patrick Excellent news! I'll wait for my mirror of choice to pick up this change. Thanks for the update, --patrick Date: Sun, 1 Aug 2010 11:55:28 -0600 (MDT) From: Mark Kettenis kette...@cvs.openbsd.org To: source-chan...@cvs.openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2010/08/01 11:55:28 Modified files: gnu/gcc/gcc/config/rs6000: rs6000.c Log message: Make __builtin_return_address(0) work with -fstack-protector. Old diff from Jakub Jelinek that never made it into upstream GCC. Fixes ld.so. Found by drahn@ and me; ok miod@ -- Matthieu Herrb
Re: macppc: firefox 3.6.8 crashing (same as 3.6.7)
On Mon, Aug 2, 2010 at 7:24 AM, patrick keshishian pkesh...@gmail.com wrote: Hi, On Fri, Jul 30, 2010 at 5:49 AM, David Coppa dco...@gmail.com wrote: Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 0x221152f8 in dlsym () from /usr/libexec/ld.so (gdb) bt full #0 0x221152f8 in dlsym () from /usr/libexec/ld.so No symbol table info available. #1 0x2214af94 in ?? () from /usr/libexec/ld.so No symbol table info available. #2 0x2214af94 in ?? () from /usr/libexec/ld.so No symbol table info available. Previous frame identical to this frame (corrupt stack?) [2] Very simple program that calls dlopen() $ ./so_loader $ echo $? 20 $ gdb so_loader GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-unknown-openbsd4.7... (gdb) break main Breakpoint 1 at 0x1800a64: file so_loader.c, line 35. (gdb) r Starting program: /home/sidster/src/so_loader Breakpoint 1, main (argc=1, argv=0xfffdd2c4) at so_loader.c:35 35 dh = dlopen(SOFILE, RTLD_NOW); (gdb) n Program exited with code 024. This problem was identified as a gcc4 problem, mis-compiling ld.so. The following commit fixes it. Date: Sun, 1 Aug 2010 11:55:28 -0600 (MDT) From: Mark Kettenis kette...@cvs.openbsd.org To: source-chan...@cvs.openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2010/08/01 11:55:28 Modified files: gnu/gcc/gcc/config/rs6000: rs6000.c Log message: Make __builtin_return_address(0) work with -fstack-protector. Old diff from Jakub Jelinek that never made it into upstream GCC. Fixes ld.so. Found by drahn@ and me; ok miod@ -- Matthieu Herrb
Re: macppc: firefox 3.6.8 crashing (same as 3.6.7)
On Sun, Aug 1, 2010 at 11:12 PM, Matthieu Herrb mhe...@gmail.com wrote: On Mon, Aug 2, 2010 at 7:24 AM, patrick keshishian pkesh...@gmail.com wrote: Hi, On Fri, Jul 30, 2010 at 5:49 AM, David Coppa dco...@gmail.com wrote: Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 0x221152f8 in dlsym () from /usr/libexec/ld.so (gdb) bt full #0 0x221152f8 in dlsym () from /usr/libexec/ld.so No symbol table info available. #1 0x2214af94 in ?? () from /usr/libexec/ld.so No symbol table info available. #2 0x2214af94 in ?? () from /usr/libexec/ld.so No symbol table info available. Previous frame identical to this frame (corrupt stack?) [2] Very simple program that calls dlopen() $ ./so_loader $ echo $? 20 $ gdb so_loader GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-unknown-openbsd4.7... (gdb) break main Breakpoint 1 at 0x1800a64: file so_loader.c, line 35. (gdb) r Starting program: /home/sidster/src/so_loader Breakpoint 1, main (argc=1, argv=0xfffdd2c4) at so_loader.c:35 35 dh = dlopen(SOFILE, RTLD_NOW); (gdb) n Program exited with code 024. This problem was identified as a gcc4 problem, mis-compiling ld.so. The following commit fixes it. Excellent news! I'll wait for my mirror of choice to pick up this change. Thanks for the update, --patrick Date: Sun, 1 Aug 2010 11:55:28 -0600 (MDT) From: Mark Kettenis kette...@cvs.openbsd.org To: source-chan...@cvs.openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2010/08/01 11:55:28 Modified files: gnu/gcc/gcc/config/rs6000: rs6000.c Log message: Make __builtin_return_address(0) work with -fstack-protector. Old diff from Jakub Jelinek that never made it into upstream GCC. Fixes ld.so. Found by drahn@ and me; ok miod@ -- Matthieu Herrb
Re: macppc: firefox 3.6.8 crashing (same as 3.6.7)
Hi, On Fri, Jul 30, 2010 at 5:49 AM, David Coppa dco...@gmail.com wrote: On Fri, Jul 30, 2010 at 10:39 AM, patrick keshishian pkesh...@gmail.com wrote: On Thu, Jul 29, 2010 at 10:37 PM, patrick keshishian pkesh...@gmail.com wrote: On Wed, Jul 28, 2010 at 10:27 PM, David Coppa dco...@gmail.com wrote: On Thu, Jul 29, 2010 at 3:42 AM, patrick keshishian pkesh...@gmail.com wrote: FF 3.6.7 was crashing as reported by Dawe and me[1] same as X (from snapshots and built from source). Rebuilding xenocara from source with debug got X working (don't know why). I tried building FF 3.6.8 and it too is crashing with signal 11. I built FF 3.6.8 with DEBUG=-g -O0 hoping to at least get a backtrace out of the core, but evidently the resulting binary is stripped[2] (brilliant!). Question: I'm about to rebuild this monster again on my slow ibook. how do I prevent it from being stripped? Google finds me --disable-install-strip, but does our port infrastructure provide a more uniform way of handling this across all (or most) ports? DEBUG=-g -O0 INSTALL_STRIP= make clean repackage reinstall Thanks David! ughh.. it still ended up stripping firefox-bin. i don't know what else to try besides trying some hack like replacing system strip with true or something. I've crawled a little into mozilla-firefox source and its configure stuff... Just add --disable-install-strip to CONFIGURE_ARGS and go ahead: apparently there's no sane way to avoid stripping binaries using environment variables as we use to do. I actually had that in there just in case. I took a small break from this (hence the late reply -- just too frustrating). So it looks like the so-libs aren't stripped but fireforx-bin is. I found it's unstripped copy in dist/bin under pobj/mozilla-firefox-3.6.8/mozilla-1.9.2/. Running that version produces a core with not too useful of a backtrace [1]. This is looking too strange. So I wrote a tinsy program that loads a .so file just to see if the problem is a more system-wide one or not. The program when executed exists with status 20 [2]. Hmm... Same source on a i386 (4.7) box works as expected. dlopen() returns handle, dlsym() finds symbol, etc. Why the few other ports I build don't exhibit similar problems is also confusing. --patrick [1] $ ozilla-1.9.2/dist/bin/firefox-bin firefox-bin.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-unknown-openbsd4.7... Core was generated by `firefox-bin'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/mozilla-firefox/libxul.so.22.0...done. Loaded symbols for /usr/local/mozilla-firefox/libxul.so.22.0 Reading symbols from /usr/local/mozilla-firefox/libmozjs.so.22.0...done. Loaded symbols for /usr/local/mozilla-firefox/libmozjs.so.22.0 Reading symbols from /usr/local/mozilla-firefox/libxpcom.so.22.0...done. Loaded symbols for /usr/local/mozilla-firefox/libxpcom.so.22.0 Reading symbols from /usr/local/lib/libplds4.so.21.0...done. Loaded symbols for /usr/local/lib/libplds4.so.21.0 Reading symbols from /usr/local/lib/libplc4.so.21.0...done. Loaded symbols for /usr/local/lib/libplc4.so.21.0 Reading symbols from /usr/local/lib/libnspr4.so.21.0...done. Loaded symbols for /usr/local/lib/libnspr4.so.21.0 Reading symbols from /usr/local/lib/libgtk-x11-2.0.so.1403.0...done. Loaded symbols for /usr/local/lib/libgtk-x11-2.0.so.1403.0 Reading symbols from /usr/local/lib/libatk-1.0.so.2800.0...done. Loaded symbols for /usr/local/lib/libatk-1.0.so.2800.0 Reading symbols from /usr/local/lib/libgdk-x11-2.0.so.1403.0...done. Loaded symbols for /usr/local/lib/libgdk-x11-2.0.so.1403.0 Reading symbols from /usr/local/lib/libgdk_pixbuf-2.0.so.1403.0...done. Loaded symbols for /usr/local/lib/libgdk_pixbuf-2.0.so.1403.0 Reading symbols from /usr/local/lib/libpangocairo-1.0.so.1802.0...done. Loaded symbols for /usr/local/lib/libpangocairo-1.0.so.1802.0 Reading symbols from /usr/local/lib/libpangoft2-1.0.so.1802.0...done. Loaded symbols for /usr/local/lib/libpangoft2-1.0.so.1802.0 Reading symbols from /usr/local/lib/libpango-1.0.so.1802.0...done. Loaded symbols for /usr/local/lib/libpango-1.0.so.1802.0 Reading symbols from /usr/local/lib/libgio-2.0.so.1803.0...done. Loaded symbols for /usr/local/lib/libgio-2.0.so.1803.0 Reading symbols from /usr/local/lib/libgobject-2.0.so.1803.0...done. Loaded symbols for /usr/local/lib/libgobject-2.0.so.1803.0 Reading symbols from /usr/local/lib/libgthread-2.0.so.1803.0...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.1803.0 Reading symbols from /usr/local/lib/libgmodule-2.0.so.1803.0...done. Loaded symbols for /usr/local/lib/libgmodule-2.0.so.1803.0
Re: macppc: firefox 3.6.8 crashing (same as 3.6.7)
On Thu, Jul 29, 2010 at 10:37 PM, patrick keshishian pkesh...@gmail.com wrote: On Wed, Jul 28, 2010 at 10:27 PM, David Coppa dco...@gmail.com wrote: On Thu, Jul 29, 2010 at 3:42 AM, patrick keshishian pkesh...@gmail.com wrote: FF 3.6.7 was crashing as reported by Dawe and me[1] same as X (from snapshots and built from source). Rebuilding xenocara from source with debug got X working (don't know why). I tried building FF 3.6.8 and it too is crashing with signal 11. I built FF 3.6.8 with DEBUG=-g -O0 hoping to at least get a backtrace out of the core, but evidently the resulting binary is stripped[2] (brilliant!). Question: I'm about to rebuild this monster again on my slow ibook. how do I prevent it from being stripped? Google finds me --disable-install-strip, but does our port infrastructure provide a more uniform way of handling this across all (or most) ports? DEBUG=-g -O0 INSTALL_STRIP= make clean repackage reinstall Thanks David! ughh.. it still ended up stripping firefox-bin. i don't know what else to try besides trying some hack like replacing system strip with true or something. --patrick
Re: macppc: firefox 3.6.8 crashing (same as 3.6.7)
On Fri, Jul 30, 2010 at 10:39 AM, patrick keshishian pkesh...@gmail.com wrote: On Thu, Jul 29, 2010 at 10:37 PM, patrick keshishian pkesh...@gmail.com wrote: On Wed, Jul 28, 2010 at 10:27 PM, David Coppa dco...@gmail.com wrote: On Thu, Jul 29, 2010 at 3:42 AM, patrick keshishian pkesh...@gmail.com wrote: FF 3.6.7 was crashing as reported by Dawe and me[1] same as X (from snapshots and built from source). Rebuilding xenocara from source with debug got X working (don't know why). I tried building FF 3.6.8 and it too is crashing with signal 11. I built FF 3.6.8 with DEBUG=-g -O0 hoping to at least get a backtrace out of the core, but evidently the resulting binary is stripped[2] (brilliant!). Question: I'm about to rebuild this monster again on my slow ibook. how do I prevent it from being stripped? Google finds me --disable-install-strip, but does our port infrastructure provide a more uniform way of handling this across all (or most) ports? DEBUG=-g -O0 INSTALL_STRIP= make clean repackage reinstall Thanks David! ughh.. it still ended up stripping firefox-bin. i don't know what else to try besides trying some hack like replacing system strip with true or something. I've crawled a little into mozilla-firefox source and its configure stuff... Just add --disable-install-strip to CONFIGURE_ARGS and go ahead: apparently there's no sane way to avoid stripping binaries using environment variables as we use to do. ciao, david
macppc: firefox 3.6.8 crashing (same as 3.6.7)
FF 3.6.7 was crashing as reported by Dawe and me[1] same as X (from snapshots and built from source). Rebuilding xenocara from source with debug got X working (don't know why). I tried building FF 3.6.8 and it too is crashing with signal 11. I built FF 3.6.8 with DEBUG=-g -O0 hoping to at least get a backtrace out of the core, but evidently the resulting binary is stripped[2] (brilliant!). Question: I'm about to rebuild this monster again on my slow ibook. how do I prevent it from being stripped? Google finds me --disable-install-strip, but does our port infrastructure provide a more uniform way of handling this across all (or most) ports? Also, what's the idea behind 'make repackage' deleting every dependency package from /usr/ports/packages/ directory? This seems quite insane, especially when those packages aren't rebuilt (although, the latter is besides the point)? I don't know how to express my frustration over this, when the dependency packages (python, gtk+, etc. etc.) took 6+ hours to build and now they are fucking gone. --patrick [1] http://marc.info/?l=openbsd-miscm=128002243807124w=2 [2] $ gdb /usr/local/mozilla-firefox/firefox-bin firefox-bin.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-unknown-openbsd4.7... (no debugging symbols found) Core was generated by `firefox-bin'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/mozilla-firefox/libxul.so.22.0...done. Loaded symbols for /usr/local/mozilla-firefox/libxul.so.22.0 Reading symbols from /usr/local/mozilla-firefox/libmozjs.so.22.0...done. Loaded symbols for /usr/local/mozilla-firefox/libmozjs.so.22.0 Reading symbols from /usr/local/mozilla-firefox/libxpcom.so.22.0...done. Loaded symbols for /usr/local/mozilla-firefox/libxpcom.so.22.0 Reading symbols from /usr/local/lib/libplds4.so.21.0...done. Loaded symbols for /usr/local/lib/libplds4.so.21.0 Reading symbols from /usr/local/lib/libplc4.so.21.0...done. Loaded symbols for /usr/local/lib/libplc4.so.21.0 Reading symbols from /usr/local/lib/libnspr4.so.21.0...done. Loaded symbols for /usr/local/lib/libnspr4.so.21.0 Reading symbols from /usr/local/lib/libgtk-x11-2.0.so.1403.0...done. Loaded symbols for /usr/local/lib/libgtk-x11-2.0.so.1403.0 Reading symbols from /usr/local/lib/libatk-1.0.so.2800.0...done. Loaded symbols for /usr/local/lib/libatk-1.0.so.2800.0 Reading symbols from /usr/local/lib/libgdk-x11-2.0.so.1403.0...done. Loaded symbols for /usr/local/lib/libgdk-x11-2.0.so.1403.0 Reading symbols from /usr/local/lib/libgdk_pixbuf-2.0.so.1403.0...done. Loaded symbols for /usr/local/lib/libgdk_pixbuf-2.0.so.1403.0 Reading symbols from /usr/local/lib/libpangocairo-1.0.so.1802.0...done. Loaded symbols for /usr/local/lib/libpangocairo-1.0.so.1802.0 Reading symbols from /usr/local/lib/libpangoft2-1.0.so.1802.0...done. Loaded symbols for /usr/local/lib/libpangoft2-1.0.so.1802.0 Reading symbols from /usr/local/lib/libpango-1.0.so.1802.0...done. Loaded symbols for /usr/local/lib/libpango-1.0.so.1802.0 Reading symbols from /usr/local/lib/libgio-2.0.so.1803.0...done. Loaded symbols for /usr/local/lib/libgio-2.0.so.1803.0 Reading symbols from /usr/local/lib/libgobject-2.0.so.1803.0...done. Loaded symbols for /usr/local/lib/libgobject-2.0.so.1803.0 Reading symbols from /usr/local/lib/libgthread-2.0.so.1803.0...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.1803.0 Reading symbols from /usr/local/lib/libgmodule-2.0.so.1803.0...done. Loaded symbols for /usr/local/lib/libgmodule-2.0.so.1803.0 Reading symbols from /usr/local/lib/libglib-2.0.so.1803.0...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.1803.0 Reading symbols from /usr/local/lib/libintl.so.5.0...done. Loaded symbols for /usr/local/lib/libintl.so.5.0 Reading symbols from /usr/local/lib/libiconv.so.6.0...done. Loaded symbols for /usr/local/lib/libiconv.so.6.0 Reading symbols from /usr/X11R6/lib/libXinerama.so.5.0...done. Loaded symbols for /usr/X11R6/lib/libXinerama.so.5.0 Reading symbols from /usr/X11R6/lib/libXi.so.11.0...done. Loaded symbols for /usr/X11R6/lib/libXi.so.11.0 Reading symbols from /usr/X11R6/lib/libXrandr.so.6.1...done. Loaded symbols for /usr/X11R6/lib/libXrandr.so.6.1 Reading symbols from /usr/X11R6/lib/libXcursor.so.4.0...done. Loaded symbols for /usr/X11R6/lib/libXcursor.so.4.0 Reading symbols from /usr/X11R6/lib/libXcomposite.so.3.0...done. Loaded symbols for /usr/X11R6/lib/libXcomposite.so.3.0 Reading symbols from /usr/X11R6/lib/libXext.so.11.0...done. Loaded symbols for /usr/X11R6/lib/libXext.so.11.0 Reading symbols from /usr/X11R6/lib/libXdamage.so.3.1...done. Loaded symbols for /usr/X11R6/lib/libXdamage.so.3.1 Reading symbols from
Re: macppc: firefox 3.6.8 crashing (same as 3.6.7)
On Thu, Jul 29, 2010 at 3:42 AM, patrick keshishian pkesh...@gmail.com wrote: FF 3.6.7 was crashing as reported by Dawe and me[1] same as X (from snapshots and built from source). Rebuilding xenocara from source with debug got X working (don't know why). I tried building FF 3.6.8 and it too is crashing with signal 11. I built FF 3.6.8 with DEBUG=-g -O0 hoping to at least get a backtrace out of the core, but evidently the resulting binary is stripped[2] (brilliant!). Question: I'm about to rebuild this monster again on my slow ibook. how do I prevent it from being stripped? Google finds me --disable-install-strip, but does our port infrastructure provide a more uniform way of handling this across all (or most) ports? DEBUG=-g -O0 INSTALL_STRIP= make clean repackage reinstall Ciao, David
