Firstly, > Hope this helps!
This is all incredibly helpful thanks! > > This is exactly what I was expecting too, although the "mingw-msys" > > build I would expect to be from a "MSYS2 MinGW 64bit" shell to be > > specific (as opposed to "MSYS2 MSYS" shell) when running make. > > I don't understand what you're getting at here. Could you clarify? I'm talking about the 2 ways (icons in the start menu) to open a shell when you install MSYS2 1. "MSYS2 MSYS": msys2 subsystem only, doesn't add MingW64 compiler to the path, for posix builds 2. "MSYS2 MinGW 64 bit" - adds the mingw64 gcc install to the path Or from their docs (https://www.msys2.org/wiki/MSYS2-introduction/): > "MSYS2 consists of three subsystems and their corresponding package > repositories, msys2, mingw32, and mingw64" ignoring mingw32 as I'm only interested in 64 bit locally, the 2 shells I can open start a bash for the "msys2" or the "mingw64" subsystems (corresponding names are 1, 2 above) so when building using a platform of "mingw-msys" I would expect to be in the 2nd of the these shells. I was trying to clarify against the comment you made that: > So mingw-msys from a bash prompt if you want to use CHICKEN from msys' bash > prompt "msys' bash prompt", is slightly vague in that it could be either of their sub-systems. > > Error: (open-output-file) cannot open file - No such file or directory: > > "/usr/local/lib/chicken/11\\modules.db" > > > > So it's mixing windows paths in. > > It kind of makes sense - there is no default for PREFIX under Windows, > and the /usr/local stuff is all "fake" - not visible to Windows itself, > only within the MSYS tools. > > I believe the way we use libc bypasses the msys POSIX directory stuff, > so we don't see /usr/local etc. I wouldn't worry about the backslash > in the path, that should be fine, as that's Windows' native path > separator. ok, that makes a bit more sense to me. I had thought that when it's in a msys2/mingw64 everything would be unix paths all the way down, so asking for "/usr/local/..." would work fine because it's asking the underlying msys for a file from the path requested, which it understands and doesn't need windows drive references. This must be why the cygwin version I created works as the library it created must bridge the 2 worlds. > > > - - - run MSYS2 shell - - - > > Again, I don't understand how this is different from an MSYS2/MINGW64 > shell. Hopefully explained at the top of this message. 2 subsystems are very different from their ability to build point of view. I was covering both bases. > > The `\\` seems to be the problem at the moment. > > That's a red herring. The problem is that there's no /usr/local path > in Windows (it is there in mingw, being faked around by the msys tools, > and that's what throwing you off). That's what I was missing it seems. > So perhaps you can retry this same thing, but pass in a PREFIX using a > native Windows path (using a drive letter and slashes instead of > backslashes, like the README says). ok, I built again with a PREFIX of C:/msys64/usr/local, and I'm back to my original issue right at the start of the thread. The application hangs running chicken-install, and running strace on the process shows it's constantly throwing an error internally: ... --- Process 11796, exception c0000005 at 0000000180139247 --- Process 11796, exception c0000005 at 0000000180139247 --- Process 11796, exception c0000005 at 0000000180139247 ... ... repeated constantly until I kill the process with Task Manager Again, thanks for helping solve this.