Closed ryandesign closed 2 years ago
This looks like it's being compiled in C++17 mode against an STL that isn't C++17 capable. (as it's failing to find the over-aligned new and delete operators)
You think so? It is using -std=gnu++14
...
For comparison, here is the log of the successful build on OS X El Capitan 10.11 and the successful build on macOS High Sierra 10.13.
Perhaps it's relevant: The differences in cmake output are:
On 10.11: -- Performing Test COMPILER_HAS_W_NOEXCEPT_TYPE - Failed
On 10.12: -- Performing Test COMPILER_HAS_W_NOEXCEPT_TYPE - Failed
On 10.13: -- Performing Test COMPILER_HAS_W_NOEXCEPT_TYPE - Success
On 10.11: -- Performing Test COMPILER_HAS_F_ALIGNED_NEW - Failed
On 10.12: -- Performing Test COMPILER_HAS_F_ALIGNED_NEW - Success
On 10.13: -- Performing Test COMPILER_HAS_F_ALIGNED_NEW - Success
On 10.11: -- Looking for clock_gettime - not found
On 10.12: -- Looking for clock_gettime - found
On 10.13: -- Looking for clock_gettime - found
If I use -DCOMPILER_HAS_F_ALIGNED_NEW=OFF
on macOS Sierra, the build does succeed.
Hi!
I have a very similar error building Folly 2018.12.03.00 over XCode 9 + apple-clang 9.0 + libc++. All build steps are executed well, but when I try to link Folly I get:
Undefined symbols for architecture x86_64:
"operator delete(void*, std::align_val_t)", referenced from:
folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::allocNextSegment(folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::Segment*) in libfolly.a(Future.cpp.o)
folly::hazptr_deleter<folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::Segment, std::__1::default_delete<folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::Segment> >::delete_obj(folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::Segment*) in libfolly.a(Future.cpp.o)
folly::hazptr_domain<std::__1::atomic>::free_hazptr_recs() in libfolly.a(Hazptr.cpp.o)
folly::TimedDrivableExecutor::~TimedDrivableExecutor() in libfolly.a(TimedDrivableExecutor.cpp.o)
folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::reclaimRemainingSegments() in libfolly.a(TimedDrivableExecutor.cpp.o)
folly::hazptr_deleter<folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::Segment, std::__1::default_delete<folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::Segment> >::delete_obj(folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::Segment*) in libfolly.a(TimedDrivableExecutor.cpp.o)
folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::allocNextSegment(folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::Segment*) in libfolly.a(TimedDrivableExecutor.cpp.o)
...
"operator new(unsigned long, std::align_val_t)", referenced from:
folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::allocNextSegment(folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::Segment*) in libfolly.a(Future.cpp.o)
folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::allocNextSegment(folly::UnboundedQueue<folly::Function<void ()>, false, true, true, 8ul, 7ul, std::__1::atomic>::Segment*) in libfolly.a(TimedDrivableExecutor.cpp.o)
folly::hazptr_domain<std::__1::atomic>::acquire_new_hprec() in libfolly.a(TimedDrivableExecutor.cpp.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/test_package] Error 1
make[1]: *** [CMakeFiles/test_package.dir/all] Error 2
make: *** [all] Error 2
I already tried, but no success:
The full log can be found here
How could I build Folly with XCode 9.0?
I forgot about this issue, and I guess the developer did too. Maybe we can revisit it now and get it fixed.
How could I build Folly with XCode 9.0?
If you look at my comment immediately above yours, I mentioned that you can build it by using the cmake flag -DCOMPILER_HAS_F_ALIGNED_NEW=OFF
.
Doing some Google research now, I found two bug reports (https://github.com/android-ndk/ndk/issues/421, https://www.veripool.org/issues/1231) that both seem to suggest that the version of Clang in Xcode 9 supports aligned new, but that the version of libc++ on macOS Sierra does not support it. So, in the cmake test where it checks if aligned new is supported, it needs to check not only if the compiler supports it but also if a program using it can be linked.
If you look at my comment immediately above yours, I mentioned that you can build it by using the cmake flag
-DCOMPILER_HAS_F_ALIGNED_NEW=OFF
.
Sorry, I did not see that you said you had already tried that. I cannot explain why that didn't work.
Well, I have two scenarios, the first one is building a minimal Folly, without Google Snappy and many other dependencies, it works well, so I'm able to build Folly using XCode 9.0.
However, when I build Folly with all dependencies, including google snappy, that error occurs. According the cmake file, snappy is used to compressor feature only. I checked snappy build and it doesn't set any flag related to alignment. As you can see in that job, there are many dependencies included:
All of these libraries are linked as static. I might think that the error comes from a transitive dependency, but I'm sure all of these dependencies are used by many other projects and have never seen this error before.
I forgot about this issue, and I guess the developer did too. Maybe we can revisit it now and get it fixed.
How could I build Folly with XCode 9.0?
If you look at my comment immediately above yours, I mentioned that you can build it by using the cmake flag
-DCOMPILER_HAS_F_ALIGNED_NEW=OFF
.
In fact the configure makes a test for it:
-- Performing Test COMPILER_HAS_F_ALIGNED_NEW - Failed
Presumably it should disable it accordingly.
We only support the two most recent named versions of OSX, currently 11 (Big Sur) and 12 (Monterey)
The aligned-new checks are just dead code at this point, since aligned new and delete are a requirement of C++14.
Building folly 2018.05.28.00 fails on macOS Sierra (10.12, Xcode 9.2 Build version 9C40b, "Apple LLVM version 9.0.0 (clang-900.0.39.2)"):
This is odd because the build succeeds both on the older OS X El Capitan (10.11, Xcode 8.2.1 Build version 8C1002, "Apple LLVM version 8.0.0 (clang-800.0.42.1)") and the newer macOS High Sierra (10.13, Xcode 9.4 Build version 9F1027a, "Apple LLVM version 9.1.0 (clang-902.0.39.2)").