-
Notifications
You must be signed in to change notification settings - Fork 87
Update README with macOS build instructions #1810
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
base: master
Are you sure you want to change the base?
Conversation
Added macOS build instructions to README.
Flamefire
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the information and your tests!
I'd like to focus on making it possible to build it on macOS out of the box like on any other system. We do have Intel macOS builds and I guess @Flow86 could add builds and downloads for arm64 too. That would require ensuring it works at all for which your insights will be helpful.
So I added a couple questions with the aim to know why non-default CMake options can are required and how those issues can be resolved in code instead.
README.md
Outdated
| -DCMAKE_BUILD_TYPE=Release \ | ||
| -DCMAKE_OSX_ARCHITECTURES=arm64 \ | ||
| -DCMAKE_PREFIX_PATH="/opt/homebrew" \ | ||
| -DENABLE_TESTS=OFF \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This likely doesn't has any effect. Which issue does this solve?
README.md
Outdated
| -DCMAKE_OSX_ARCHITECTURES=arm64 \ | ||
| -DCMAKE_PREFIX_PATH="/opt/homebrew" \ | ||
| -DENABLE_TESTS=OFF \ | ||
| -DCMAKE_CXX_FLAGS="-std=c++17 \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is better done by -DCMAKE_CXX_STANDARD=17, but why do it anyway? The CMake files already ensure this is done. Have you tried without that?
README.md
Outdated
| -Wno-error=missing-noreturn \ | ||
| -Wno-error=deprecated-copy \ | ||
| -Wno-error=unused-parameter \ | ||
| -Wno-error=undef \ | ||
| -Wno-error=cast-qual" .. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you really need that? If so we should fix it in the code so they are not required.
Can you use -DRTTR_ENABLE_WERROR=OFF and post the list of those warnings please?
README.md
Outdated
| mkdir -p build && cd build | ||
| cmake .. \ | ||
| -DCMAKE_BUILD_TYPE=Release \ | ||
| -DCMAKE_OSX_ARCHITECTURES=arm64 \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why doesn't it work without that? We have code that should ensure it works out of the box
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CMAKE_OSX_ARCHITECTURES may not contain arm64 by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By default it is empty. In that case we detect the supported architectures including arm64: https://github.com/Return-To-The-Roots/libutil/blob/7198609c21eae58c31cee5e88c76dc3eddea603f/cmake/DetectOsXArchs.cmake#L61
We then use CMAKE_SYSTEM_PROCESSOR to select that or all available archs. That is set to uname -m by CMake.
So my question is what exactly fails in the current workflow such that we can improve it for everyone.
I can't, I think there were some issues cross compiling some of the dependencies and/or getting the arm64 build to work |
|
I pulled the repo again and now I get this error if I try to compile: ccache is installed. macOS 26. |
|
You need a recursive clone or init and update the submodules |
|
Ok I did recurse. Now building starts but stopps here (9%): |
|
This is this issue: boostorg/move#61 I'm wondering why warning inside system libs are triggered though. |
|
Got it!
If anyone of your team has a M device could test my build: |
Can you use
I can't see how: We already compile RTTR with C++17 so I don't see what difference this makes especially not 10x. Any idea?
Can you explain that? What is accessed exactly? |
|
Without -DCMAKE_PREFIX_PATH="/opt/homebrew" by the way now I don't need to exclude /usr/local explicit for some reason ... strange. Ok without C++17 Parameter it compiles now as the same speed. Don't know what was the problem before that it was kinda slow. If i put only
it drops this error and stopps (it accessed /usr/local which is wrong?): |
|
Here the complete log |
|
Ok so all warnings are from inside Boost in /usr/local. However it finds a homebrew Boost:
This shouldn't happen but could explain the warnings. Do the paths in the config files under I also can't see where the How exactly is your But most important is the Boost-location thing. If you run with |
if you set |
|
All in
points to ../../Cellar. Ok so far. Here I added logs from all scenarios. The given cmake parameters are at the top. compile1.log And by the way .... with it compiles fine now. If I try without the PATH of homebrew it fails. One important thing: To get the dylib linkings in the .app "independent" I do this: |
Just seen you are using ccache in the builds so the 10x might be because of the warm ccache cache and the relation to adding that flag just chance. Would then have been the same when removing the flag after initially adding it.
Is it possible that Boost isn't properly installed? Can you try cmake with
So I guess your system isn't arm64 then?
We use a CMake module for that for our releases. It gets activated with |
is missing. I compiled with
Here is the log I'm on an ARM System here (M4 Max). |
|
I tried the "make install" method and got this: If I copy the 2 SDL FW to the Build Folder: it continues but stuck here: |
I see, that's not a compiled library anymore which might be the reason. Check e.g. boost_headers. I'm looking for something like: I see Is there a
So you are supposedly compiling for the same system you are on? Or is this not an arm64 system? Otherwise I don't understand how the files like /usr/local/lib/libboost_unit_test_framework.dylib /usr/local/Cellar/libsamplerate/0.2.2/lib/libsamplerate.dylib don't contain symbols for the architecture they are installed for. Any ideas?
Found an open issue for this: https://discourse.cmake.org/t/unable-to-resolve-rpath-not-found/5325 -.- |
|
I recognized that pkg-config was not installed for arm64. Did it now. Than in .bashrc only this was there:
changed it to
All /opt/homebrew but it´s still stopping here and seeking in /usr/local: stream.hpp is in place This here is an arm64 System. Apple Silicon is always arm64. |
|
Ok so the files are there but not used for some reason. Did you check You can try to reproduce with a MWE:
The first 2 should somewhere in the output show the filepath to
Then there must be a problem with this specific system: Why would x86 system files be installed there:
Is it possible that those files were copied from another system? |
|
That's my CPATH:
And here MWE: No the files are fresh from brew. I have /usr/local too because I did crosscompiling for another apps/projects as Universal Binary. Installed it with
|
|
Ok, that helps a lot.
That seems to be your Remove that and it should take the correct boost headers.
I'm not so used to macos multi-arch but it seems /usr/local is for the x64 (rosetta) files and /opt/homebrew for arm. So that is expected and we need CMake to search the arm folder first. You can do that with |
Added macOS build instructions to README.