Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows and Mac OS extension #5

Open
fverdugo opened this issue Mar 24, 2020 · 35 comments
Open

Windows and Mac OS extension #5

fverdugo opened this issue Mar 24, 2020 · 35 comments
Labels
help wanted Extra attention is needed

Comments

@fverdugo
Copy link
Member

Some potential users are willing to use MiniQhull from Windows and presumably also from Mac OS, but the project is only tested for Linux. See this thread: https://discourse.julialang.org/t/delaunay-triangularization/36172/13

Is somebody in the Julia community ready to help us with the Windows and / or the mac OS extension? Feel free to fork and open a PR. Thanks!

@fverdugo fverdugo added the help wanted Extra attention is needed label Mar 24, 2020
@ueliwechsler
Copy link

I have no experience with Cmake and wrapping c-libraries in general, so I cannot offer direct help, but since I have a windows mache, I can try to figure out where the problem lies, i.e. where the build breaks.

On windows, I get the following build.log ( i have set a environmental variable to QHULL_ROOT_DIR = C:\sw_source\qhull-2019.1` which is the home folder of ghull)

-- Building for: Visual Studio 14 2015
-- Selecting Windows SDK version  to target Windows 10.0.18362.
-- The C compiler identification is MSVC 19.0.24215.1
...
-- CMAKE_C_FLAGS_DEBUG: /MDd /Zi /Ob0 /Od /RTC1
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
QHULL_qhull_r_INCLUDE_DIR (ADVANCED)
   used as include directory in directory C:/Users/wueli/.julia/dev/MiniQhull/deps/MiniQhullWrapper
   ...
   used as include directory in directory C:/Users/wueli/.julia/dev/MiniQhull/deps/MiniQhullWrapper/src/tests
QHULL_qhull_r_LIBRARY (ADVANCED)
    linked by target "MiniQhullWrapper" in directory C:/Users/wueli/.julia/dev/MiniQhull/deps/MiniQhullWrapper/src/lib

-- Configuring incomplete, errors occurred!
See also "C:/Users/wueli/.julia/dev/MiniQhull/deps/MiniQhullWrapper/build/CMakeFiles/CMakeOutput.log".
[ Info: MiniQhullWrapper root directory at: 
...
┌ Info: QHULL configuration:
│ ==============================================
│   - QHULL_WRAPPER_FOUND    = false
│   - QHULL_WRAPPER_LIB_DIR  = 
│   - QHULL_WRAPPER_LIB_NAME = 
└   - QHULL_WRAPPER_LIB_PATH = 

So apparently, the QHULL_qhull_r_INCLUDE_DIR variable does not exist or is empty. Going further, I see that in the CMakeCache.txt this error results because the QHULL_ROOT_DIR variable is not set.

//Directory to search for Qhull
QHULL_ROOT_DIR:PATH=

//Path to a file.
QHULL_qhull_r_INCLUDE_DIR:PATH=QHULL_qhull_r_INCLUDE_DIR-NOTFOUND
...

I think this variable should be set in FindQhull.cmake where

set(QHULL_ROOT_DIR
    "${QHULL_ROOT_DIR}"
    CACHE PATH "Directory to search for Qhull")

I assume that the FindQhull.cmake file is called in this part of CMakeLists.txt

#################################################################
# FIND QHULL
#################################################################

FIND_PACKAGE(Qhull REQUIRED)
INCLUDE_DIRECTORIES(${INCLUDE_PATH} ${QHULL_qhull_r_INCLUDE_DIR})

However, at this point, I don't know how to proceed and set QHULL_ROOT_DIR to the environmental variable. Maybe this is already of help.

@fverdugo
Copy link
Member Author

fverdugo commented Apr 1, 2020

Thanks @ueliwechsler for reporting.

It is strange that

//Directory to search for Qhull
QHULL_ROOT_DIR:PATH=

appears empty in your cache file even though you have set the corresponding environment variable. @victorsndvg any idea of what is going on?

@victorsndvg
Copy link
Contributor

Dear @ueliwechsler ,

first of all, can you confirm that the environment variable is set within your Julia environment?

I mean,

julia> ENV["QHULL_ROOT_DIR"] == "C:\sw_source\qhull-2019.1"

If true, please try to instantiate and build the MiniQhull project again;

pkg> intantiate
pkg> build

is it still failing after these steps?

@ueliwechsler
Copy link

So I tried it again on another windows computer, the result is still the same.

image

And the qhull installation is here:

image

@victorsndvg
Copy link
Contributor

Dear @ueliwechsler ,

the content of C:\sw_source\qhull-2019.1 (picture) is the sources code directory, NOT the installation directory.

Maybe your Qhull library has been installed at C:\sw_source\qhull-2019.1\qhull-2019.1?

Please, fix the QHULL_ROOT_DIR variable (pointing to the right Qhull install directory) and try again.

Anyway, we have no tested it under Windows, not sure if it will work.

@ueliwechsler
Copy link

I am not sure if I understand correctly what you mean by installation directory.
The qhull exacutable are located in bin, so I also tried to set the path to bin and I get the same result. So I assume, it does not work for windows in the current configuration.
C:\sw_source\qhull-2019.1\qhull-2019.1 is a copy of C:\sw_source\qhull-2019.1 it should not matter.

@djlacombe
Copy link

I tried to build Qhull using Visual Studio C++ by opening the Qhull solution file for the 64 bit build (i.e. the .sln file) and received the following log file:

-- Building for: NMake Makefiles
-- The C compiler identification is unknown
CMake Error at CMakeLists.txt:5 (PROJECT):
  The CMAKE_C_COMPILER:

    cl

  is not a full path and was not found in the PATH.

  To use the NMake generator with Visual C++, cmake must be run from a shell
  that can use the compiler cl from the command line.  This environment is
  unable to invoke the cl compiler.  To fix this problem, run cmake from the
  Visual Studio Command Prompt (vcvarsall.bat).

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
  the compiler, or to the compiler name if it is in the PATH.

-- Configuring incomplete, errors occurred!
See also "C:/Users/dolacomb.TTU-305138/.julia/packages/MiniQhull/unUAX/deps/MiniQhullWrapper/build/CMakeFiles/CMakeOutput.log".
See also "C:/Users/dolacomb.TTU-305138/.julia/packages/MiniQhull/unUAX/deps/MiniQhullWrapper/build/CMakeFiles/CMakeError.log".
[ Info: MiniQhullWrapper root directory at: C:\Users\dolacomb.TTU-305138\.julia\packages\MiniQhull\unUAX\deps\MiniQhullWrapper
┌ Warning: You should have entered a numeric value
└ @ Main C:\Users\dolacomb.TTU-305138\.julia\packages\MiniQhull\unUAX\deps\build.jl:46
┌ Warning: MiniQhullWrapper lib directory not found: 
└ @ Main C:\Users\dolacomb.TTU-305138\.julia\packages\MiniQhull\unUAX\deps\build.jl:60
┌ Warning: MiniQhullWrapper library not found: ["libMiniQhullWrapper.dll"]
└ @ Main C:\Users\dolacomb.TTU-305138\.julia\packages\MiniQhull\unUAX\deps\build.jl:68
┌ Info: QHULL configuration:
│ ==============================================
│   - QHULL_WRAPPER_FOUND    = false
│   - QHULL_WRAPPER_LIB_DIR  = 
│   - QHULL_WRAPPER_LIB_NAME = 
└   - QHULL_WRAPPER_LIB_PATH = 

I'm not sure how to proceed but this may provide some additional info. If anyone can help me out, I can try to find a solution.

@victorsndvg
Copy link
Contributor

Dear @djlacombe ,

I've never used Visual Studio and I don't know how it works. It seems that that found/selected C compiler is not working or at least cannot be used from Visual Studio.

Please, follow the recommendations :

To use the NMake generator with Visual C++, cmake must be run from a shell
that can use the compiler cl from the command line. This environment is
unable to invoke the cl compiler. To fix this problem, run cmake from the
Visual Studio Command Prompt (vcvarsall.bat).

Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.

or choose another C compiler if possible.

@victorsndvg
Copy link
Contributor

Dear @ueliwechsler ,

MiniQull (and in particular MiniQhullWrapper and findQhull.cmake file) does not look for the Qhull binary file. In particular they are looking for the following files:

  • Relative path pointing to headers (only informative): libqhull_r/libqhull_r.h
  • Relative path pointing to the library file with this name (without extension): qhull_r, libqhull_r, qhullstatic_r or libqhullstatic_r.

If you are under windows, I suppose library extensions can be .dll (for dynamic libraries) or .lib for static libraries.

Please, once you find these files, can you report their full path to try to recommend you a valid QHULL_ROOT_DIR?

@ueliwechsler
Copy link

@victorsndvg thanks for the the clarificication and sorry for the late reply.

The first file is at

  • ...\qhull-2019.1\src\libqhull_r\libqhull_r.h
    From the library files, I could only find:
  • ....\qhull-2019.1\bin\qhull_r.dll
    The other files: libqhull_r,qhullstatic_r and libqhullstatic_r are either a .pro, a c-source or a c header file and all located in ....\qhull-2019.1\src.

Note, I did download and used the version which is available here: http://www.qhull.org/download/qhull-2019.1.zip.

@victorsndvg
Copy link
Contributor

Dear @ueliwechsler ,

only one question, did you install Qhull? I mean, did you run make install?

If you run it at the Qhull source directory root, it create the .\lib at the install directory? At least, this is how it works on linux.

If previous step does not change anything I have a last try to make it work.

Can you please replace the following line in your MiniQhull local repository?

https://github.com/gridap/MiniQhull.jl/blob/master/deps/build.jl#L26

and change this:

        configure  = run(`$cmake -B $QHULL_WRAPPER_BUILD -S $QHULL_WRAPPER_SOURCES`)

by:

        configure  = run(`$cmake -DQHULL_qhull_r_LIBRARY=FULL-PATH-TO-QHULL-LIBRARY -B $QHULL_WRAPPER_BUILD -S $QHULL_WRAPPER_SOURCES`)

where:
FULL-PATH-TO-QHULL-LIBRARY, in your particular case, is C:\sw_source\qhull-2019.1\bin\qhull_r.dll, if I'm not wrong.

Hope it works!

@ueliwechsler
Copy link

Hi @victorsndvg , thank you for your effort and information, but it did not work.
I did not do the make install before because I assumed it is not needed. I tried to run make install and it failed with

C:\sw_source\qhull-2019.1>make install
==========================================
==== If ar fails, try make qhullx ====
==========================================
ar -rs lib/libqhullstatic.a src/libqhullstatic/global.o src/libqhullstatic/stat.o src/libqhullstatic/geom2.o src/libqhullstatic/poly2.o src/libqhullstatic/merge.o src/libqhullstatic/libqhull.o src/libqhullstatic/geom.o src/libqhullstatic/poly.o src/libqhullstatic/qset.o src/libqhullstatic/mem.o src/libqhullstatic/random.o src/libqhullstatic/usermem.o src/libqhullstatic/userprintf.o src/libqhullstatic/io.o src/libqhullstatic/user.o src/libqhullstatic/rboxlib.o src/libqhullstatic/userprintf_rbox.o
ar: lib/libqhullstatic.a: No such file or directory
make: *** [Makefile:680: lib/libqhullstatic.a] Error 1

Unfortunately, your other fix did also not help. I am afraid my knowledge is not good enough to really understand what exactly is going on.

@victorsndvg
Copy link
Contributor

Sorry @ueliwechsler ,

we have not designed the package to be used on Windows yet.

As soon as we got it working on windows we will comment in this issue again.

Thanks for reporting!

@oriolcg
Copy link
Member

oriolcg commented Sep 5, 2020

Hi @victorsndvg ,

I'm trying to see if I can get this thing working in Windows. I've managed to get the correct QHULL_ROOT_DIR, since I'm using a julia version >= 1.3, everything is well defined within the .julia folder. CMake is able to find all the qhull include dirs where the *.h files are located. The problem comes when trying to find the library using

Here it looks for *.lib files and the lib files are either *.dll or *.dll.a. If I go to this files and manually change the extension to *.lib it works ✌️ . However, it fails latter when linking to MiniQhullWrapper.dll which I cannot manually change to MiniQhullWrapper.lib because it's rewritten everytime I build.

My question is: is there any way for CMake to check for *.dll instead of *.lib?

Thank you!

@fverdugo
Copy link
Member Author

fverdugo commented Sep 7, 2020

Hi @oriolcg,

Since some months, @victorsndvg is working full time in another company. It is likely that he cannot help with this anymore.

@oriolcg
Copy link
Member

oriolcg commented Sep 7, 2020

Ups... OK, I'll see if I can figure it out by myself. In any case, if someone else has any insights or wants to help, it will be very much appreciated

@victorsndvg
Copy link
Contributor

Hi @oriolcg ,

this project was only tested under linux. I think it should be not too much dificult to use it under windows ... but I really don't figure out the steps to do it.

I don't know too much about linking in windows, but I think it's a little bit different to linux. Maybe I'm wrong, but I think that windows dynamic libraries (dll) need a "pseudostatic" library (lib) in order to be "easily" linked.

So, I think you need to recompile QHull library to obtain both, dynamic dlls and static libs. This is why CMake try to find lib files. Is this possible?

The other possible workaround is to use Mingw to compile both, QHull and MiniQHullWrapper. I think this is the selected choice in Qhull_jll.

Hope that helps!

Best!

@oriolcg
Copy link
Member

oriolcg commented Sep 8, 2020

Hi @victorsndvg ,

Thanks for the reply! If I compile the QHull library with VS I get both ".dll" and ".lib" and MiniQhull finds the libraries. However, I still have the same problem with "MiniQhullWrapper". I tried to modify the build.jl script, but still having problems with Libdl.find_library(). I'll keep investigating and see if I can fix the problem.

@victorsndvg
Copy link
Contributor

Ok, then, if I understood correctly, the problem is that MiniQhullWrapper only generates the dll file in windows, right?

I've found the following post. I think it could be helpful, hopefully.

https://gitlab.kitware.com/cmake/community/-/wikis/doc/tutorials/BuildingWinDLL

Let me know if it works ;)

@oriolcg
Copy link
Member

oriolcg commented Sep 13, 2020

Ok, then, if I understood correctly, the problem is that MiniQhullWrapper only generates the dll file in windows, right?

Yes. However, Libdl.find_library(...) should be able to find it with the "*.dll" and it's not finding it. I've checked to use it directly and it does not find anything, and I don't understand why.

I also tried the fix on the link, but didn't help.

I guess that for now I'll have to assume that this is not going to work soon on Windows...

@joa-quim
Copy link

joa-quim commented Oct 6, 2020

I managed to build the MiniQhullWrapper.dll but the module is not working yet due to another cmake that I don't understand,

     Creating library C:/Users/joaqu/.julia/packages/MiniQhull/TRNh0/deps/MiniQhullWrapper/build/lib/Debug/MiniQhullWrapper.lib and object C:/Users/joaqu/.julia/packages/MiniQhull/TRNh0/deps/MiniQhullWrapper/build/lib/Debug/MiniQhullWrapper.exp
  MiniQhullWrapper.vcxproj -> C:\Users\joaqu\.julia\packages\MiniQhull\TRNh0\deps\MiniQhullWrapper\build\lib\Debug\MiniQhullWrapper.dll
  Building Custom Rule C:/Users/joaqu/.julia/packages/MiniQhull/TRNh0/deps/MiniQhullWrapper/src/tests/CMakeLists.txt
  testqhullwrapper.c
  testqhullwrapper.vcxproj -> C:\Users\joaqu\.julia\packages\MiniQhull\TRNh0\deps\MiniQhullWrapper\build\bin\Debug\testqhullwrapper.exe
  Building Custom Rule C:/Users/joaqu/.julia/packages/MiniQhull/TRNh0/deps/MiniQhullWrapper/CMakeLists.txt
Microsoft (R) Build Engine version 16.7.0+b89cb5fde for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

MSBUILD : error MSB1009: Project file does not exist.
Switch: test.vcxproj
[ Info: MiniQhullWrapper root directory at: C:\Users\joaqu\.julia\packages\MiniQhull\TRNh0\deps\MiniQhullWrapper
┌ Warning: Something wrong has happened while building MiniQhullWrapper
â”” @ Main C:\Users\joaqu\.julia\packages\MiniQhull\TRNh0\deps\build.jl:55
┌ Info: QHULL configuration:
│ ==============================================
│   - QHULL_WRAPPER_FOUND    = false
│   - QHULL_WRAPPER_LIB_DIR  = C:\Users\joaqu\.julia\packages\MiniQhull\TRNh0\deps\MiniQhullWrapper\build\lib
│   - QHULL_WRAPPER_LIB_NAME = 
â””   - QHULL_WRAPPER_LIB_PATH = 

And what did I do?

  • Built Qhull from source
  • Set the julia> ENV["QHULL_ROOT_DIR"] = C:\\programs\\compa_libs\\qhull\\compileds\\VC14_64
  • run ] build MiniQhull

On Windows one always link against a *.lib. Now, there are two types of .lib: the static libs and the so called import libs (*.lib.a I think if the dll was build with MinGW). The latter are to be used when the code will link against a dll on runtime.
And more. By default the symbols in a library are not exported by default, meaning that the ccall mechanism will not work if calls any of a non-exported function. This means that the qhullwrapper.c would not work on Windows. So I changed it (plus another change because /dev/null is a pure unix thing) and I'm attaching it as a zip file at the end of this post (sorry, too lazy to go through a PR process).

I actually made it work by compiling it directly as

cl /c /nologo qhullwrapper.c -IC:\programs\compa_libs\qhull\compileds\VC14_64\include
link /out:qhullwrapper.dll /dll C:\programs\compa_libs\qhull\compileds\VC14_64\lib\qhull_r.lib qhullwrapper.obj

and then editing the .jl files to use the qhullwrapper.dll directly

And now to finish I have a question. I tried to reproduce this Matlab example but got 18 triangles instead of the 12 in the Matlab example. The excess are due to fact that each cube face is decomposed into 4 triangles instead of two. Why is that?

julia> Tes = delaunay(X)'
18×4 LinearAlgebra.Adjoint{Int32,Array{Int32,2}}:
 4  2  3  1
 4  9  3  1
 4  9  2  1
 7  5  3  1
 7  9  3  1
 7  9  5  1
 7  4  8  3
 7  4  9  3
 7  4  8  9
 6  5  2  1
 6  9  2  1
 6  9  5  1
 6  4  8  2
 6  4  9  2
 6  4  8  9
 6  7  8  5
 6  7  9  5
 6  7  8  9

qhullwrapper.zip

@eschnett
Copy link
Contributor

FWIW – I am using MiniQhull.jl on MacOS, and it's working fine out of the box. This is with Julia 1.5, which uses Qhull_jll.

@eschnett
Copy link
Contributor

Would it make sense to rewrite the C code in MiniQhull in Julia? It's less than 150 lines, the code looks straightforward, and (with Qhull_jll) this would then work on any system, any architecture, without having to install anything.

@stevengj
Copy link
Contributor

stevengj commented Nov 20, 2020

The main annoyance seems to be that you will need to replicate the huge struct qhT data structure in Julia.

On the other hand, this isn't that bad if you at least semi-automate the translation, and since you depend on the Qhull_jll package then you only need to be compatible with a single version of qhull. In principle you could use Clang.jl.

@stevengj
Copy link
Contributor

stevengj commented Nov 20, 2020

The Clang output looks usable: https://gist.github.com/stevengj/0cf9bcc9f338ad8fcf78e5862d4ff851

I just ran

     using Clang, Qhull_jll
     wc = init(; headers = [Qhull_jll.user_r_h, Qhull_jll.mem_r_h, Qhull_jll.qset_r_h, Qhull_jll.stat_r_h, Qhull_jll.libqhull_r_h],
              output_file = joinpath(@__DIR__, "libqhull_out.jl"),
              common_file = joinpath(@__DIR__, "libqhull_common.jl"),
              header_wrapped = (root, current)->root == current,
              header_library = x->"libqhull"
              )
     run(wc)

@stevengj
Copy link
Contributor

stevengj commented Nov 20, 2020

One thing that worries me from the above translation is that I get

julia> sizeof(LibQhull.qhT)
7136

but adding printf("sizeof (struct qhT) = %zu bytes\n", sizeof (struct qhT)); to deps/MiniQhullWrapper/src/tests/testqhullwrapper.c prints a different size:

sizeof (struct qhT) = 8592 bytes

@Gnimuc, am I using Clang.jl incorrectly here? Why is it not giving the same sizeof?

@eschnett
Copy link
Contributor

I see the type jmp_buf in the libqhull.h source code. This type is translated to Cint. That looks wrong – it should be much larger.

@stevengj
Copy link
Contributor

@eschnett, good catch. Maybe we can store sizeof(jmp_buf) in Qhull_jll somehow, since this is platform/ABI-dependent (maybe compiler-dependent?).

@stevengj
Copy link
Contributor

sizeof(jmp_buf) == 148 on my system, but when I use NTuple{148,UInt8} for the jmp_buf fields I get a size of 7568 bytes, so there must be other problems.

@stevengj
Copy link
Contributor

Hmm, Clang doesn't handle union types properly. In particular, intrealT should be a union { int, double } so it should be sizeof(double), but Clang makes it a Cint.

Changing that increases the size to 8608 bytes, which is now too big! Possibly there is an alignment mismatch somewhere due to the differences in types.

Grrr, a pure-Julia wrapper is going to be more of a pain than I thought.

Maybe it would be better to package a minimal C wrapper as a jll file. Mainly, it needs to be able to allocate a struct qhT* and provide accessors for various key user-accessible fields.

@Gnimuc
Copy link

Gnimuc commented Nov 21, 2020

Changing that increases the size to 8608 bytes, which is now too big! Possibly there is an alignment mismatch somewhere due to the differences in types.

This reminds me JuliaInterop/Clang.jl#238. For now, it's not trivial to map this kinda nested records from C to Julia due to the mismatched padding behavior. https://github.com/analytech-solutions/CBinding.jl is worth a try but JuliaLang/julia#35795 seems to be the future. Another way is to generate a struct that only contains an NTuple field and then emulates the field accessing behavior by overloading Base.getproperty. However, clang_Cursor_getOffsetOfField runs during "compile"-time, so multiplatform support is still a problem.

@eschnett
Copy link
Contributor

It might be easiest to smuggle a few additional functions into the build script for the qhull_jll library. This way, one ensures that the same system/compiler/build options are used, so that the struct size is correct, and this way one also automatically benefits from whatever cmake/configure magic is used to build and link correctly.

@Gnimuc
Copy link

Gnimuc commented Apr 4, 2021

@stevengj @eschnett I just tried to regenerate the bindings with Clang.jl's new generator.

using Clang.Generators
using Qhull_jll
include_dir = joinpath(Qhull_jll.artifact_dir, "include")
options = Dict("general"=>Dict("library_name" => "libqhull", "output_file_path" => "libqhull.jl", "module_name" => "LibQhull"), "codegen"=>Dict{String,Any}("field_access_method_list"=>["qhT"], "macro"=>Dict("macro_mode" => "none")))
ctx = create_context(Qhull_jll.libqhull_r_h, ["-I$include_dir"], options)
@add_def jmp_buf
build!(ctx)

The script generates a libqhull.jl file in the current directory. After manually adding const jmp_buf = NTuple{148,UInt8} at the top of the file, run


julia> using CEnum

julia> include("libqhull.jl")
WARNING: replacing module LibQhull.
Main.LibQhull

julia> LibQhull.qhstatT |> sizeof
5344

julia> LibQhull.qhT |> sizeof
8608

I think the size is correct, as the Clang compiler's getoffsetof tells the same thing:

f === :qhstat && return Ptr{qhstatT}(x + 3264)

the last field of qhT has an offset of 3264 and the size of qhstatT is 5344, which gives 5344+3264=8608.

@eschnett
Copy link
Contributor

eschnett commented Apr 4, 2021

@Gnimuc On which architectures did you check this? The value might depend on the system and/or the CPU architecture.

Is there a way to check this at build time?

@Gnimuc
Copy link

Gnimuc commented Apr 5, 2021

@Gnimuc On which architectures did you check this? The value might depend on the system and/or the CPU architecture.

It was tested on macOS.

Is there a way to check this at build time?

Maybe use C11's static_assert?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

9 participants