Support MacOS #46
Comments
|
I have access to a MacMini which we use internally for CD purposes. |
|
Seems like |
|
It does support concepts, I've got it building in the CI (link), just chasing down a segfault which only occures on windows, only with clang, and gives a different error code each time (and which ends in a different position in the call stack/different dll entirely). What might be a bit more of an issue is coroutines, msvc has the TS implemented apparently and GCC has had the full since 10, clang though has had "partial" support since 8 and apparently nothing more on it yet. It doesn't like the "lambda in unevaluated expression" though, so I've had to move those to seperate structs. It doesn't seem to support TLS with boost< 1.76.0 though, gives a ~12mb log at the end of which are some redefinition errors about |
Well, as discussed here, coroutines usage will be something for the future anyway, right? As far as I know there is currently no code depending on coroutines.
If you change those, I'd say keep the current code but just commented out, add a comment as to why that is and add the workaround implementation below that.
As I'm only a few minutes away from a pizza, all I can say to this at the moment is: lol 😛🍕 |
|
Update on this, I think the segfault is due to a mismatch between the |
|
Ok so libc++ 12 does not support concepts, I'm guessing thats what you ran into above. 13 does but msys doesn't have it yet... this is insane, I haven't had this much trouble with getting a toolchain working since I first started learning C++. My feat-clang-build branch builds fine on linux/clang, and also in msys (but segfaults when running the tests), should I just make the CI build with clang on linux and hold off on msys till it gets libc++13? |
Exactly.
Yes, I do think that it's very valuable to add the CI tests for clang13 on the corresponding platforms and ignore msys2 for now.
Trust me - I feel you there... |
I like msys2 personally, after getting back into it for this with more linux experience it really is quite nice. My issues so far are with the toolchains, mingw has only ever been slow and/or buggy for me. Although I guess the
afaik nothing has clang13 yet, its the trunk version. arch doesn't for sure so I doubt anything else will. Is there a particular reason why we can't only support MSVC on windows? I know its historically been quite slow with change but its now neck-and-neck with gcc for implemenation of 20 and ahead of clang |
|
As you mentioned the main problem arises from the toolchains provided by MSYS2. The devel is in the detail tho: PROVIDED by MSYS2. I ran into several conflicts (especially in the early days of MSYS2 tho) where environments were colliding if not carefully manually setting everything up). As far as I can tell it's also very difficult - if not impossible - to have several toolchains (or other packages, eg boost) with different versions under MSYS2. While it might work technically under the hood (doubtful) the way the packages are built & distributed doesn't allow choosing versions via
Exactly because of historical reasons 🙈
Communication problems. I'm good with your initial idea to provide clang CI for Linux for now. |
If you mean could we link stuff compiled with older MSVC to this library compiled with modern MSVC, the docs say "yes as along as its one of 2015, 2017, or 2019". If its whether we can link msvc-dlls to non-msvc compiled applications I'm guessing no since C++ has no standard ABI but I'm not sure. |
|
Yeah... I think I won't be able to migrate some of the projects away from MinGW any time soon. So unfortunately I am stuck with the requirement that this library builds with MinGW on Windows :/ |
|
I quickly tried to compile this on a Mac:
|
|
mhmm, libc++12 has no |
|
Ah yeah - this was discussed lengthy before - brain fart 🤦 Time to figure out how to use |
|
Just an update on this, I tried compiling |
|
So, lets get back to this... I'm currently on FreeBSD 13.0-RELEASE. I tried to compile |
|
I'm able to compile I've simply used the The next step from my side is to test this on an actual MacOS system. |
|
I had another go at this today. I got malloy to compile, link & run successfully on an x86 MacOS 12.4 machine. Using homebrew, the following packages were installed:
After that, I ran CMake like this: Manually specifying the C++ compiler was necessary as CMake would otherwise default to the system's compiler. However, at this point CMake complained about the compiler test not succeeding. This was due to the fact that CMake/LLVM was still picking up the incorrect Once MacOS ships with a decent version of Clang this should no longer be necessary. |
|
I tested this today and yesterday on two separate MacBooks. I manually downloaded On the second MacBook I installed On both tests I did NOT have to manually set |
|
@astrobatman That is great news! Which version(s) of MacOS are those two machines running? |
We have reports of using this library successfully out-of-the-box on a MacOS machine. Ref #46
|
Both MacBooks were running macOS 12.4. |
|
Awesome, thanks for the info. |
This is mostly for tracking.
MacOS should probably be supported, as clang catches up to msvc and gcc it should be easier/feasible to support clang and by extension mac. I'm currently working on getting to clang to compile
malloy, but even then I doubt it will work straight off aslibc++has very different (and generally cleaner) transitive includes to libstdc++ (and microsofts version too I guess). I can setup clang to uselibc++on my linux box, but theres still differences. Therefore we at least need the CI to build mac and preferably also someone who actually has a mac box who can contribute.The text was updated successfully, but these errors were encountered: