Created attachment 284763 [details] emerge--info.txt This is a fun bug. I had this exact same bug with seamonkey-2.2 but I couldn't debug it (and I upgraded to 2.3.1 in the process of trying to fix it, but that doesn't matter as 2.2 is not in the tree anymore). My installation of seamonkey-2.3.1 has the following in /usr/lib/seamonkey: anna@delldesky ~ $ LANG=C ls -l /usr/lib/seamonkey total 28189 -rw-r--r-- 1 root root 4773 Aug 23 14:59 README -rw-r--r-- 1 root root 825 Aug 23 14:59 Throbber-small.gif -rw-r--r-- 1 root root 1988 Aug 23 14:59 application.ini -rw-r--r-- 1 root root 3956 Aug 23 14:59 blocklist.xml drwxr-xr-x 3 root root 432 Aug 23 15:09 chrome -rw-r--r-- 1 root root 153 Aug 23 15:01 chrome.manifest drwxr-xr-x 2 root root 3296 Aug 23 15:09 components -rwxr-xr-x 1 root root 92208 Aug 23 15:08 crashreporter -rw-r--r-- 1 root root 587 Aug 23 14:59 crashreporter-override.ini -rw-r--r-- 1 root root 3803 Aug 23 14:59 crashreporter.ini drwxr-xr-x 6 root root 160 Aug 14 2010 defaults -rw-r--r-- 1 root root 125 Aug 23 14:58 dependentlibs.list drwxr-xr-x 7 root root 320 Aug 15 01:32 extensions -rw-r--r-- 1 root root 86613 Aug 23 14:59 greprefs.js drwxr-xr-x 2 root root 168 Aug 23 15:09 isp -rwxr-xr-x 1 root root 199196 Aug 23 15:08 libldap60.so -rwxr-xr-x 1 root root 9460 Aug 23 15:08 libldif60.so -rwxr-xr-x 1 root root 9484 Aug 23 15:08 libmozalloc.so -rwxr-xr-x 1 root root 17864 Aug 23 15:08 libprldap60.so -rwxr-xr-x 1 root root 17828 Aug 23 15:08 libxpcom.so -rwxr-xr-x 1 root root 28165612 Aug 23 15:08 libxul.so -rwxr-xr-x 1 root root 30826 Aug 23 14:59 license.txt drwxr-xr-x 5 root root 2056 Aug 23 15:09 modules -rwxr-xr-x 1 root root 13928 Aug 23 15:08 mozilla-xremote-client -rw-r--r-- 1 root root 45 Aug 23 14:59 platform.ini -rwxr-xr-x 1 root root 42524 Aug 23 15:08 plugin-container lrwxrwxrwx 1 root root 20 Aug 23 15:10 plugins -> ../nsbrowser/plugins -rw-r--r-- 1 root root 11225 Aug 23 14:57 removed-files drwxr-xr-x 6 root root 1256 Aug 23 15:09 res -rwxr-xr-x 1 root root 10380 Aug 23 14:59 run-mozilla.sh -rwxr-xr-x 1 root root 3908 Aug 23 14:59 seamonkey -rwxr-xr-x 1 root root 46704 Aug 23 15:08 seamonkey-bin drwxr-xr-x 2 root root 184 Aug 23 15:09 searchplugins anna@delldesky ~ $ The segfault goes away when I add the one following file: lrwxrwxrwx 1 root root 9 Aug 26 23:22 libblah.so -> /dev/null I am also very sure that the segfault will go away if I uninstall xulrunner. The symbolic link hack can be found by reading /usr/lib/moz-runner.sh and searching for '[ -h'. The problem is that moz-runner.sh doesn't extend LD_LIBRARY_PATH by default unless if a symbolic link with a name ending in '.so' exists in /usr/lib/seamonkey. I have net-libs/xulrunner-1.9.2.17 installed which must be old and ABI-incompatible with seamonkey-2.3.1. Seamonkey wasn't even compiled against the system xulrunner though, it compiles, ships, and installs its own. So, so solve this, seamonkey must be trained to unconditionally link against its own xulrunner or fixed to actually compile against the system xulrunner (and then deal with DEPENDing against a proper xulrunner version). See the attached seamonkey-ldd-output.txt for more information. The culprit libraries installed by both seamonkey and xulrunner are libxul.so and libxpcom.so. net-libs/xulrunner-1.9.2.17 appends /usr/lib/xulrunner-1.9.2 to the linker paths by installing /etc/env.d/08xulrunner with the contents 'LDPATH=//usr/lib/xulrunner-1.9.2'. All in all, it would be nice for seamonkey to support an external xulrunner so that its own compilation time would be shorter... but I suspect supporting that would be very difficult.
Created attachment 284765 [details] seamonkey-ldd-output.txt
Created attachment 284767 [details] gdb-output.txt
Oh, and using the system libxul may be a bad idea since mozilla sets SONAME to just `libxul.so', preventing ABI-incompatible changes to the library from being glossed over by preserved-libs or detected by revdep-rebuild AFAIK.
Thank you very much Nathan for your bug report and your very detailed description. This is not a problem of seamonkey alone. All mozilla apps I have installed are affected, maybe even more (I didn't test thunderbird for example). As Nathan pointed out the culprit seems to be /etc/env.d/08xulrunner. As soon as I remove that file and refresh my environment, the wrong linking is gone for all apps. So mozilla team, what should we do here? I see this as a really big regression and would like to have this resolved rather sooner than later.
Nathan, nirbheek pointed out that moz_should_set_ld_library_path() from /usr/lib64/seamonkey/run-mozilla.sh returns 0 for all systems except SunOS. The return value 0 in bash means true so the following if statement comes into effect and LD_LIBRARY_PATH is set. I wonder if there's something else wrong on your system.
OK, so I created this bug based on circumstantial evidence. While trying different ways to start seamonkey, I randomly noticed that nscd wasn't running and started it. When nscd is running seamonkey works, when nscd isn't seamonkey fails to start by some sort of segfault for me (I'm running nss_ldap). So, this bug is invalid. If I figure out why the segfault happens when nscd isn't running I'll open a separate bug.
