MSYS2 or MS Windows Build?

[snunez1]

I've just successfully built c2ffi on MS Windows and MSYS2, but get zero output. With a .h file, or just calling it without any parameters, it just exits without doing anything.

Anyone have any ideas?

[rpav]

Dumb Q but did you compile as a console app / console subsystem.. not sure how msys builds by default and I don't have the usual windows thing in there. I would sortof hope msys2 does the right thing, but... does c2ffi -h show help?

[snunez1]

I built it with all the defaults (i.e. I didn't change anything). Also confirmed the clang version, built with gcc as well, all with the same result. c2ffi -h doesn't output anything.

[snunez1]

Any ideas? It seems that a -mconsole option might be worth trying, but it's not clear where/how to add such an option.

[rpav]

Err right; maybe try a couple things as a test:

# Test if it's actually running normally.. if not try a debugger
$ ./c2ffi -h ; echo $?

# If this returns 0, maybe:
$ winpty ./c2ffi -h

I'm not sure why this would require winpty though. If the first returns 0 and the second does nothing, try to see if a simple printf("hello world\n"); program works in C, and if so std::cout << "hello world\n"; in C++. If the above for c2ffi fails, and those work... we'll at least have narrowed the problem to "something pretty weird".

[snunez1]

$ ./c2ffi.exe -h ; echo $?
127

Is this known to work with MSVC? Installing that toolchain might be another option.

[rpav]

It probably won't as it uses getopt(). This was hacked together before I seriously got back into C++ so sadly it could use a bit of a complete rewrite. (OTOH, it compiles pretty quick.)

If this returns 127, try gdb and see if it crashes / get a backtrace.

I'll see if I can try this build myself; I actually have MSYS2 on here.

[rpav]

OK the good news is, I have a clang-18.1 c2ffi that builds and works in MSYS2.

I don't really have any bad news.

[rpav]

Well, I haven't tested in Linux so someone might want to do that.

[rpav]

I've pushed the branch; you should be able to git checkout v18.1.0 and try building. If you have trouble just note the packages and config I used. Let me know if you have other issues.

[snunez1]

Did something happen to the make file? cmake doesn't seem to be producing on in the build/ directory.

[snunez1]

I see that MS Windows build doesn't use make, will open new issue with ninja.

[snunez1]

Issue remains, even when compiling with the latest clang 18 branch and compiler value:

$ ./c2ffi.exe -h ; echo $?
127

A bit of searching suggests that 127 may indicate 'command not found'. Could any of the warnings/errors in cmake be the cause of that?

$ cmake -G Ninja ..
-- Config: -Release
-- CXX Compiler: GNU
-- Building for Win32-x64
-- Found LLVM 18.1.3
-- LLVM installed in C:/msys64/mingw64
-- Using LLVMConfig.cmake in: C:/msys64/mingw64/lib/cmake/llvm
-- c2ffi c++std: -std=c++17
CMake Warning at CMake/setup_post_project.cmake:34 (message):
  (Can't enable sanitizers on c2ffi
Call Stack (most recent call first):
  CMake/setup_post_project.cmake:101 (__target_sanitize)
  CMake/setup_post_project.cmake:107 (ProcessDir)
  CMake/setup_post_project.cmake:114 (MapDirs)
  CMakeLists.txt:76 (SetupPost)

**   C++ flags:  -W -Wall -Wextra -Wno-unused-label -Wno-unused-parameter -Werror=return-type -Werror=unused-result
**   C++ debug    flags:  -O1 -ggdb2 -fno-omit-frame-pointer
**   C++ rwdi     flags: -O2 -ggdb2 -fno-omit-frame-pointer -DNDEBUG
**   C++ release  flags: -O3 -DNDEBUG
**   Link flags:
**   Link debug flags:
**
**   This build: Release
-- Configuring done (0.5s)
-- Generating done (0.1s)
-- Build files have been written to: S:/src/c2ffi/build

[snunez1]

A bit of progress. When attempting to run from a cmd window, the claim is that libLLVM-18.dll and libclang-cpp.dll are missing. They are not. This may explain the exit code 127, but doesn't explain why the system would think they are missing. I get same exit-no-output if I run in PowerShell (but now pop-ups indicating the missing DLLs).

Any ideas?

[snunez1]

The above theory, about DLL's, doesn't seem correct.

ldd ./c2ffi.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc4f010000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffc4dc10000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffc4cbd0000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffc4d200000)
        libgcc_s_seh-1.dll => /c/Program Files/GTK2-Runtime Win64/bin/libgcc_s_seh-1.dll (0x61440000)
        libstdc++-6.dll => /c/Program Files/GTK2-Runtime Win64/bin/libstdc++-6.dll (0x6fc40000)

        libclang-cpp.dll => /mingw64/bin/libclang-cpp.dll (0x7ffb41980000)
        libLLVM-18.dll => /mingw64/bin/libLLVM-18.dll (0x7ffb27f40000)

        ADVAPI32.dll => /c/WINDOWS/System32/ADVAPI32.dll (0x7ffc4e890000)
        sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7ffc4e7d0000)
        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ffc4d820000)
        bcrypt.dll => /c/WINDOWS/System32/bcrypt.dll (0x7ffc4cb70000)
        libwinpthread-1.dll => /c/Program Files/GTK2-Runtime Win64/bin/libwinpthread-1.dll (0x64940000)
        libwinpthread-1.dll => /c/Program Files/GTK2-Runtime Win64/bin/libwinpthread-1.dll (0xa0000)
        ole32.dll => /c/WINDOWS/System32/ole32.dll (0x7ffc4d9f0000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ffc4c6c0000)
        combase.dll => /c/WINDOWS/System32/combase.dll (0x7ffc4e9f0000)
        GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ffc4db80000)
        win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ffc4cba0000)
        gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ffc4ced0000)
        VERSION.dll => /c/WINDOWS/SYSTEM32/VERSION.dll (0x7ffc45d80000)
        msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ffc4ca40000)
        USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ffc4ee30000)
        SHELL32.dll => /c/WINDOWS/System32/SHELL32.dll (0x7ffc4e060000)

