On Jun 18 11:24, Corinna Vinschen wrote:
On Jun 17 14:07, Jeff Johnston wrote:
While I have no problem in backing off the change for the moment to keep
Cygwin up and running, I would like to see further investigation as to why
Cygwin depends on _GLOBAL_REENT changing in tandem with _REENT
(_impure_ptr). It might indicate a missing usage of _GLOBAL_REENT in
newlib or a logic flaw in Cygwin.
Thanks for backing this out for now. Unfortunately I can't tell for sure
so far what the exact problem is. I tried several changes already but
to no avail. Unfortunately I don't have experience with the impure_ptr
stuff so I'm a bit shooting in the dark here. I'll send a heads up to
cygwin-developers list.
I have investigated further, triggered by the recent reent problem
and I found why the change to use _global_impure_ptr broke Cygwin.
The reason is that Cygwin never used the impure_data structure and the
original _impure_ptr value provided by newlib, but instead it maintains
its own global struct reent called `reent_data'. Therefore, all
usages of GLOBAL_REENT inside of newlib pointed to the wrong data structure.
I have a local patch to Cygwin, which allows to revert the definition
of _GLOBAL_REENT to _global_impure_ptr. The patch removes reent_data
entirely and let Cygwin use the data structures provided by newlib's
impure.c.
Unfortunately, there's a problem left. reent_data has been exported by
the Cygwin DLL and unfortunately there are apps and libraries out there
which make use of that datastructure, namely libitcl32.a. That's a pain,
but since backward compatibility is an important factor, we can't just
get rid of the reent_data export.
So I'd like to suggest the following change to newlib. It aliasses reent_data
to be the same as impure_data and so allows to further export that symbol,
and it reverts _GLOBAL_REENT to _global_impure_ptr.