3554 - Unix: MOZILLA_HOME needs to get yanked out of nspr

Status: VERIFIED DUPLICATE of bug 4450

(NSPR :: NSPR, defect, P1)

Description

[Chris McAfee]

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

Comment 1

[leger]

Putting on M3 radar.

Comment 2

[Suresh Duddi (gone)]

I was thinking of using MOZILLA5_HOME

Ramiro, Mcafee, Do you both prefer MOZILLA_FIVE_HOME

Comment 3

[ramiro]

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

Comment 4

[Chris McAfee]

MOZILLA_5_HOME ?  I agree with ramiro about the misreading of MOZILLA5

Comment 5

[Suresh Duddi (gone)]

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

Comment 6

[Suresh Duddi (gone)]

Using MOZILLA_FIVE_HOME now.

Comment 7

[leger]

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

Comment 8

[Chris McAfee]

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?

Comment 9

[Suresh Duddi (gone)]

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

Comment 10

[Chris 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.

Comment 11

[Wan-Teh Chang]

(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.

Comment 12

[srinivas]

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.

Comment 13

[Chris McAfee]

Are any non-mozilla products using MOZILLA_HOME?  Server?

Comment 14

[Chris McAfee]

Are any non-mozilla products using MOZILLA_HOME?  Server?

Comment 15

[Wan-Teh Chang]

No, servers don't use MOZILLA_HOME.

Comment 16

[ramiro]

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 ?

Comment 17

[Peter Trudelle]

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

Comment 18

[ramiro]

its not.  marking m4.

Comment 19

[Peter Trudelle]

moving to m5

Comment 20

[Chris McAfee]

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 ***

Comment 21

[phillip]

verified.

Comment 22

[Terry Weissman]

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