dlls/kernel/process.c breakage due to environ

[Gerald Pfeifer]

My nightly autobuilder failed to build today, after I've had no
problems for several days.  This seems to be due to yesterday's
changes in dlls/kernel:

process.o: In function `build_initial_environment':
  wine/dlls/kernel/process.c:341: undefined reference to `environ'
  wine/dlls/kernel/process.c:357: undefined reference to `environ'
  process.o: In function `build_envp':
  wine/dlls/kernel/process.c:1018: undefined reference to `environ'
  gmake[2]: *** [kernel32.dll.so] Error 1

Part of the fix is the patch below, but this is not sufficient, as
environ simply is non-standard.  On my SuSE 8.2 box, for example,
/usr/include/unistd.h says:

#ifdef __USE_GNU
  extern char **environ;
  #endif

In other words, on GNU/Linux you are just lucky because even if the
symbol is not declared (which is why you need the extern declaration)
it is in the library.

Gerald

ChangeLog:
Declare environ at the top, not inside functions.

Index: process.c
===================================================================
RCS file: /home/wine/wine/dlls/kernel/process.c,v
retrieving revision 1.24
diff -u -3 -p -r1.24 process.c
--- process.c	10 Oct 2003 00:12:17 -0000	1.24
+++ process.c	10 Oct 2003 08:11:52 -0000
@@ -73,6 +73,8 @@ extern void SHELL_LoadRegistry(void);
 extern void VERSION_Init( const WCHAR *appname );
 extern void MODULE_InitLoadPath(void);

+extern char **environ;
+
 /***********************************************************************
  *           contains_path
  */
@@ -331,7 +333,6 @@ static HMODULE load_pe_exe( const WCHAR
  */
 static BOOL build_initial_environment(void)
 {
-    extern char **environ;
     ULONG size = 1;
     char **e;
     WCHAR *p, *endptr;
@@ -1007,7 +1008,6 @@ static char **build_envp( const WCHAR *e

if ((envp = malloc( count * sizeof(*envp) )))
     {
-        extern char **environ;
         char **envptr = envp;
         char **unixptr = environ;
         char *p;

[Alexandre Julliard]

Gerald Pfeifer  writes:
> ChangeLog:
> Declare environ at the top, not inside functions.

I must be missing something here. Why does this make a difference?

[Gerald Pfeifer]

On Fri, 10 Oct 2003, Alexandre Julliard wrote:
> > Declare environ at the top, not inside functions.
>
> I must be missing something here. Why does this make a difference?

I don't remember chapter and verse of the standards, but this came up
some time ago on the GCC mailing lists (though, in hindsight, it might
have been for C++, I'm not sure).

Depending on how you plan to fix the compilation failure, it might make
sense to have just one declaration at the top instead of several (and
thus several #ifdef's, in case they are needed for the fix) in functions?

Gerald

[Alexandre Julliard]

Gerald Pfeifer  writes:
> Depending on how you plan to fix the compilation failure, it might make
> sense to have just one declaration at the top instead of several (and
> thus several #ifdef's, in case they are needed for the fix) in functions?

Well, maybe, but we can only tell once we know what is required to fix
the problem. My question was whether simply moving the declaration
fixed it for you, but I'd be very surprised if it did.

[Gerald Pfeifer]

On Fri, 10 Oct 2003, Alexandre Julliard wrote:
> > Depending on how you plan to fix the compilation failure, it might make
> > sense to have just one declaration at the top instead of several (and
> > thus several #ifdef's, in case they are needed for the fix) in functions?
>
> Well, maybe, but we can only tell once we know what is required to fix
> the problem. My question was whether simply moving the declaration
> fixed it for you, but I'd be very surprised if it did.

You are right, this did not really fix the problem.

A real fix might require adding a global variable and initializing that
from the third parameter of main, i.e., changing main to

int main( int argc, char *argv[], char **environ )

Gerald