MOZILLA_HOME is conflicting with Netscape 4.5. Dp & ramiro suggest moving to a new variable, MOZILLA_FIVE_HOME.

Putting on M3 radar.

I was thinking of using MOZILLA5_HOME Ramiro, Mcafee, Do you both prefer MOZILLA_FIVE_HOME

As I typed MOZILLA5 i noticed it looks a lot like MOZILLAS (S instead of 5) MOZILLA_FIVE_HOME is very obvious and i think will work better. I think the extra chars are worth the fact is obvious we are talking about MOZILLA FIVE. dp, are you ready to make this change ? Go for it if you are and ill post an announcement if you want. -re

MOZILLA_5_HOME ? I agree with ramiro about the misreading of MOZILLA5

I will do component loading from MOZILLA_FIVE_HOME and then if that failed ./components Then ramiro will do some more for other parts of the app. I will reassign to ramiro once I am done

Using MOZILLA_FIVE_HOME now.

mcafee, can you mark this Verified now? All cool?

Reopening, there is still one occurance of MOZILLA_HOME in nspr, http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/src/linking/prlink.c#331 Wan-Teh, can we include a test for MOZILLA_FIVE_HOME in front of MOZILLA_HOME here?

My part of components directory using MOZILLA_FIVE_HOME is done. hence I am forwarding bug to err... mcafee

Wan-Teh, I'm assigning this to you so you can take a look at this. We've recently switched from MOZILLA_HOME to MOZILLA_FIVE_HOME, for all Unix versions for 5.0. I believe we need to check for this variable ahead of MOZILLA_HOME in prlink.c.

(NSPR bugs should be assigned to the module owner Srinivas.) I think we should not make the change to prlink.c that you suggested. NSPR should not check MOZILLA_HOME or MOZILLA_FIVE_HOME. These are environment variables used only by specific products. I would even remove the existing check for MOZILLA_HOME from prlink.c. Instead, an NSPR client should use PR_GetLibraryPath() and PR_SetLibraryPath() to add the directories it's interested in to the dynamic library search path.

NSPR is a general purpose runtime library and shouldn't process product-specific environment variables. The current reference to MOZILLA_HOME in nspr should be removed. This can be done when the relevant changes (i.e. explicitly set the library path) are made in the mozilla code. I am reassigning this bug mcafee.

Are any non-mozilla products using MOZILLA_HOME? Server?

Are any non-mozilla products using MOZILLA_HOME? Server?

No, servers don't use MOZILLA_HOME.

I agree with wtc and srinivas. I suggest you comment out this code in NSPR. And when the client breaks, we will fix it. I still dont know what in 4.x needed that code in NSPR. Anyone know ?

Is this really a showstopper for M3? If it can wait til m4, please re-target.

its not. marking m4.

moving to m5

I think this is a dup of 4450: http://bugzilla.mozilla.org/show_bug.cgi?id=4450 *** This bug has been marked as a duplicate of 4450 ***

verified.

NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.