324169 - Allow configuration to specify global USE_STATIC_LIBS

Status: RESOLVED INCOMPLETE

(Firefox Build System :: General, defect, P3)

Description

[Benjamin Smedberg]

I'm trying to a mozilla built linking statically against the C runtime (windows). You can do this for mozilla by specifying USE_STATIC_LIBS on the make command line, but it is not saved by configure.

NSPR hardcodes use of -MD... I'll post a patch that makes NSPR honor USE_STATIC_LIBS as well to switch -MD or -MT.

Comment 1

[Benjamin Smedberg]

Attachment: Make NSPR configure honor USE_STATIC_LIBS

wtc, I'm aiming this at mozilla trunk/NSPR client branch, it does not need to make any of the 1.8 branches.

Comment 2

[Benjamin Smedberg]

Attachment: Make Mozilla configure remember USE_STATIC_LIBS, rev. 1

Comment 3

[Wan-Teh Chang]

Comment on attachment 209128 [details] [diff] [review]
Make NSPR configure honor USE_STATIC_LIBS

Ben, please explain why you want to link with
the static MSVC runtime library globally.

While this is fine for libc functions such as
strlen, strcmp, and memset that don't have "state",
this is risky for libc functions such as malloc/free
and getenv/putenv that have state.  Each DLL or
EXE that links with the static MSVC runtime library
will have its own copy of the state:

  For malloc/free, the state is the heap.
  For getenv/putenv, the state is the POSIX environment
  variables, which are initialized with the values of
  the Win32 environment variables but will deviate from
  then on.

So, a Mozilla DLL that calls PR_Malloc() to allocate
memory and calls free() to free the memory, currently
works, but will fail because the memory is allocated
from NSPR's heap but returned to the DLL's heap.
Similar problem with a Mozilla DLL that calls PR_SetEnv()
to set an environment variable and calls getenv() to
read it.  Both of the above can be considered sloppy
code or programming errors, but it is a lot of work
to find and fix them.

(I'd prefer a configure option named --enable-static-rtl,
to follow the pattern of the existing --enable-debug-rtl
configure option, but I'm not sure if this patch is a good
idea.)

Comment 4

[Benjamin Smedberg]

> Ben, please explain why you want to link with
> the static MSVC runtime library globally.

For the moment we're considering this an experiment: we're going to be switching to MSVC8 from MSVC6: we'd like to avoid needing to redistribute the MSVC8 runtime DLLs if practical because it makes certain installation tasks very difficult (in particular installing Firefox as a non-Administrator user on pre-winXP systems).

>   For malloc/free, the state is the heap.

We have standard allocators PR_malloc and NS_Malloc and are pretty good right now about using matched allocators (and matching C++ new/delete and new[] delete[]). Any mismatched allocators will need to be fixed.

>   For getenv/putenv, the state is the POSIX environment
>   variables, which are initialized with the values of
>   the Win32 environment variables but will deviate from
>   then on.

This is more troublesome, and I need to do some investigation: I'm pretty sure that putenv saves state back into the windows environment, but it isn't shared with the other C runtimes. The possible solutions include always using the PR_*env variants and auditing our code to use the windows environment variable functions directly.

There is an additional problem you didn't mention, which is that you can't pass FILE* across module boundaries when statically linking the C runtime.

But I'd like to go ahead and add this configure option (--enable-static-rtl if you like, I'll need to change the mozilla/configure to match) for experimentation purposes.

> Similar problem with a Mozilla DLL that calls PR_SetEnv()
> to set an environment variable and calls getenv() to
> read it.  Both of the above can be considered sloppy
> code or programming errors, but it is a lot of work
> to find and fix them.
> 
> (I'd prefer a configure option named --enable-static-rtl,
> to follow the pattern of the existing --enable-debug-rtl
> configure option, but I'm not sure if this patch is a good
> idea.)
> 

Comment 5

[Chris Cooper [:coop] (he/him)]

Mass bug cleanup for Core:Build Config.

If you feel this bug has been closed in error, please re-open with new details.