Doug Turner wrote: >> B. Smedberg wrote
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
Where does the application get the LD_LIBRARY_PATH in the first place?
I'm not sure about the question, but right now LD_LIBRARY_PATH is set in run-mozilla.sh to include the application directory... is this what you're asking?
If you use XPCOMGlueStartup instead of NS_InitXPCOM2, we do properly set LD_LIBRARY_PATH.
right. On *nix it's not honored when loading SOs in the current process, only child processes.
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.
I didn't realize we were trying to solve this issue as well. I take it back... ;)
--BDS
_______________________________________________ Mozilla-xpcom mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-xpcom
