RE: Failure with fork()

[<gmt@malth.us>]

on Thu, 27 Jun 2013, at 12:22, Alan W. Irwin thusly quipped:
> On 2013-06-27 21:00+0200 marco atzeri wrote:
> 
>> Il 6/27/2013 8:35 PM, Alan W. Irwin ha scritto:
>>> Are there daily snapshot builds of the CVS version I could access?
>> 
>> daily not, but on reasonable schedule
>> (aka when Corinna or Christopher release one)
>> 
>> http://cygwin.com/snapshots/
>> 
>> just wait for the next cygwin1-20130xxx.dll.bz2
>> and replace the installed cygwin1.dll with the new one
> 
> I haven't even gotten as far as an initial install because
> of this fork bug.
> 
> From the Linux command line here is what I did some time ago (for a
> wine-git version very close to wine-1.6.0-rc1 and for (presumably) the
> latest stable release of setup.exe downloaded from
> http://cygwin.com/setup.exe) when I first ran into the fork bug:
> 
> wineconsole setup.exe

I haven't tried this myself (yet), but if you "can't wait", and have access to a mingw64 cross-compiler, you can likely get cygwin cvs here: http://cygwin.com/cvs.html, and, from there, follow a fairly typical cross-compiling configure && make && make install DESTDIR=foo && tar type of process to create your own "ghetto" snapshot, that you could drop into place on top of your your half-completed nascent cyg-wine install.  From there, you could run setup.exe, uncheck the "cygwin" and "newlib" packages, and then, when setup.exe prompts you to put those packages back in, uncheck the box (by default, checked) specifying to add them.

Assuming you get that far, successfully, you'd then expect to see some results -- either finding the next bug, discovering the bug still exists, somehow, or that everything is magically fixed... what-have-you.

Alternatively, you could try to create a cross-cygport.  Not sure how easy/hard that is, but I'd guess it's fairly straightforward.  Cygport by default generates "setup.exe"-compatible package-trees that, if I'm not mistaken, by following easily-google-able advice, can be overlaid into your setup.exe's package-set so that you could follow a standard setup.exe process without having to uncheck those core packages.

No idea what results you'll get -- very likely an anticlimax where you simply find the next bug -- but one of the above would probably allow you to proceed; worst-case you'd at least have a build environment, for future testing/hacking, that you could recycle. 

-gmt


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple