Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging

[Mark Fisher]

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.