gator
Deep Blooper
Posts: 24
|
Post by gator on May 12, 2022 3:13:03 GMT
I get the same behavior locally and on the build machine, so maybe there's something in your setup I'm not aware of. As far as I understand, the source of the issue is that WIN32 isn't defined when compiling. so at /src/mkit/as/input.c (83), the code defines the include path separator as : and not ; Or perhaps there's something in your setup that I'm not aware of! For a start, if the GCC compiler isn't automatically setting WIN32 ... then you're not actually running Msys2's mingw-w64 GCC compiler. "gcc -dM -E - </dev/null | grep WIN32" should display the 4 variations of WIN32 that gcc defines by default when running on a Windows machine. If you're running in Microsoft's "Windows Subsystem for Linux" ... I can't help you, that's not Msys2! A simple ... cd /usr/local git clone https://github.com/jbrandwood/huc.git cd huc make
... works fine for me on a Win64 machine. Now, you do need to run msys2_shell.cmd with the "-mingw64" parameter in order for it to set up the compiler, else gawd knows where your GCC installation is coming from.
Depending upon how you installed Msys2, that may or may not be the default for your setup Ok, let's continue with the investigation From a clean environment (read GitHub VMs with mysys2 preinstalled), I am running the following commands C:\msys64\msys2_shell.cmd -mingw64 -no-start -defterm -c "pacman -S base-devel gcc git --noconfirm" C:\msys64\msys2_shell.cmd -mingw64 -no-start -defterm -where %CD% -c "make" and still, end up with the same error. That really weird. If I run the "gcc -dM -E - </dev/null | grep WIN32" command, no WIN32 shows up, but I do see a __CYGWIN__ defined (I managed to see the 4 WIN32 define if I add a -mwin32 to the actual call to GCC but that's it) Am I installing the proper gcc package with pacman ? FWIW, HuC also builds fine on a Linux machine, and even a Mac now apparently, just as long as GNU Make is your default, and not Mac OS's (BSD?) Make.
It indeed fails and it's using the make bundled with XCode it seems. I'm not familiar with the Mac environment. What's the proper way to get the gnumake installed ? (reproducible and headless ) I haven't tried the Windows subsystem yet, only plain ubuntu so far (but I confirm 18.04 and 20.04 are building well) Anyway ... how on earth are you getting a "/usr/local/lib/huc/*" directory? Just found some references to these paths in the code when loading the content of the PCE_INCLUDE, false lead
|
|
|
Post by dshadoff on May 12, 2022 3:34:39 GMT
Well that's odd. What does your 'gcc -v' report ?
I installed MSYS2 on one machine quite a while ago, and it reports: gcc version 10.2.0 (Rev6, Built by MSYS2 project)
I installed MSYS2 much more recently on another machine, and it does not have a gcc installed... (although I separately installed a cross-compiler for another purpose, it is not simply 'gcc'). Are you sure you're not picking up some sort of residual gcc in your path from another product installation (or transplant of profile) ? If you have cygwin referecnes, it sounds plausible.
|
|
|
Post by elmer on May 12, 2022 3:40:23 GMT
If I run the "gcc -dM -E - </dev/null | grep WIN32" command, no WIN32 shows up, but I do see a __CYGWIN__ defined (I managed to see the 4 WIN32 define if I add a -mwin32 to the actual call to GCC but that's it) Am I installing the proper gcc package with pacman ? If you're seeing __CYGWIN__, then there's a CYGWIN version of GCC somewhere in your path that's being used instead of Msys2's version of GCC. May I suggest that you walk before trying to run, and stop relying on someone else's virtual machine for the moment, and just try to get things working on your own computer. If you can do that, then you'll be in a better position to debug whatever is going on the VM context. If you install a clean Msys2 on your 64-bit Windows computer, then I believe that you need at-least the "base-devel", "git" and "mingw-w64-x86_64-toolchain" packages. If you're building on a 32-bit computer, the packages are slightly different ... and IIRC, 32-bit versions of msys32 are pretty-much on life-support these days.
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 12, 2022 3:47:29 GMT
Quite a bit different here C:\tools\msys64\msys2_shell.cmd -mingw64 -no-start -defterm -c "gcc -v" Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-msys/11.2.0/lto-wrapper.exe Target: x86_64-pc-msys Configured with: /c/S/gcc/src/gcc-11.2.0/configure --build=x86_64-pc-msys --prefix=/usr --libexecdir=/usr/lib --enable-bootstrap --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --with-arch=x86-64 --with-tune=generic --disable-multilib --enable-__cxa_atexit --with-dwarf2 --enable-languages=c,c++,fortran,lto --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --disable-libssp --disable-win32-registry --disable-symvers --with-gnu-ld --with-gnu-as --disable-isl-version-check --enable-checking=release --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.2.0 (GCC) I also checked the real location of GCC (/usr/bin/gcc) and it's actually located in C:\tools\msys64\usr\bin\gcc
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 12, 2022 3:57:51 GMT
ok, that did the trick. Using pacman, I uninstalled the package gcc and instead installed mingw-w64-x86_64-toolchain instead And now it's working
|
|
|
Post by elmer on May 12, 2022 16:59:31 GMT
And now it's working Yep, it definitely helps to use the right compiler!
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 13, 2022 4:38:23 GMT
Ok, finally got a full green on all platforms On windows, I'm trying to keep the environment as lean as possible, and mingw-w64-x86_64-toolchain is installing a lot of things not really needed to build the project. So I installed mingw-w64-x86_64-gcc instead, and saved about 2 min of build time. Build is still happily green after that. Is it ok to leave it like that ? On the mac side, I used the brew command to get gmake installed. (brew install make) And I just invoke gmake instead of make (so no fuzzy magic going on) Is this the right way to do it ?
|
|
|
Post by dshadoff on May 13, 2022 15:38:11 GMT
So I installed mingw-w64-x86_64-gcc instead, and saved about 2 min of build time. Build is still happily green after that. Is it ok to leave it like that ? Most likely. For this, unless the build process has changed radically since I last had hands in it, I don’t think anything more than gcc and make are used.
|
|
|
Post by elmer on May 14, 2022 0:22:14 GMT
Ok, finally got a full green on all platforms Woohoo, congratulations! On windows, I'm trying to keep the environment as lean as possible, and mingw-w64-x86_64-toolchain is installing a lot of things not really needed to build the project. So I installed mingw-w64-x86_64-gcc instead, and saved about 2 min of build time. Build is still happily green after that. Is it ok to leave it like that ? If it builds and then compiles the examples, I think that you've won! There's no need to overthink it until someone actually tries one of these automatic builds to see if the example projects actually work in an emulator. On the mac side, I used the brew command to get gmake installed. (brew install make) And I just invoke gmake instead of make (so no fuzzy magic going on) Is this the right way to do it ? Gawd knows, I don't have a Mac ... but it sure *sounds* a lot like what the Mac guy did. Again, if it builds and then compiles the examples, I think that you've won! If you're feeling adventurous, then the next step would be to actually run the HuC test-suite that Uli added. AFAIK it only runs on linux, and definitely NOT on Windows, and you'll probably need to install a couple of extra packages on linux ... but it does a good job of testing a lot of the core functionality of HuC. You can find it in the huc/test directory.
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 14, 2022 1:30:42 GMT
Ok, PR coming your way Next I have the static code analysis to activate, but this requires a token to interact with CodeQL. All is setup in my repo, but I think we'll need to setup yours to have it run automatically. So far, 5 issues were raised, and easily fixable. Running the tests automatically will be the next challenge Looks like we're not using an actual test framework (Nunit, XUnit, PYTest, etc), and if I'm ready this correctly, it's only trying to compile the c files in the folder. This will tell us if the compile step is ok, but we don't know if we introduced a regression in the generated asm, right ?
|
|
|
Post by elmer on May 14, 2022 1:37:07 GMT
Looks like we're not using an actual test framework (Nunit, XUnit, PYTest, etc), and if I'm ready this correctly, it's only trying to compile the c files in the folder. This will tell us if the compile step is ok, but we don't know if we introduced a regression in the generated asm, right ? Yes, it's a test framework ... it's just older than those newfangled thingies. It runs the HuC-generated code in the tgemu that HuC builds, and then makes sure that the result is OK, not really any different to any other test framework, except that it doesn't require a ton of external stuff.
|
|
|
Post by elmer on May 24, 2022 15:33:32 GMT
Thanks to gator 's hard work, we now have CI (continuous integration) active in the HuC repo, which also runs the complete HuC testsuite to find bugs. This will hopefully be a big step in helping us find regressions (bugs) quicker while we're working on improving HuC.
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 24, 2022 22:35:42 GMT
A pleasure to help There are still many improvements I'd like to add, but it's a good start. Hopefully, regressions will become a thing of the past, and Huc users will be more comfortable blindly updating to more recent versions, as long as the first digit of the version doesn't change (and versioning is another debate ) BTW, elmer, I just realized CodeQL needs to be activated in your repo settings (Settings / Code Scanning / Enable). On my side, I left the Check Failure to "High or higher Only errors" for now
|
|
|
Post by elmer on May 24, 2022 22:38:06 GMT
OK, thanks, I'll do that!
I also need to figure out how to get the automated-build packages showing up in github.
You mentioned that I needed to do something, but I've obviously not done it yet, because I can see them begin made, but they're not downloadable.
|
|
|
Post by elmer on May 24, 2022 22:45:36 GMT
OK, thanks, I'll do that! Hmmmm ... it was already enabled. That must have been set by one of your pull-requests.
|
|