Benjamin Smedberg wrote:
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.
It's reasonable to ASSume that the LD_LIBRARY_PATH would include the path to the components, and its parent directory. It would be relatively easy to do something like:
1. Find the gre you want via the usual methods 2. Set the LD_LIBRARY_PATH to the component dir and its parent 3. Spawn regxpcom
go, go, go.
Of course, as I mentioned in another post, this doesn't help at all with installations that are system-wide and the user doesn't have access to.
--Chris
-- ------------ Christopher Blizzard http://www.mozilla.org ------------
_______________________________________________ Mozilla-xpcom mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-xpcom
