Is anyone able to build on Win 7

Tue Feb 14 11:29:52 UTC 2012

Hi Kelly,

that's an interesting hint. I looked at it and tried to understand
what's behind it.
Here's what I found out - if I'm wrong or if somebody has additional
information I
would appreciate any correction!

1. Windows DLLs  have a base address which indicates the virtual base address
where they would like to get loaded to.

2. If this address is already in use, the operating system chooses
another base address
and the DLL is relocated to that new base address.
Relocation should be no problem for a DLL, but apparently the
implementation of "fork()"
in Cygwin is very picky about these base addresses and "..needs to
have a very special
memory layout to implement the fork semantics in Win32. If this memory
layout is disrupted,
fork breaks.." (from http://www.cygwin.com/ml/cygwin/2009-05/msg00413.html).

3. The McAffe knowledge base entry cited by Kelly states: "..When a
Cygwin DLL fails to load
to the default address, Windows arbitrarily chooses an available
address and loads it there.
That works only as long as Windows chooses the same address every
time, but there are a
lot of conditions during startup that may affect the outcome."

4. Cygwin comes with its own rebase tool (/bin/rebaseall) which
"..does its best to locate all
Cygwin DLLs that it knows of into a layout that avoids collisions.."
"rebaseall" is usually called by setup.exe so if you do not manually
install any DLLs, this
shouldn't be a problem.
I indeed ran 'rebaseall' (call 'rebaseall --help' for an instruction
how to use it) without
any positive effect and I assume this is because all the DLLs already
had non-overlapping
base addresses. There's one thing to keep in mind however: Cygwins
'rebaseall' can not
rebase 'cygwin1.dll' because it is linked against it. To rebase
'cygwin1.dll' one has to use
another rebase tool (e.g. "C:\Program Files\Microsoft
SDKs\Windows\v7.1\Bin\ReBase.Exe"
from the MS SDK). I've done that but that even worsened things
(probably because it is not
so easy to rebase cygwin1.dll to a meaningful new base address without
knowing the
memory layout of 32-bit Windows processes:).

