Zsh Mailing List Archive
Messages sorted by:
Cygwin: environ problem
- X-seq: zsh-workers 12338
- From: "Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>
- To: "ZSH workers mailing list" <zsh-workers@xxxxxxxxxxxxxx>
- Subject: Cygwin: environ problem
- Date: Fri, 21 Jul 2000 15:56:45 +0400
- Importance: Normal
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Tests for dynamic loading choke almost immediately. The reason is static
libc and environ variable. It is contained in libc.a that is statically
linked so every DLL gets it's own copy.
BUT it looks, that exactly in case of Cygwin this test does not matter.
If I understand correctly, what happens:
- every DLL has control block, that contains pointer to "environ" for
this DLL; this is of type 'char ***' intialised to point to "extern char
**environ", that is a local varible: "user_data->envp = &environ".
- main program has __cygwin_environ that points to actual "true"
- every time environment changes (via setenv()/putnev()) and, of course,
when loading DLL, cygwin updates local environ to point to
__cygwin_environ, like "*(user_data->envp) = __cygwin_environ"
In other words, every copy of environ is forced to point to the same
location, even if addresses of variables itself are different.
This implies that direct manipulation of environ is not possible (or,
better said, make no sense). Zsh does exactly this - it directly assigns
pointer to new environment block in createparamtable(). This needs to be
fixed for Cygwin.
It just occured to me, that it may be one reason for these misterious
cores on Cygwin.
It looks, like libc.a is actually nothing more than stub library for
cygwin.dll. That is, we can ignore the above test on Cygwin.
We _could_try_ to directly manipulate __cygwin_environ, but I do not
like it - who knows, where and how it is used. BTW comments imply, that
DLLs should actually refer to __cygwin_environ :-)
Have a nice DOS!
Messages sorted by: