From: Chris S. <ir0...@gm...> - 2010-02-19 11:44:37
|
Starting sh.exe using MSys 1.0.13-2 causes an immediate crash. I updated the -bin and -dev packages to 1.0.13-2 from 1.0.12, are there other packages I also need to upgrade to make it work? Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Cesar S. <ces...@gm...> - 2010-02-19 14:02:28
|
Chris Sutcliffe wrote: > Starting sh.exe using MSys 1.0.13-2 causes an immediate crash. I > updated the -bin and -dev packages to 1.0.13-2 from 1.0.12, are there > other packages I also need to upgrade to make it work? No, not really. Please unpack the following archives into an empty directory: msysCORE-1.0.13-2-msys-1.0.13-bin.tar.lzma bash-3.1.17-2-msys-1.0.11-bin.tar.lzma coreutils-5.97-2-msys-1.0.11-bin.tar.lzma Then, run the newly created msys.bat. You may also try to reduce PATH to a minimum. Does it still crash? Cesar |
From: Chris S. <ir0...@gm...> - 2010-02-19 15:06:22
|
Hi Cesar, > Please unpack the following archives into an empty directory: > > msysCORE-1.0.13-2-msys-1.0.13-bin.tar.lzma > bash-3.1.17-2-msys-1.0.11-bin.tar.lzma > coreutils-5.97-2-msys-1.0.11-bin.tar.lzma > > Then, run the newly created msys.bat. You may also try to reduce PATH to > a minimum. > > Does it still crash? Yep, and running sh.exe itself: C:\MSYS-TEMP\bin>sh.exe 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x71690000, RegionSize 0x410000, State 0x10000 C:\MSYS-TEMP\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 6 Any ideas on what I can try to correct the error? 1.0.12 works OK for me (other than the chmod issue I mentioned previously). Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2010-02-20 01:04:18
|
Chris Sutcliffe wrote: > C:\MSYS-TEMP\bin>sh.exe > 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 > AllocationBase 0x0, BaseAddress 0x71690000, RegionSize 0x410000, State 0x10000 > C:\MSYS-TEMP\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, > Win32 error 6 Oh, geez. This sounds like either the dreaded DLL rebasing problem, or a BLODA. For the latter problem, see if any of these applications are installed on your machine: http://cygwin.com/faq/faq.using.html#faq.using.bloda For the former... > Any ideas on what I can try to correct the error? 1.0.12 works OK for > me (other than the chmod issue I mentioned previously). install dash and rebase (err...wait. Have I uploaded those yet? Ooops. Okay, wait until I upload them...) and then follow the instructions to run 'rebaseall'. Until then, if you have cygwin installed (or access to the microsoft 'rebase' tool) you could use THAT to try and rebase the msys dll itself: rebase -b 0x30000000 /path/to/msys-1.0.dll -- Chuck |
From: Chris S. <ir0...@gm...> - 2010-02-20 03:38:12
|
Hi Chuck, > Oh, geez. This sounds like either the dreaded DLL rebasing problem, or a > BLODA. For the latter problem, see if any of these applications are > installed on your machine: > > Until then, if you have cygwin installed (or access to the microsoft > 'rebase' tool) you could use THAT to try and rebase the msys dll itself: > > rebase -b 0x30000000 /path/to/msys-1.0.dll It was the rebase problem, using Cygwin's rebase solved the issue (thank you for the tip). Wouldn't this be a good case for using '-Wl,--enable-auto-image-base' when linking msys-1.0.dll? Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2010-02-20 15:14:59
|
Chris Sutcliffe wrote: > Wouldn't this be a good case for using '-Wl,--enable-auto-image-base' > when linking msys-1.0.dll? No, I don't think so. The image base for cygwin1.dll and msys-1.0.dll is actually explicitly specified in the build machinery (a fairly uncommon thing in the world of cygwin/msys DLLs). Changing it to auto would just move it somewhere else that may -- or may NOT -- have fewer conflicts on SOME systems, but not others. And it wouldn't be under our control. But /somebody/ is going to see conflicts, no matter what memory address we (or --auto) picks. BTW, just as cygwin-rebase can't rebase cygwin1.dll, my msys port of rebase can't rebase msys-1.0.dll. Maybe we need a pure win32 version... -- Chuck |
From: Johannes S. <Joh...@gm...> - 2010-02-20 15:32:14
|
Hi, On Sat, 20 Feb 2010, Charles Wilson wrote: > BTW, just as cygwin-rebase can't rebase cygwin1.dll, my msys port of > rebase can't rebase msys-1.0.dll. Maybe we need a pure win32 version... If you want a MinGW version of rebase, I think this is doing what you want it to do: http://repo.or.cz/w/msysgit.git/commitdiff/76920dc49da361257cbccb02ea63b3e5357fe353 And the sources are here: http://repo.or.cz/w/msysgit.git/commitdiff/322c42c780833a52bd7cd0358a562ab243ecfbce But I guess you still would have problems with rebasing in-use .dll files. You need to copy them to a new name, use the rebase.exe tool, then exit every process using the .dll file and replace the .dll file. Ciao, Johannes |