From: crvich AT raleigh DOT ibm DOT com Subject: environ defined twice 29 Apr 1997 10:52:13 -0700 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <9704291336.AA28022.cygnus.gnu-win32@ode1.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Original-To: gnu-win32 AT cygnus DOT com X-Mailer: ELM [version 2.4 PL22] Original-Sender: owner-gnu-win32 AT cygnus DOT com Version: beta 17.1 Platform: WinNT 4.00.1381 Not sure if this has already been discussed (I searched the archives, which only run through Dec 22, to no avail), but I've found that environ is defined in both libc.a (environ.c) and libcygwin.a (libccrt0.cc). This causes confusing results, since the stdlib.h functions (setenv, putenv, getenv) seem to be using "their" version, while a browse through environ directly by my program uses the "other" version. Both versions are initially the same, but once you begin modifying environ (with either the stdlib.h functions or directly yourself), their uniqueness becomes apparent. My main concern is the way fork() and exec() behave (I'm invariably invoking a shell, "cmd" for now), since they cause different versions of environ to be visible to an invoked program...exec() by itself causes the "other" version (the one that was altered manually) to be seen by the invoked program, while fork() allows a subsequent exec() to see the stdlib.h version. I assume an "extern" was forgotten in the libccrt0.cc declaration, correct? Any simple fix in the meantime, aside from changing libccrt0.cc myself and trying to update cygwin.dll? - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".