5. During all these experiments I ran across another new Windows7
feature called ASLR
(Address Space Layout Randomization, see
http://en.wikipedia.org/wiki/Address_space_layout_randomization).
Actually it is not really new in Windows 7 but from what I've read it
is implemented much more
aggressively in Windows 7. On Windows 7, ASLR can only be disabled  by
using the
Enhanced Mitigation Experience Toolkit provided by Microsoft
(http://support.microsoft.com/kb/2458544),
(the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
Management\MoveImages
registry setting has no effect in Windows 7)

6. The default setting for ASLR is still "application opt in" which
means that only applications
which want will be randomized. You can check this for example with the
Cygwins /usr/bin/peflags
tool. It will display something like "[-dynamicbase]" for applications
which don't want to be
randomized. Now all Cygwin DLL's have "-dynamicbase", so why should
this be a problem?
My naive explanation is that the Cygwin DLLs still depend an native
Windows runtime DLLs and
they all will be randomized by default. If now one of these Windows
sysytem DLLs will be placed
at the default base address of a Cygwin DLL, the Cygwin DLL will have
to be relocated with the
outcome described in 2.

7. I switched ASLR off (you need to reboot afterwards) and was able to
do 4 consecutive,
full builds without any error. After that I switched ASLR on again,
rebooted and the second
build failed with the well known "fork" problem.

To cut a long story short:
- disabling "on access" scanning of *.{java,c,cpp,h,hpp} seems to
resolve the file io problems (permission denied, access denied)
- disabling ASLR seems to resolve the "fork" problems

I would be graceful if anybody could confirm these findings or can
come up with another, better solution/explanation.

Regards,
Volker

On Thu, Feb 9, 2012 at 9:42 PM, Kelly O'Hair <kelly.ohair at oracle.com> wrote:
>
> Does this article provide any help:
>
> https://kc.mcafee.com/corporate/index?page=content&id=KB55075&actp=search&viewlocale=en_US&searchid=1328818133782
>
> It suggests that rebase'ing the CYGWIN DLL's will help. Seems a bit strange to me, just passing it on.
>
> -kto
>
> On Jan 25, 2012, at 5:10 PM, Pete Brunet wrote:
>
>> I just had success with the following changes:
>> - downgraded from cygwin 1.7.9 (with bash 4.1.10) to 1.7.0 (with bash
>> 3.2.49)
>> - changed ...\jdk\make\docs\Makefile line 74
>>
>> ifeq ($(ARCH_DATA_MODEL),64)
>>  MAX_VM_MEMORY = 1024
>> else
>>  MAX_VM_MEMORY = 1024 <--- This was 512
>> endif
>>
>> I've only done one build and in prior builds had other issues besides
>> the memory problem, i.e. fork and error 126, but there's always hope.
>>
>> If others could report their W7 configurations and whether or not there
>> were problems, that would be helpful.
>>
>> Pete
>>
>> On 1/25/12 6:17 PM, Kelly O'Hair wrote:
>>> Sorry guys, I don't have the time or priority to track this down.
>>> Official builds are still happening on Windows XP and Windows 2003 X64 and these
>>> problems are not being seen on those systems.... yet...
>>> although we recently have been visited by the McAfee plague so maybe it's just a matter of time. ;^(
>>>
>>> Someone with some strong Windows experience needs to run this to ground.
>>> We do need this to work, eventually.
>>>
>>> -kto
>>>
>>> On Jan 25, 2012, at 9:09 AM, Pete Brunet wrote:
>>>
>>>> I started W7 in safe mode and the build failed with a fork failure.  I
>>>> think that eliminates things in the BLODA list.  If anyone out there is
>>>> building OK on W7 please send your configuration, e.g. as shown below.
>>>> Maybe that will suggest a different version of cygwin or bash.  -Pete
>>>>
>>>> On 1/25/12 9:55 AM, Pete Brunet wrote:
>>>>> Thanks Volker, I was thinking I'm going to have to try using XP in a
>>>>> VM.  My W7 config is very close to yours (make 3.81 instead of 3.82).
>>>>>
>>>>> W7 Pro, 64 bit, SP1
>>>>> Intel Core 2 Duo, P8700, 2.53 GHz, 8 GB RAM
>>>>> CYGWIN_NT-6.1-WOW64 Bevo 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
>>>>> GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)
>>>>> GNU Make 3.81
>>>>>
>>>>> Pete
>>>>>
>>>>> On 1/25/12 9:06 AM, Volker Simonis wrote:
>>>>>> Hi Peter,
>>>>>>
>>>>>> glad to see that other have the same problems:)
>>>>>>
>>>>>> But seriously, on Windows 7 I'm currently experiencing the same
>>>>>> massive build problems and I'm not sure what the root cause of these
>>>>>> problems is.
>>>>>>
>>>>>> I found the following bug which exactly describes the problems I'm facing:
>>>>>>
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6903517
>>>>>>
>>>>>> Among others, these are:
>>>>>>
>>>>>> - rm: cannot remove directory `META-INF': Directory not empty
>>>>>> - error:  cannot create example2.html: Permission denied
>>>>>> - [javac] C:\Software\OpenJDK\jdk8\langtools\src\share\classes\com\sun\tools\javac\util\SharedNameTable.java:40:
>>>>>> error: error while writing SharedNameTable:
>>>>>> c:\Software\OpenJDK\output_amd64\langtools\build\bootstrap\classes\com\sun\tools\javac\util\SharedNameTable.class
>>>>>> (Access is denied)
>>>>>>
>>>>>> but I also saw the 'out of memory' and 'for' problems mentioned by you.
>>>>>>
>>>>>> The description of bug 6903517 references the "Big List of Dodgy Apps"
>>>>>> (http://cygwin.com/faq/faq.using.html#faq.using.bloda). This is a list
>>>>>> in the Cygwin FAQ which lists applications like Virus Scanners which
>>>>>> can interfere with Cygwin in an unpredictable way. An indeed the
>>>>>> Windows 7 box on which I observe the problems has some of them
>>>>>> installed (e.g. McAffe {Agent, GTI Proxy Agent, Intrusion Prevention,
>>>>>> VirusScan Enterprise, AntySpywaare Enterprise} to name just a few).
>>>>>>
>>>>>> On the other hand, on the same Windows 7 box I have a virtual machine
>>>>>> running inside VirtualBox  with WindowsXP which has the same McAffe
>>>>>> software installed and it is running without any problems. The OpenJDK
>>>>>> build always succeeds in the virtual machine!
>>>>>>
>>>>>> So I'm not quite sure of this is:
>>>>>> - a problem of some additional software which is running on my Windows
>>>>>> 7 box and interferes with Cygwin
>>>>>> - a general Windows7 problem
>>>>>> - a problem of the specific Cygwin version I'm using
>>>>>> - a problem of Cygwin running on 64-bit Windows 7
>>>>>>
>>>>>> I'll try to further narrow down the problem, but of course any hints
>>>>>> are highly welcome (unfortunately I can't easily get rid of the McAffe
>>>>>> stuff without losing my job, so please don't advise this:)
>>>>>>
>>>>>> Regards,
>>>>>> Volker
>>>>>>
>>>>>> PS: below you can find the exact versions of the software/hardware I'm using:
>>>>>>
>>>>>> 64-bit Windows 7, SP 1
>>>>>> Dual Core Intel i7, 8GB RAM
>>>>>>
>>>>>> Cygwin (output of uname -a):
>>>>>> CYGWIN_NT-6.1-WOW64 WDFN00299915A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
>>>>>> bash 4.1.10(4)  // installed by Cygwin setup.exe
>>>>>> make 3.82  // compiled by myself
>>>>>>
>>>>>> In the Virtual box VM I have the following system:
>>>>>>
>>>>>> 64-bit Windows XP Professional Version 2003 SP 2
>>>>>>
>>>>>> Cygwin (output of uname -a):
>>>>>> CYGWIN_NT-5.2-WOW64 WDFV00248216A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
>>>>>> bash 4.1.10(4)  // installed by Cygwin setup.exe
>>>>>> make 3.82  // compiled by myself
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 24, 2012 at 5:52 PM, Pete Brunet <peter.brunet at oracle.com> wrote:
>>>>>>> Is anyone able to build on Win 7?  I'm on my 8th build hoping to get to
>>>>>>> the end and have seen these errors:
>>>>>>>
>>>>>>> out of memory, 3 times - I have more than enough memory
>>>>>>> fork: Resource temporarily unavailable, 3 times
>>>>>>> error 126, once
>>>>>>>
>>>>>>> I have read http://cygwin.com/faq-nochunks.html#faq.using.bloda so
>>>>>>> apparently something on my system is causing a problem but I haven't
>>>>>>> been successful in finding it yet.  I have my Norton 360 "Auto-Protect"
>>>>>>> turned off.  It would be helpful to know if anyone has successfully
>>>>>>> built on Win 7 and also if anyone has ideas on what I might look for
>>>>>>> beyond what is listed in the cygwin FAQ.
>>>>>>>
>>>>>>> Thanks, Pete
>>>>>>>
>>>>>>>
>