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 Date: Mon, 11 Jul 2005 22:17:51 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Updated: perl-5.8.7-2 Message-ID: <20050712021751.GD17886@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com References: <7231C15EAC2F164CA6DC326D97493C8BA1C483 AT exchange35 DOT fed DOT cclrc DOT ac DOT uk> <42D2E4A6 DOT 7030107 AT familiehaase DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42D2E4A6.7030107@familiehaase.de> User-Agent: Mutt/1.5.8i On Mon, Jul 11, 2005 at 11:29:10PM +0200, Gerrit P. Haase wrote: >Adye, TJ (Tim) wrote: >>Thanks for the Perl update. >> >>Unfortunately this doesn't seem to fix the problem I reported earlier >>("Perl Win32::Shortcut screws up fork"). My test script worked fine >>after "rebaseall", but when I reinstalled Cygwin from scratch (including >>Perl 5.8.7-2) it dies with >> >>C:\cygwin\bin\perl.exe (3772): *** unable to remap >>C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcut\Shortcut. >>dll to same address as parent(0x950000) != 0xBF0000 >> 17 [main] perl 3448 fork_parent: child 3772 died waiting for dll >>loading >> >>The addresses are now different, if that's any consolation (previously >>it reported parent(0xBF0000) != 0x1110000). >> >>Presumably "rebaseall" will fix it again, but I'll keep the pristine >>Cygwin installation for further tests if that's helpful. > >Jason said it in the "Perl Win32::Shortcut screws up fork" thread, >auto-image-base helps but it doesn't resolve all issues. A certain >amount of pad is required between the base DLL addresses and it seems >that this is one of those cases where the padding is too small. I really can't see why this padding would be needed for fork. If the dlls are in the same place in the parent and the child (as should be the case after an auto-image-base) then fork() shouldn't care where they're located. It is only when some dlls are not correctly based and some are that I could see problems. In any event, if the problem really does occur, even with all dlls correctly based, there's certainly no reason to stand on our heads trying to accommodate cygwin behavior. We golly gee just might be able to fix cygwin if we have a reproducible test case. cgf -- 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/