-
Notifications
You must be signed in to change notification settings - Fork 3
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
Habemus Macam #82
Habemus Macam #82
Conversation
This looks like it's working on macOS Silicon as well, I am able to run |
@soleti Could you also try the version in the |
Also works. |
This branch uses clang on Linux, and stdenv (g++) on Darwin. Over in Which one do we prefer? (I'll add the
g++ also spews an absurd amount of warnings. There is also #17. |
Apparently, not. |
Will it still be ugly once the upstream fix is in place? There is one advantage of keeping g++ on darwin and that's that we don't ignore g++, which we have been doing for a while. As you say:
When I get some time I will explore what's going on with that in a separate branch
I guess this has to do with the different interpretations of |
Once the upstream fix is in place, it should look exactly like it did before we touched anything, but now it should work. Currently the clang 16 env on Darwin uses a different version of libc++ from everything else, that's what was causing our problems. After the fix, it should use the same version. IIUC. So our old flake should Just Work.
I guess we should just add it to GHA. Off the top of my head, it should be possible to have a default devShell with clang, and a second one with gcc. Then it should be possible to invoke the latter explicitly with something like |
9daac46
to
8d6d851
Compare
Fixed. I've left the gcc-on-darwin-clang-on-linux solution in the history, for reference, and replaced it with the patch-clang-on-darwin-to-use-libc++-11 approach. This avoids using g++, so the compile-time tests now pass. I suggest that we merge, and deal with g++ related issues (broken compile-time tests, running g++ on GHA) in a separate PR. |
if(APPLE) | ||
target_link_options(Nain4 PRIVATE -undefined dynamic_lookup) | ||
endif() | ||
|
||
if(APPLE) | ||
target_link_options(client_exe PRIVATE -undefined dynamic_lookup) | ||
endif() |
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 is Nain4 a target here? this is a client, shouldn't need to mess with Nain4's link options.
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.
I don't know why it's needed, but here is the proof that it is needed.
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.
Ah, I think we go back again to the issue where fetchcontent grabs the last tag, not the current branch.
#67
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.
Ugh.
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.
Can we have a commit changing GIT_TAG
to your branch to convince ourselves that it's the only issue?
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.
So we'd have to add the if-apple-then-dynamic-lookup gubbins somewhere in there?
Yes, that absolutely needs to go in.
Anything else?
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.
dealing with stupid macos is not a nain4 problem
Unfortunately, in the harsh Real World, it is very much our problem.
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.
I can't think of anything else. Just remember to revert 9d9d552.
We can provide a CMake function for our clients to do if-apple-then-dynamic-lookup more conveniently, but that will probably not work out of the box and deserves its own PR.
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.
The macos build is passing the tests. This means that the networkless recompilation test is not working as expected. My guess is that the command we use to restrict network usage is not working on macos. This means that it's allowed to use the network, fetch the branch and recompile, thus passing the test. But this is not supposed to happen.
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.
And, I can confirm that this is the issue:
sudo: iptables: command not found
There seems to be a linking problem in macOS now? |
Yes, we're going around in circles. Let's summarize:
|
I see two options:
I don't have a strong preference. |
What do you consider to be the offending lines? I don't think there are any (unless you're referring to the apple dynamic links in the client-side tests, whose removal I have finally managed to push, so they are not there any more). If I've got that right, then we
done. |
Yes, I was referring to that. I'm not very focused today. Your plan works. Let's go ahead. |
You or me? I can do it, if you haven't started yet. |
Go for it. |
Closes #15.
The remaining problems against which we were banging our heads recently, were caused by linking multiple versions of libc++, which was caused by the dependencies (G4 and Qt) and the client code using different compiler configurations.
The solution1 is to use the gcc environment rather than the clang one in the flake's
devShell
. This is only necessary on Darwin, but (for now) it has been changed on Linux too.The change to gcc breaks the compile-time tests we added recently (which have been removed, to make GHA pass).
Thus, before we can merge this, we have to:
@soleti this has been tested on macOS on Intel, but we do not have access to Apple Silicon, so it would be good if you could check that it works there too.
(Why is the macOS GHA so slow? The one I've been waiting for before submitting this PR, completed on Linux in under 9 minutes, the macOS one chugged along for muuuch longer and then failed spuriously, so I had to restart it. Then it took another 21 minutes.)
Footnotes
This solution is temporary: a fix is in the pipeline upstream. ↩