Doug,
Chris and I talked at some length on IRC, and came up with a possible solution to this problem. Keeping the dependent libs code as it is; when NS_InitXPCOM2() needs to do autoregistration, instead of doing it directly, it sets up the LD_LIBRARY_PATH environment properly and calls "regxpcom" as a child process. This breaks the catch-22 and probably breaks the need for the startup shell scripts as well.
Where does the application get the LD_LIBRARY_PATH in the first place?
If you use XPCOMGlueStartup instead of NS_InitXPCOM2, we do properly set LD_LIBRARY_PATH.
Of course, win32 does not have this issue and I would like to suggest that we #ifdef the dependent-libs code so that it is only built on the platforms with *nixlike soloaders that don't dynamically respond to the environment.
win32 does have this problem also. You can imagine some person installing the GRE or part of it in a bad location, like system32. It is a known configure to install nspr and nss into system32.
Doug Turner
_______________________________________________ Mozilla-xpcom mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-xpcom
