Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
> Many thanks for this thorough analysis. Could you do me a favour? > Could you send me the installation instructions and the > generated chicken-config.h files for each build option you used? > Perhaps that way we can figure out where our various Windows > build configurations are inconsistent. I'll do that now over lunch. I'll send them to you outside the list.
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
Mark, Many thanks for this thorough analysis. Could you do me a favour? Could you send me the installation instructions and the generated chicken-config.h files for each build option you used? Perhaps that way we can figure out where our various Windows build configurations are inconsistent. felix
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
> Could you give 5.3.0rc2 a quick spin? In it, we've simply
> dropped the custom implementation of opendir and readdir.
Sure thing. Looks good.
Sorry it's taken a while to respond, but I wanted to do some thorough tests.
TL,DR;
It's not crashing any more
I can install eggs, and use them.
I tried:
1. compiling and installing in an MSYS2/MinGW64 shell
2. compiling and installing in a windows CMD shell with MSYS2/MinGW64 paths
3. compiling and installing in a windows CMD shell with chocolatey
make/gcc on the path
All of them worked.
However, of note was the ones with MSYS2/MinGW64 binaries on the path
created versions that make eggs think they should use "cp" instead of
"xcopy" in thier install bat files. (I think this is to do with
C_TARGET_INSTALL_PROGRAM)
For example, this version was the output from (2) above:
> set PATH=c:\chicken\bin;%PATH%
> chicken-install srfi-1 # i'd already compiled this in another shell
building srfi-1
installing srfi-1
A subdirectory or file C:\chicken\lib\chicken\11 already exists.
'cp' is not recognized as an internal or external command
- - - - -
In srfi-1.install.bat:
- - - 8< - - -
@echo off
cd /d "C:\Users\markj\AppData\Local\chicken-install\srfi-1"
mkdir %DESTDIR%"C:\chicken\lib\chicken\11"
cp -r "C:\Users\markj\AppData\Local\chicken-install\srfi-1\srfi-1.static.obj"
%DESTDIR%"C:\chicken\lib\chicken\11\srfi-1.obj"
cp -r "C:\Users\markj\AppData\Local\chicken-install\srfi-1\srfi-1.link"
%DESTDIR%"C:\chicken\lib\chicken\11\srfi-1.link"
if errorlevel 1 exit /b 1
... etc.
- - -
But building with option (3) is giving:
- - - 8< - - -
@echo off
cd /d "C:\Users\markj\AppData\Local\chicken-install\srfi-1"
mkdir %DESTDIR%"C:\chicken\lib\chicken\11"
copy /Y "C:\Users\markj\AppData\Local\chicken-install\srfi-1\srfi-1.static.obj"
%DESTDIR%"C:\chicken\lib\chicken\11\srfi-1.obj"
copy /Y "C:\Users\markj\AppData\Local\chicken-install\srfi-1\srfi-1.link"
%DESTDIR%"C:\chicken\lib\chicken\11\srfi-1.link"
if errorlevel 1 exit /b 1
... etc
- - -
Using option 3:
Compilation test with uri-common egg:
==
;;; uri-test.scm
(import uri-common)
(print (uri->string (update-uri (uri-reference "") path: '("example"
"greeting") query: '((hi . "there")
> csc uri-test.scm
> uri-test.exe
example/greeting?hi=there
Interactive test
=
C:\Users\markj>csi
CHICKEN
(c) 2008-2021, The CHICKEN Team
(c) 2000-2007, Felix L. Winkelmann
Version 5.3.0rc2 ((HEAD detached at 5.3.0rc2)) (rev 12bb5c31)
mingw32-windows-gnu-x86-64 [ 64bit dload ptables ]
Type ,? for help.
#;1> (import uri-common)
; loading C:/chicken/lib/chicken/11/uri-common.import.so ...
; loading C:/chicken/lib/chicken/11/uri-common.so ...
; loading C:/chicken/lib/chicken/11/srfi-1.so ...
; loading C:/chicken/lib/chicken/11/srfi-13.so ...
; loading C:/chicken/lib/chicken/11/srfi-14.so ...
; loading C:/chicken/lib/chicken/11/defstruct.so ...
; loading C:/chicken/lib/chicken/11/matchable.so ...
; loading C:/chicken/lib/chicken/11/uri-generic.so ...
#;2> (uri->string (update-uri (uri-reference "") path: '("example"
"greeting") query: '((hi . "there"
"example/greeting?hi=there"
#;3>
So I think that installing from a MSYS2/MinGW64 shell is still not
quite working correctly, but it appears to be spot on using chocolatey
with msys2/make installed.
Also, one other problem I have is that non of the binaries I created
have a chicken-install that works in a MSYS2/MinGW64 shell
- - - 8< - - -
$ chicken-install test
fetching test
'xcopy' is not recognized as an internal or external command,
operable program or batch file.
Error: (open-input-file) cannot open file - No such file or directory:
"C:\\Users\\markj\\AppData\\Local\\chicken-install\\test\\test.egg"
- - -
So it seems with chocolatey on my path its build seemed to make
everything fully "windows", whereas with MSYS2/MinGW64 on the path it
was slightly unixy (cp instead of xcopy, but still referring to
C:\\Users\\markj\\AppData etc).
Option (2) did mostly work though as a solution without chocolatey,
but only because unix style binaries were on the path.
mark
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
On Fri, Aug 27, 2021 at 08:00:22PM +0100, Mark Fisher wrote: > I have traced where my copy is crashing, but I don't know why. Hi Mark, Could you give 5.3.0rc2 a quick spin? In it, we've simply dropped the custom implementation of opendir and readdir. Also, since it is pre-translated to C, it doesn't need a preinstalled CHICKEN and any patching, which reduces the chance of errors due to rebuilding. Cheers, Peter signature.asc Description: PGP signature
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
I have traced where my copy is crashing, but I don't know why.
After compiling with DEBUGBUILD, and using gdb, I've step debug the
application until it crashes.
This is the last function it enters in chicken-install.c:
/* main#destination-repository in k8330 in k8326 in k8322 in k8318 in
k8314 in k8310 in k8306 in k8302 in k8298 in k8294 in k8290 in k8286
in k8282 in k8278 in k8274 in k8270 in k8266 in k8262 in k8258 in
k8254 in k22049 in ... */
static void C_fcall f_8360(C_word t1,C_word t2,C_word t3){
...
C_trace(C_text("egg-environment.scm:115:
chicken.process-context#get-environment-variable"));
t8=C_fast_retrieve(lf[57]);{
C_word av2[3];
av2[0]=t8;
av2[1]=t7;
av2[2]=lf[58];
((C_proc)(void*)(*((C_word*)t8+1)))(3,av2);}}}
so it's doing
(or (get-environment-variable "CHICKEN_INSTALL_REPOSITORY")
host-repo)))
It jumps around in library.c, runtime.c and file.c a bit before crashing.
The final backtrace is:
#0 0x7ffbabf5faad in ntdll!RtlEnterCriticalSection ()
from C:\Windows\SYSTEM32\ntdll.dll
#1 0x7ffba9a299c5 in KERNELBASE!FindNextFileW ()
from C:\Windows\System32\KernelBase.dll
#2 0x7ffba9a29868 in KERNELBASE!FindNextFileA ()
from C:\Windows\System32\KernelBase.dll
#3 0x7ffbabe56daa in msvcrt!_findnext64 ()
from C:\Windows\System32\msvcrt.dll
#4 0x7ffb451f8018 in _findnext64i32 (_FindHandle=,
_FindData=0x21ac4764f20)
at
C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/stdio/_findnext64i32.c:8
#5 0x7ffb44dc3607 in readdir (dir=0x21ac4764f20) at file.c:108
#6 0x7ffb44dd97f2 in f_903 (t0=484619982368, t1=484619986192)
at file.c:5341
#7 0x7ffb44dda226 in f_929 (t0=484619980592, t1=22) at file.c:5416
#8 0x7ffb44dda0ab in f_917 (c=2, av=0x70d59a1120) at file.c:5390
#9 0x7ffb44bc53ce in f_11588 (c=2, av=0x70d59a1120) at library.c:11683
#10 0x7ffb451e4824 in allocate_vector_2 (c=0, av=0x21ac2eebec8)
I don't know where to go from here though.
I've also tried cross compiling from my linux laptop.
Following the guide at https://wiki.call-cc.org/man/5/Cross%20development
This isn't very accurate, for instance, it mentions "see
C_PLATFORM_TYPE in chicken.h for the supported options", but there
isn't any C_PLATFORM_TYPE in that file.
I compiled chicken with:
make clean confclean
make ARCH=x86-64 PREFIX=C:/msys64/usr/local
PLATFORM=cross-linux-mingw HOSTSYSTEM=x86_64-w64-mingw32
DESTDIR=/home/redacted/dev/personal/windows-xcomp/target
CHICKEN=/home/redacted/.asdf/installs/chicken/5.2.0/bin/chicken
# have to drop the PLATFORM when installing else it mangles the destination
make ARCH=x86-64 PLATFORM=cross-linux-mingw
HOSTSYSTEM=x86_64-w64-mingw32
DESTDIR=/home/redacted/dev/personal/windows-xcomp/target
CHICKEN=/home/redacted/.asdf/installs/chicken/5.2.0/bin/chicken
install
I was able to make the cross compiled chicken work in wine on linux:
$ wine ../target/usr/local/bin/chicken.exe -version
CHICKEN
(c) 2008-2021, The CHICKEN Team
(c) 2000-2007, Felix L. Winkelmann
Version 5.3.0rc1 (prerelease) (rev 837cf9ff)
mingw32-windows-gnu-x86-64 [ 64bit dload ptables cross ]
$ wine ../target/usr/local/bin/chicken-install.exe -repository
C:/msys64/usr/local/lib/chicken/11
I transferred the cross compiled installation files to my PC, and
although a simple csi worked, as well as "chicken --version", it still
crashes trying to do a "chicken-install update-db" (this was in a
windows cmd shell with paths setup to pick up msys64 bin dirs).
I then found that if I move the old /usr/local/lib/chicken/11 dir out
the way, it then doesn't crash and was able to create a new modules.db
file.
However, when I then tried to install any egg, it was failing as the
PREFIX in my cross build in a windows shell is causing the install
scripts to insert the wrong delimiter, e.g.
set "PATH=C:/msys64/usr/local/bin;%PATH%"
set "CHICKEN_CC=gcc"
... etc
and the cmd script errors:
The filename, directory name, or volume label syntax is incorrect.
I can't run this under MSYS2 shell because it fails as it's unable to
understand cmd files.
I couldn't work out how to set the prefix up correctly to make the
paths correct, it kept failing to compile if I used any number of
backslashes instead of forward slashes in the PREFIX variable.
So I think I've got the cross compilation args wrong, but the instructions are
I really don't know how to get chicken compiling in windows, and not
crashing when doing chicken-install.
The cygwin build I made the other day still works in an MSYS shell but
not a cmd shell.
Is it possible to have it work in both?
Has anyone compiled a recent copy of chicken with the latest
MSYS/MingW64 installations?
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
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 c005 at 000180139247 --- Process 11796, exception c005 at 000180139247 --- Process 11796, exception c005 at 000180139247 ... ... repeated constantly until I kill the process with Task Manager Again, thanks for helping solve this.
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
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
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
> > Those assumptions are all correct. Looking at your other mail, I think I > understand what might be going wrong here. > > My guess is that you either tried to use PLATFORM=mingw from an msys > shell (i.e., msys2 bash), which would explain the error about XCOPY, > or you used PLATFORM=... with make, then aborted the compilation and > then switched to a different PLATFORM. 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". That won't work because the > PLATFORM is written into chicken-config.h. So it may appear to work > because the build works fine, but the resulting binaries will have > settings wired into them that don't match the platform you're building > for. > The steps I outlined above were from clean installs, and cleaning between runs. I even did a local git commit from the original tarball to ensure I wasn't amending anything I wasn't expecting. > Be sure to run the make from the type of shell you want to run the > resulting binaries from. So mingw-msys from a bash prompt if you > want to use CHICKEN from msys' bash prompt, or plain mingw from a > Windows CMD prompt if you want to use CHICKEN from that. > 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 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. > > I found this site: > > > https://github-wiki-see.page/m/accidentalrebel/rebel-game-engine/wiki/Building-and-running-the-engine-for-Windows-%28using-Msys2%29 > > This is really wrong and I have no idea who came up with this, but the > described actions are mixing up MSYS and Cygwin concepts. Agreed, yet somehow the resultant binaries work fine, and I'm glad you've confirmed my "but it shouldn't" thoughts. I've just checked my install out and it's got cyg*.dll files created, so I'm attempting a new build. 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). - - - 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. - - - run MSYS2 shell - - - shell = MSYS2 gcc=gcc (GCC) 10.2.0 # NOTE: This is different gcc make=GNU Make 4.3, Built for x86_64-pc-msys make clean confclean touch *.scm # force rebuild of c files make ... gcc -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H -DC_ENABLE_PTABLES -c -Os -DC_BUILDING_LIBCHICKEN posixwin.c -o posixwin-static.o -I. -I./ posixwin.c:140:10: fatal error: direct.h: No such file or directory 140 | #include | So this is failing to build because of missing headers in the MSYS only environment I tried installing the packages that have direct.h (but installs it in /opt) in them and clean/building, but still fails with the same error. So currently, I still can't produce working binaries in the MINGW64/MSYS environment. The `\\` seems to be the problem at the moment.
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
On Wed, Aug 25, 2021 at 08:34:47PM +0100, Mark Fisher wrote: > I've finally been able to get chicken installed and working, but I had to > pretend to be cygwin. > I think there's errors in the mingw-msys Makefile, or my assumptions about > it are wrong. > I would expect: > - "Makefile.mingw" to produce files for MingW64 in a windows cmd shell > - "Makefile.mingw-msys" to produce files for MingW64 in msys2 shells > (bash etc with unix paths) > - "Makefile.cygwin" to require some kind of cygwin setup, which I don't > have Those assumptions are all correct. Looking at your other mail, I think I understand what might be going wrong here. My guess is that you either tried to use PLATFORM=mingw from an msys shell (i.e., msys2 bash), which would explain the error about XCOPY, or you used PLATFORM=... with make, then aborted the compilation and then switched to a different PLATFORM. That won't work because the PLATFORM is written into chicken-config.h. So it may appear to work because the build works fine, but the resulting binaries will have settings wired into them that don't match the platform you're building for. Be sure to run the make from the type of shell you want to run the resulting binaries from. So mingw-msys from a bash prompt if you want to use CHICKEN from msys' bash prompt, or plain mingw from a Windows CMD prompt if you want to use CHICKEN from that. 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 found this site: > https://github-wiki-see.page/m/accidentalrebel/rebel-game-engine/wiki/Building-and-running-the-engine-for-Windows-%28using-Msys2%29 This is really wrong and I have no idea who came up with this, but the described actions are mixing up MSYS and Cygwin concepts. The Makefiles should be named correct and don't mix things up on the CHICKEN side, but CHICKEN can't really prevent the user from mixing things up on their side. Cheers, Peter signature.asc Description: PGP signature
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
>
> I just can't get this working.
>
I've finally been able to get chicken installed and working, but I had to
pretend to be cygwin.
I think there's errors in the mingw-msys Makefile, or my assumptions about
it are wrong.
I would expect:
- "Makefile.mingw" to produce files for MingW64 in a windows cmd shell
- "Makefile.mingw-msys" to produce files for MingW64 in msys2 shells
(bash etc with unix paths)
- "Makefile.cygwin" to require some kind of cygwin setup, which I don't
have
I found this site:
https://github-wiki-see.page/m/accidentalrebel/rebel-game-engine/wiki/Building-and-running-the-engine-for-Windows-%28using-Msys2%29
This time, I compiled under an MSYS shell (not MingW64)
$ make PLATFORM=cygwin install
I still needed at least a chicken.exe from the previous installs I did, but
it compiled and installed fine.
It also was able to install an egg:
$ chicken-install uri-common
fetching uri-common
fetching uri-generic
...
installing uri-common
which subsequently works in a csi shell:
#;2> (import uri-common)
; loading /usr/local/lib/chicken/11/uri-common.import.so ...
; ...
#;3> (uri->string (update-uri (uri-reference "") path: '("example"
"greeting") query: '((hi . "there"
"example/greeting?hi=there"
So I finally have an install that honours the unix paths.
In the MSYS shell, my versions are:
$ uname -a
MSYS_NT-10.0-19043 teeny 3.2.0-340.x86_64 2021-08-02 16:30 UTC x86_64 Msys
$ make --version
GNU Make 4.3
Built for x86_64-pc-msys
$ gcc --version
gcc (GCC) 10.2.0
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
> My patches had an error, instead of HANDLE there should have been > intptr_t Thanks Jani Firstly, I completely wiped all mingw64/msys2, and chocolatey installs from my PC before trying this. My system is absolutely pristine new installs, versions are as follows: $ uname -a MINGW64_NT-10.0-19043 mypcname 3.2.0-340.x86_64 2021-08-02 16:30 UTC x86_64 Msys $ make --version GNU Make 4.3 Built for x86_64-pc-msys $ gcc --version gcc.exe (Rev5, Built by MSYS2 project) 10.3.0 I applied that patch, and ran make. I'm doing this from within a MINGW64 shell, with the command: make PLATFORM=mingw-msys PREFIX=C:/msys64/usr/local make PLATFORM=mingw-msys PREFIX=C:/msys64/usr/local install After some initial issues with the fact I don't have chicken installed anywhere, and the scm files were trying to compile to c files with chicken, I had to rebuild 5.2.0 to get a working "chicken.exe" on my path so I could continue compiling chicken-5.3.0rc1 with your patch. Then I popped back into my 5.3.0rc1 directory with your patches, and compiled again. The compilation worked, and chicken-install appears to partially work. Certainly, make install finished without hanging this time (which itself runs -update-db). When I manually run chicken-install, it seems good: $ chicken-install -update-db loading import libraries ... generating database ... and checking where it thinks the repository is works: $ chicken-install -repository C:/msys64/usr/local/lib/chicken/11 However, when I actually try and install an egg, it fails: $ chicken-install uri-common fetching uri-common 'xcopy' is not recognized as an internal or external command, operable program or batch file. Error: (open-input-file) cannot open file - No such file or directory: "C:\\Users\\redacted\\AppData\\Local\\chicken-install\\uri-common\\uri-common.egg" It looks like it's mixing mingw64 for windows and mingw64/sys2 concepts. The "xcopy" error is from it thinking that's the system copy (instead of "cp" as I'm in msys2 environment) The path is then looking in my windows appdata local dir instead of the reported repository directory from "chicken-install -repository". So a step forward, but still no working chicken-install. Then, I cleaned, touched all scm files (to force a recompile of the c files) and remade the whole package, as this time it would be compiling with chicken-5.3.0 instead of 5.2.0 make clean confclean touch *.scm make PLATFORM=mingw-msys PREFIX=C:/msys64/usr/local make PLATFORM=mingw-msys PREFIX=C:/msys64/usr/local install This all worked, but still the same error trying to install an egg: $ chicken-install uri-common fetching uri-common 'xcopy' is not recognized as an internal or external command, operable program or batch file. Error: (open-input-file) cannot open file - No such file or directory: "C:\\Users\\redacted\\AppData\\Local\\chicken-install\\uri-common\\uri-common.egg" I just can't get this working. Mark
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
Hi,
My patches had an error, instead of HANDLE there should have been
intptr_t
diff -up chicken-5.3.0rc1/file.c.orig chicken-5.3.0rc1/file.c
--- chicken-5.3.0rc1/file.c.orig 2021-08-24 15:19:00.847104480 +0300
+++ chicken-5.3.0rc1/file.c 2021-08-24 15:36:10.889230349 +0300
@@ -46,7 +46,7 @@ struct dirent
typedef struct
{
struct _finddata_t fdata;
-int handle;
+intptr_thandle;
struct dirent current;
} DIR;
diff -up chicken-5.3.0rc1/file.scm.orig chicken-5.3.0rc1/file.scm
--- chicken-5.3.0rc1/file.scm.orig 2021-08-24 15:18:56.063761366 +0300
+++ chicken-5.3.0rc1/file.scm 2021-08-24 15:36:02.129211933 +0300
@@ -77,7 +77,7 @@ struct dirent
typedef struct
{
struct _finddata_t fdata;
-int handle;
+intptr_thandle;
struct dirent current;
} DIR;
diff -up chicken-5.3.0rc1/file.c.orig chicken-5.3.0rc1/file.c
--- chicken-5.3.0rc1/file.c.orig 2021-08-24 15:19:00.847104480 +0300
+++ chicken-5.3.0rc1/file.c 2021-08-24 15:36:10.889230349 +0300
@@ -34,7 +34,7 @@
# define C_mkdir(str) C_fix(mkdir(C_c_string(str)))
#endif
-#if !defined(_WIN32) || defined(__CYGWIN__)
+#if !defined(_WIN32) || defined(__CYGWIN__) || defined(__MINGW32__)
# include
# include
#else
@@ -46,7 +46,7 @@ struct dirent
typedef struct
{
struct _finddata_t fdata;
-int handle;
+intptr_thandle;
struct dirent current;
} DIR;
diff -up chicken-5.3.0rc1/file.scm.orig chicken-5.3.0rc1/file.scm
--- chicken-5.3.0rc1/file.scm.orig 2021-08-24 15:18:56.063761366 +0300
+++ chicken-5.3.0rc1/file.scm 2021-08-24 15:36:02.129211933 +0300
@@ -65,7 +65,7 @@
# define C_mkdir(str) C_fix(mkdir(C_c_string(str)))
#endif
-#if !defined(_WIN32) || defined(__CYGWIN__)
+#if !defined(_WIN32) || defined(__CYGWIN__) || defined(__MINGW32__)
# include
# include
#else
@@ -77,7 +77,7 @@ struct dirent
typedef struct
{
struct _finddata_t fdata;
-int handle;
+intptr_thandle;
struct dirent current;
} DIR;
Jani
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
Hi,
The following patch might make a difference,
diff -up chicken-5.3.0rc1/file.c.orig chicken-5.3.0rc1/file.c
--- chicken-5.3.0rc1/file.c.orig 2021-08-24 15:19:00.847104480 +0300
+++ chicken-5.3.0rc1/file.c 2021-08-24 15:36:10.889230349 +0300
@@ -46,7 +46,7 @@ struct dirent
typedef struct
{
struct _finddata_t fdata;
-int handle;
+HANDLE handle;
struct dirent current;
} DIR;
diff -up chicken-5.3.0rc1/file.scm.orig chicken-5.3.0rc1/file.scm
--- chicken-5.3.0rc1/file.scm.orig 2021-08-24 15:18:56.063761366 +0300
+++ chicken-5.3.0rc1/file.scm 2021-08-24 15:36:02.129211933 +0300
@@ -77,7 +77,7 @@ struct dirent
typedef struct
{
struct _finddata_t fdata;
-int handle;
+HANDLE handle;
struct dirent current;
} DIR;
Since mingw-w64 provides opendir and readdir implementations, this could also
work
diff -up chicken-5.3.0rc1/file.c.orig chicken-5.3.0rc1/file.c
--- chicken-5.3.0rc1/file.c.orig 2021-08-24 15:19:00.847104480 +0300
+++ chicken-5.3.0rc1/file.c 2021-08-24 15:36:10.889230349 +0300
@@ -34,7 +34,7 @@
# define C_mkdir(str) C_fix(mkdir(C_c_string(str)))
#endif
-#if !defined(_WIN32) || defined(__CYGWIN__)
+#if !defined(_WIN32) || defined(__CYGWIN__) || defined(__MINGW32__)
# include
# include
#else
@@ -46,7 +46,7 @@ struct dirent
typedef struct
{
struct _finddata_t fdata;
-int handle;
+HANDLE handle;
struct dirent current;
} DIR;
diff -up chicken-5.3.0rc1/file.scm.orig chicken-5.3.0rc1/file.scm
--- chicken-5.3.0rc1/file.scm.orig 2021-08-24 15:18:56.063761366 +0300
+++ chicken-5.3.0rc1/file.scm 2021-08-24 15:36:02.129211933 +0300
@@ -65,7 +65,7 @@
# define C_mkdir(str) C_fix(mkdir(C_c_string(str)))
#endif
-#if !defined(_WIN32) || defined(__CYGWIN__)
+#if !defined(_WIN32) || defined(__CYGWIN__) || defined(__MINGW32__)
# include
# include
#else
@@ -77,7 +77,7 @@ struct dirent
typedef struct
{
struct _finddata_t fdata;
-int handle;
+HANDLE handle;
struct dirent current;
} DIR;
At least that update-db doesn't get stuck on my computer (msys2,
mingw64/mingw-w64-x86_64-gcc 10.3.0-5).
Jani
Mark Fisher writes:
> Hi all,
>
> I'm on a new PC with windows 10 and thought I'd try getting a chicken
> environment up and running on MSYS2 MingGW-64.
>
> I've installed a fresh copy of msys2 and mingw64 from the msys2 site, doing
> the pacman updates on top.
>
> I've then followed the guide at http://wiki.call-cc.org/msys2 (except using
> 5.2.0 source instead) running under a MINGW64 terminal as advised.
>
> The compilation works fine, but when I run the install phase, the
> "chicken-install -update-db" just hangs:
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
Hey, Mark! I successfully installed Chicken on Windows off chocolatey just last week. To get around all of the requirements for the Unix programs I installed win-bash and put them on my path so it could use cp etc. like normal. For SRFI-18 specifically you do have to modify it from using the variables "CSI_PATH" and "CSC_PATH" to just csc and csi since Windows doesn't properly convert them from strings to the actual programs on that SRFI specifically for whatever reason. I've had 0 problems with coops and other SRFIs and packages aside from 18. - ArooBaito On Sun, Aug 22, 2021, 9:31 AM Mark Fisher wrote: > Thanks Peter. > > I messed up the threading on this conversation, and went into more details > elsewhere about my adventures into getting this working, and I've tried > more since. > > I've had no luck with the latest version (5.3.0rc2); I discovered (via > strace) that the created executable is internally loop crashing under gcc > 10.3 mingw64/msys2 > > Nor were my various attempts to downgrade mingw64 to gcc 10.2 in > (mingw64/msys2) successfully, it just failed to compile, but that's > probably because downgrading msys2 is difficult as you have to manually try > and apply downgraded packages. > > I tried compiling via mingw64 for windows (chocolatey instead of msys2), > which worked in compilation, but there's an issue with file paths mixing > windows and unix slash types. > > I then tried the chocolatey chicken package but the maintainer has > compiled it with incorrect flags, so the copy phase of eggs is broken (uses > "cp -r" instead of windows copy). I'm awaiting to see if that gets fixed ( > https://community.chocolatey.org/packages/chicken), but i'm not holding > my breath as there's several comments over recent months with the same > message (I at least feel I've tried to pinpoint the issue for the > maintainer though). > > I've tried at least 6 different methods to get chicken working on windows, > and they are all sadly broken in some way. > > It's an awful state. the docs (http://wiki.call-cc.org/msys2) still refer > to 5.0.0, and it simply doesn't work as written (I'm doing this on clean > installations of everything). I suspect gcc versions, but it doesn't feel > like anyone owns this, so there's no regular build on windows with latest > mingw64/msys2 to check. > > And in no way am I trying to start any implementation wars, but after > hours of this, in exasperation, I ran racket, and it just worked. > > Mark > > On Sun, 22 Aug 2021 at 17:00, Peter Bex wrote: > >> On Sat, Aug 21, 2021 at 12:14:51PM +0100, Mark Fisher wrote: >> > The compilation works fine, but when I run the install phase, the >> > "chicken-install -update-db" just hangs >> >> Hello Mark, >> >> I seem te remember something like this caused by Windows Defender (the >> virus scanner thing in Windows). If you turn it off, does that fix >> things? >> >> Also, if you have the time, please try the new 5.3.0 release candidate, >> to see if this works better. >> >> Cheers, >> Peter >> >
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
Thanks Peter. I messed up the threading on this conversation, and went into more details elsewhere about my adventures into getting this working, and I've tried more since. I've had no luck with the latest version (5.3.0rc2); I discovered (via strace) that the created executable is internally loop crashing under gcc 10.3 mingw64/msys2 Nor were my various attempts to downgrade mingw64 to gcc 10.2 in (mingw64/msys2) successfully, it just failed to compile, but that's probably because downgrading msys2 is difficult as you have to manually try and apply downgraded packages. I tried compiling via mingw64 for windows (chocolatey instead of msys2), which worked in compilation, but there's an issue with file paths mixing windows and unix slash types. I then tried the chocolatey chicken package but the maintainer has compiled it with incorrect flags, so the copy phase of eggs is broken (uses "cp -r" instead of windows copy). I'm awaiting to see if that gets fixed ( https://community.chocolatey.org/packages/chicken), but i'm not holding my breath as there's several comments over recent months with the same message (I at least feel I've tried to pinpoint the issue for the maintainer though). I've tried at least 6 different methods to get chicken working on windows, and they are all sadly broken in some way. It's an awful state. the docs (http://wiki.call-cc.org/msys2) still refer to 5.0.0, and it simply doesn't work as written (I'm doing this on clean installations of everything). I suspect gcc versions, but it doesn't feel like anyone owns this, so there's no regular build on windows with latest mingw64/msys2 to check. And in no way am I trying to start any implementation wars, but after hours of this, in exasperation, I ran racket, and it just worked. Mark On Sun, 22 Aug 2021 at 17:00, Peter Bex wrote: > On Sat, Aug 21, 2021 at 12:14:51PM +0100, Mark Fisher wrote: > > The compilation works fine, but when I run the install phase, the > > "chicken-install -update-db" just hangs > > Hello Mark, > > I seem te remember something like this caused by Windows Defender (the > virus scanner thing in Windows). If you turn it off, does that fix > things? > > Also, if you have the time, please try the new 5.3.0 release candidate, > to see if this works better. > > Cheers, > Peter >
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
On Sat, Aug 21, 2021 at 12:14:51PM +0100, Mark Fisher wrote: > The compilation works fine, but when I run the install phase, the > "chicken-install -update-db" just hangs Hello Mark, I seem te remember something like this caused by Windows Defender (the virus scanner thing in Windows). If you turn it off, does that fix things? Also, if you have the time, please try the new 5.3.0 release candidate, to see if this works better. Cheers, Peter signature.asc Description: PGP signature
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
Hi Mark, I installed Chicken successfully on Windows not too long ago, but unfortunately I've since switched my setup and I don't know what your issue might be. However looking at the wiki instructions I do remember that I didn't install Chicken 'in' msys, if that makes sense, but from a 'normal' Windows command shell. Maybe there's some network issue with msys -- could Windows be blocking it? cheers, George
Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
Hi all, I'm on a new PC with windows 10 and thought I'd try getting a chicken environment up and running on MSYS2 MingGW-64. I've installed a fresh copy of msys2 and mingw64 from the msys2 site, doing the pacman updates on top. I've then followed the guide at http://wiki.call-cc.org/msys2 (except using 5.2.0 source instead) running under a MINGW64 terminal as advised. The compilation works fine, but when I run the install phase, the "chicken-install -update-db" just hangs: cp -r chicken.tcp.import.so "C:/msys64/usr/local//lib/chicken/11" cp -r chicken.compiler.user-pass.import.so "C:/msys64/usr/local//lib/chicken/11" C:/msys64/usr/local//bin/chicken-install -update-db I left it for an age, and checked if it was doing network activity, which it doesn't seem to be. opening another window, csi seems to work, but I can't install any eggs, presumably because the chicken db is not being built. markj@teeny MINGW64 ~ $ winpty csi -p '(+ 1 1)' 2 markj@teeny MINGW64 ~ $ chicken-install -s srfi-18 Error: extension or version not found: "srfi-18" Any advice on getting chicken-install working, or how to work out why it's hanging? Thanks, Mark
