dlls/kernel/process.c breakage due to environ
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;
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
Gerald Pfeifer <gerald(a)pfeifer.com> 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. -- Alexandre Julliard julliard(a)winehq.com
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 -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/
participants (3)
-
Alexandre Julliard -
Gerald Pfeifer -
Gerald Pfeifer