The pypy-c executable is not a dll, and hence does not need to be rebased if I
understand it correctly. However, just to follow up on this hunch, I rebased it
by first running rebaseall -v on the complete Cygwin installation (which does
not touch pypy-c even if put into /usr/bin/) and then manually rebasing pypy-c
to the next available base address. Unfortunately this does not help.
As to the question about runtime libraries, pypy links against the following
libraries:
$ cygcheck ./pypy-c
D:\pypy\pypy-work-no-python-patch\pypy\pypy\translator\goal\pypy-c
C:\cygwin\bin\cygbz2-1.dll
C:\cygwin\bin\cygwin1.dll
C:\windows\system32\KERNEL32.dll
C:\windows\system32\ntdll.dll
C:\cygwin\bin\cyggcc_s-1.dll
C:\cygwin\bin\cygcrypt-0.dll
C:\cygwin\bin\cygcrypto-1.0.0.dll
C:\cygwin\bin\cygz.dll
C:\cygwin\bin\cygncurses-10.dll
C:\cygwin\bin\cygexpat-1.dll
C:\cygwin\bin\cygintl-8.dll
C:\cygwin\bin\cygiconv-2.dll
C:\cygwin\bin\cygssl-1.0.0.dll
C:\cygwin\bin\cygffi-4.dll
Just for good measure, here's a typical error message from an interactive pypy
session:
$ pypy-c
Python 2.7.2 (b0005ab7c34f+, Jun 06 2012, 17:33:28)
[PyPy 1.9.1-dev0 with GCC 4.5.3] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``'that's definitely a case of
"uh????"'''
>>>> import os
>>>> os.fork()
3 [main] pypy-c 11788 fixup_mmaps_after_fork: ReadProcessMemory failed
for MAP_PRIVATE address 0xB0010000, Win32 error 998
153 [main] pypy-c 11788
D:\pypy\pypy-work-no-python-patch\pypy\pypy\translator\goal\pypy-c: *** fatal
error in forked process - recreate_mmaps_after_fork_failed
499 [main] pypy-c 11788 open_stackdumpfile: Dumping stack trace to
pypy-c.stackdump
2 [main] pypy-c 2572 fork: child -1 - forked process 11788 died
unexpectedly, retry 0, exit code 256, errno 11
Traceback (most recent call last):
File
"<console>", line 1, in <module>
OSError: [Errno 11] Resource temporarily
unavailable
>>>>
I noticed that the address 0xB0010000 in the error message above seems to be
the same regardless of rebasing pypy-c or not, and I am seeing this address on
two different Windows 2003 64bit servers. For what it's worth, the expected
output, from a python session, would be:
$ python
Python 2.6.7 (r267:88850, Feb 2 2012, 23:50:20)
[GCC 4.5.3] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.fork()
5552
>>> 0
>>>
Finally, today unexpectedly the os.fork() call works on a Windows XP
Professional 32bit box, where it previously failed (that's the Cygwin pypy
1.8.1 version I had posted on my web page).
--Uwe
________________________________
From: Amaury Forgeot d'Arc <amaur...@gmail.com>
To: Uwe F. Mayer <uwe_f_ma...@yahoo.com>
Cc: Armin Rigo <ar...@tunes.org>; Matti Picus <matti.pi...@gmail.com>;
"pypy-dev@python.org" <pypy-dev@python.org>
Sent: Thursday, June 7, 2012 10:46 AM
Subject: Re: [pypy-dev] Patches for Pypy under cygwin
2012/6/7 Uwe F. Mayer <uwe_f_ma...@yahoo.com>
Currently the Cygwin Pypy Python standalone version build with --opt=jit fails
on os.fork() calls.
fork() on Windows... I'm surprised it works at all!
You should probably read this page:
http://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-process
specially the "DLL base address collisions", did you run rebaseall?
Is pypy linked with some non-cygwin load-time DLLs?
--
Amaury Forgeot d'Arc
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
