-
Notifications
You must be signed in to change notification settings - Fork 67
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
Request: consider splitting out time_generator functionality / adding a cmake option? #169
Comments
I agree that a CMake option seems the best way to approach this. Clang under Linux using libstdc++ very likely needs -latomic as well, I'm not sure about Clang/Linux using libc++. I don't see a simple way to detect the stdlib. One can always do a configure check, I suppose. My CMake CI only uses the system compiler, so testing for GCC was enough to make it pass. |
Looks like -latomic is required on Linux even when using libc++: https://godbolt.org/z/hKv1z89aE |
For reference on our eccentric toolchain; we use GCC + libstdc++ or Clang + libc++ (no "cross"), for historical (and, despite issues, quirky) reasons. So yeah, needed under clang + libc++ (bad timing between my response and you looking into it). |
CMake option added to develop. |
Merged to master. |
uuid/CMakeLists.txt
Lines 25 to 29 in e7fcbc1
It's unclear if the above lines are correct (considering I needed to manually change the tests on Clang to link against libatomic; but this may be an artifact of my organization's eccentric toolchain); however, by forcing all downstream consumers to link against
libatomic
on GCC; even those that don't use the time_generator functionality, this makes the library unsuitable for some high-performance environments (in our case; we intentionally don't link againstlibatomic
since we want to use the intrinsics at all times or fail, and we do not supplylibatomic
on production machines for the same reason).I was originally going to suggest relying on autolinking, but then found out that apparently GCC doesn't support it.
For what it's worth, I've gone the cmake-option route in our (fork? fork feels like the wrong term but I guess it's accurate?).
It's also possible that simply using Boost.Atomic instead of STL atomics would suffice as well (I'm unfamiliar with what Boost.Atomic does in such an environment / if it in some way also relies on
libatomic
).The text was updated successfully, but these errors were encountered: