This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: Wierd perl problem..
- To: "Fifer, Eric" <EFifer at sanwaint dot com>
- Subject: Re: Wierd perl problem..
- From: Chris Faylor <cgf at cygnus dot com>
- Date: Fri, 22 Oct 1999 11:48:00 -0400
- Cc: "'cygwin at sourceware dot cygnus dot com'" <cygwin at sourceware dot cygnus dot com>, Steve Jorgensen <steve at khoral dot com>
- References: <779F20BCCE5AD31186A50008C75D997917166A@SILLDN_MAIL1>
- Reply-To: cygwin at sourceware dot cygnus dot com
Another work around is to change the load address for each DLL that
perl uses. The problem is that when perl issues a fork and cygwin tries
to reload the DLLs that were in use in the parent, cygwin is unable to
map the DLLs into exactly the same address space in the child. This
confuses things badly.
Changing the load addresses would rectify this. Currently every DLL (on
the Cygwin CD, at least) loads into 0x64000000. If one could change
this that would work around the problem for perl. Unfortunately, I
don't think that there is any way to do this with any of our distributed
tools. There are tools available from microsoft (editbin) which all
allow this, however.
cgf
On Fri, Oct 22, 1999 at 02:48:39PM +0100, Fifer, Eric wrote:
>The workaround is to build perl with the extension statically
>linked into perl.exe. In this case FileHandle.pm uses IO.pm,
>so IO needs to be statically linked when you originally run
>Configure during the perl make process. This is the default
>with hints/cygwin.sh that is in the latest developer
>release, perl5.005_62.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com