Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <435DBB31.5C164C83@dessent.net> Date: Mon, 24 Oct 2005 21:57:21 -0700 From: Brian Dessent MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: cygwin-setup & rebaseall References: <435D743F DOT EDB6FBB9 AT dessent DOT net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com 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/