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