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

[Peter Bex]

On Thu, Aug 26, 2021 at 01:38:42PM +0100, Mark Fisher wrote:
> I always ran clean/confclean between any builds to regenerate the
> chicken-config file and would
> watch for its generation when I built it, so I don't think it was that.
> I'm pretty sure I never mixed and matched PLATFORM= values between runs,
> and never ran just "mingw".

OK, we can rule that out then.

> 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 never ran a build from a windows cmd shell, so I don't understand the
> file path/xcopy errors. Interestingly this is one of the problems in
> the chocolatey build, it's using "cp" in a windows cmd shell instead
> of xcopy.

Well, if you build with msys, it expects to be able to use the msys
tools, regardless how the program is being invoked.  Perhaps we need
to make chicken-install be smarter so that it can detect whether it
is being called from CMD or from bash, but that would complicate things
quite a bit.

Perhaps always invoking bash on the generated script explicitly in an
msys build might be a simpler way?

It looks like Chocolatey uses msys2, so it makes sense that it would
emit egg build scripts that rely on msys2 tools.

> Also, I think the platform auto-detection ought to work with 5.3.0,
> > so you don't even need to pass in PLATFORM.
> 
> I only just came across the detect Makefile.
> 
> So, just running make on its own, with no PLATFORM (after running
> clean/confclean).

Yep, that should work.

> - - -  run 1 MSYS2/MINGW64 shell - - -
> shell = MSYS2/MINGW64
> gcc=gcc.exe (Rev5, Built by MSYS2 project) 10.3.0
> make=GNU Make 4.3, Built for x86_64-pc-msys
> 
>     make clean confclean
>     touch *.scm # force rebuild of c files
>     make
>     make DESTDIR=/tmp/chicken-build/001 install
> 
> The resultant binary has the following problem (which I've seen before but
> can't remember if I mentioned in this thread):
> 
>      $ /tmp/chicken-build/001/usr/local/bin/chicken-install -update-db
>     loading import libraries ...
>     generating database ...
> 
>     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.

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).

> - - -  run  MSYS2 shell - - -

Again, I don't understand how this is different from an MSYS2/MINGW64
shell.

> So currently, I still can't produce working binaries in the MINGW64/MSYS
> environment.
> 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).

Hope this helps!

Cheers,
Peter

signature.asc
Description: PGP signature