Though it does seem rather odd that cmd woujld report these as missing.

[snunez1]

Then again, maybe it is so, but why?

(gdb) run
Starting program: S:\src\c2ffi\build\bin\c2ffi.exe
[New Thread 16640.0xa488]
[New Thread 16640.0xa644]
[New Thread 16640.0x61d0]
[Thread 16640.0x61d0 exited with code 3221225785]
[Thread 16640.0xafd4 exited with code 3221225785]
[Thread 16640.0xa644 exited with code 3221225785]
During startup program exited with code 0xc0000139.

Which is supposed to be related to a DLL. I'll continue tomorrow, but if you know a fast way to check or workaround this issue I'd love to hear it.

[rpav]

Not sure; for me:

$ ldd bin/c2ffi.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffb30f50000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffb2f010000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffb2e850000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffb301b0000)
        libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x7ffb1c6c0000)
        libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x7ffae55f0000)
        libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x7ffb13690000)
        libclang-cpp.dll => /mingw64/bin/libclang-cpp.dll (0x7ffaa34b0000)
        libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x125bbe20000)
        VERSION.dll => /c/WINDOWS/SYSTEM32/VERSION.dll (0x7ffb26f20000)
        libLLVM-18.dll => /mingw64/bin/libLLVM-18.dll (0x7ffa9c440000)
        ADVAPI32.dll => /c/WINDOWS/System32/ADVAPI32.dll (0x7ffb2f270000)
        libLLVM-18.dll => /mingw64/bin/libLLVM-18.dll (0x125bbe20000)
        sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7ffb2f580000)
        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ffb2fc40000)
        ole32.dll => /c/WINDOWS/System32/ole32.dll (0x7ffb2f430000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ffb2e630000)
        combase.dll => /c/WINDOWS/System32/combase.dll (0x7ffb2fd70000)
        GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ffb300d0000)
        win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ffb2ef80000)
        libffi-8.dll => /mingw64/bin/libffi-8.dll (0x7ffb13670000)
        gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ffb2e730000)
        msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ffb2eb80000)
        USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ffb302c0000)
        SHELL32.dll => /c/WINDOWS/System32/SHELL32.dll (0x7ffb30730000)
        WS2_32.dll => /c/WINDOWS/System32/WS2_32.dll (0x7ffb30250000)
        zlib1.dll => /mingw64/bin/zlib1.dll (0x7ffb0fc50000)
        libxml2-2.dll => /mingw64/bin/libxml2-2.dll (0x7ffae54b0000)
        libzstd.dll => /mingw64/bin/libzstd.dll (0x7ffae4e00000)
        liblzma-5.dll => /mingw64/bin/liblzma-5.dll (0x7ffb0e680000)
        libiconv-2.dll => /mingw64/bin/libiconv-2.dll (0x7ffae4ce0000)

The things pointing at GTK2-Runtime... seem weird; maybe try making those normal.

I build/run this in a MSYS2 MINGW64 terminal, not cmd; if I run in cmd it definitely complains about missing DLLs.

[snunez1]

Why is your executable loading different DLL's? Should cmake have accounted for and warned for anything it needs but isn't there?

[snunez1]

The problem was having the MSVC DLL's in the PATH before the MSYS2 ones. I think as a matter of good practice, in future, it is best to keep MSVC and Cygwin completely separate; use MSVC from PowerShell and don't mix. In reality though, doing this when also trying to maintain a Python environment may take some bit of work in keeping everything in order. Some Python packages are challenging in a pure MS Windows environment. VM's can't access the GPU, so if you want any CUDA libs from Python, you're pretty much out of luck.