Mail Archives: cygwin/2005/10/25/00:57:33
Satish Balay wrote:
> Ok so the problem is likely to go away for python users.
I don't know if Jason has started compiling Python with
--enable-auto-image-base or not. It will also depend on the maintainers
of any libraries that are dynamically loaded by a python module using
the flag as well.
> Currently the burden is on [cygwin] users to know/keep track of this
> info. And not all instructions/documetation get read by users. So each
> time there is such a breakage, cygwin get a bad repo [why doesn't it
> just work?]
>
> So I hope cygwin can improve on this. Users seeing "Unable to remap"
> errors [however infrequently] should be avoided - esp if it can be
> automated.
This is true. It is a rather bad situation. It is mitigated by the
fact that it only affects certain packages used in certain
circumstances. Cygwin is also somewhat aimed at users that are familiar
with reading documentation, and this problem is documented in
/usr/share/doc/cygwin/python-*.README.
> [maybe the fix is: for any package that is likely to break - add a
> flag - which triggers setup to run rebaseall - after
> install/upgrade. So no overhead for pacakges that don't break - but
> always overhead for packages that break.]
It's not that simple. The --enable-auto-image-base feature is, in
theory, the correct way to fix this problem. This option has been
traditionally been disabled by default, for reasons I'm not familiar
with. At some time in the past I think it had some problems. And I
seem to recall that it can still cause conflicts in certain
circumstances because Cygwin uses a small amount of memory past the end
of the DLL for record-keeping purposes, which the rebaseall script
accomodates by adding padding.
Automatically running rebaseall from setup.exe has issues too. For one
thing, it would run into problems if the user had programs or services
running. The rebaseall script bails if it cannot write to a DLL, so
unless the user was very careful to close all running programs, it would
fail in almost all cases. Rebaseall would have to be modified to rebase
in-use DLLs, but this would require the user to reboot. And, somehow
this would have to be communicated to setup.exe so it could notify the
user. Plus, consider if setup.exe installed a DLL that was in use
(writing it to name.dll.new, and scheduling that for replacement at next
boot) and then rebaseall was run. The rebaseall script would have to
know to rebase name.dll.new and not name.dll. It just gets more and
more complicated. The only workable solution would be to incorporate
the entire rebaseall functionality internally into setup.exe, which is
not an insignificant undertaking, and one which no one is eager to
undertake.
On top of that, there is a problem with running out of address space. I
don't think this happens (yet!) with the official packages but someone
has reported that it can happen if you suppliment an installation with
some of the Cygwin ports like KDE. So this solution of rebasing every
single DLL is clearly not scaleable into the future, unless the Cygwin
DLL's memory layout is rearranged, or unless DLLs are rebased into
another memory space.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -