Skip to content
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.

Sign up for GitHub

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

Jump to bottom

semaphore file not found i macos #45

Closed
Mirocos opened this issue Aug 19, 2021 · 16 comments
Closed

semaphore file not found i macos #45

Mirocos opened this issue Aug 19, 2021 · 16 comments

Comments

@Mirocos
Copy link

Mirocos commented Aug 19, 2021

Hi, I checkout to branch 'develop' and tried to build this project.
Compiler shows that semaphore.h can not be found.

Mojave 10.14
Clang-10

concurrencpp/executors/thread_pool_executor.h:9:10: fatal error: 'semaphore' file not found
[build] #include <semaphore>
@David-Haim
Copy link
Owner

Hi again
the library is supported with clang 11 and above
clang 10 is unfortunately not supported.

does the problem go away if you upgrade clang?

@Mirocos
Copy link
Author

Mirocos commented Aug 19, 2021

Hi again
the library is supported with clang 11 and above
clang 10 is unfortunately not supported.

does the problem go away if you upgrade clang?

all right, I need to upgrade my clang and check again.

@Mirocos
Copy link
Author

Mirocos commented Aug 19, 2021

Hi again
the library is supported with clang 11 and above
clang 10 is unfortunately not supported.

does the problem go away if you upgrade clang?

Hi, I upgrade my clang to clang-12, and semaphore.h can be found. However, there is still some compile error like below:

/concurrencpp/source/executors/worker_thread_executor.cpp:42:21: error: 'acquire' is unavailable
[build]         m_semaphore.acquire();
[build]                     ^
[build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:202:10: note: 'acquire' has been explicitly marked unavailable here
[build]     void acquire()
[build]          ^
[build] /Users/mirocos/master/study/concurrencpp/source/executors/worker_thread_executor.cpp:106:21: error: 'release' is unavailable
[build]         m_semaphore.release();
[build]                     ^
[build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:197:10: note: 'release' has been explicitly marked unavailable here
[build]     void release(ptrdiff_t __update = 1)
[build]          ^
[build] /Users/mirocos/master/study/concurrencpp/source/executors/worker_thread_executor.cpp:121:21: error: 'release' is unavailable
[build]         m_semaphore.release();
[build]                     ^
[build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:197:10: note: 'release' has been explicitly marked unavailable here
[build]     void release(ptrdiff_t __update = 1)
[build]          ^
[build] /Users/mirocos/master/study/concurrencpp/source/executors/worker_thread_executor.cpp:160:17: error: 'release' is unavailable
[build]     m_semaphore.release();
[build]                 ^
[build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:197:10: note: 'release' has been explicitly marked unavailable here
[build]     void release(ptrdiff_t __update = 1)
[build]          ^
[build] /Users/mirocos/master/study/concurrencpp/source/executors/thread_pool_executor.cpp:218:26: error: 'try_acquire_until' is unavailable
[build]         if (!m_semaphore.try_acquire_until(deadline)) {
[build]                          ^
[build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:219:10: note: 'try_acquire_until' has been explicitly marked unavailable here
[build]     bool try_acquire_until(chrono::time_point<Clock, Duration> const& __abs_time)
[build]          ^
[build] /Users/mirocos/master/study/concurrencpp/source/executors/thread_pool_executor.cpp:218:26: error: 'try_acquire_until<std::__1::chrono::steady_clock, std::__1::chrono::duration<long long, std::__1::ratio<1, 1000000000>>>' is unavailable
[build]         if (!m_semaphore.try_acquire_until(deadline)) {
[build]                          ^
[build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:219:10: note: 'try_acquire_until<std::__1::chrono::steady_clock, std::__1::chrono::duration<long long, std::__1::ratio<1, 1000000000>>>' has been explicitly marked unavailable here
[build]     bool try_acquire_until(chrono::time_point<Clock, Duration> const& __abs_time)
[build]          ^
[build] /Users/mirocos/master/study/concurrencpp/source/executors/thread_pool_executor.cpp:322:25: error: 'release' is unavailable
[build]             m_semaphore.release();
[build]                         ^
[build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:197:10: note: 'release' has been explicitly marked unavailable here
[build]     void release(ptrdiff_t __update = 1)
[build]          ^
[build] /Users/mirocos/master/study/concurrencpp/source/executors/thread_pool_executor.cpp:420:17: error: 'release' is unavailable
[build]     m_semaphore.release();
[build]                 ^
[build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:197:10: note: 'release' has been explicitly marked unavailable here
[build]     void release(ptrdiff_t __update = 1)
[build]          ^
[build] 4 errors generated.

@David-Haim
Copy link
Owner

Interesting. I'll take a look at it.

@David-Haim
Copy link
Owner

If you checkout semaphore_polyfill branch, does it compile?

@Mirocos
Copy link
Author

Mirocos commented Aug 20, 2021

If you checkout semaphore_polyfill branch, does it compile?

Unfortunately not, same error with branch 'develop'

@Mirocos
Copy link
Author

Mirocos commented Aug 27, 2021

Sorry, Any advices?

@David-Haim
Copy link
Owner

I have a way to fix it. Wait patiently, good things come slow :)

@David-Haim
Copy link
Owner

Can you checkout macos_semaphore branch and try to build it?
thanks.

@Mirocos
Copy link
Author

Mirocos commented Aug 31, 2021

Yes, it works, thanks a lot!!!

@David-Haim
Copy link
Owner

OK, next step: can you try to compile and run the tests the way it's detailed here?

Try to run and build the test both in debug and release versions. (TSAN is not supported on mac os)

@Mirocos
Copy link
Author

Mirocos commented Aug 31, 2021

Is it normal that ctest seems stuck at final test case 'timer_tests' in debug version?
By the way, build the test in release version seems have something wrong.

Test project /Users/mirocos/master/study/concurrencpp/build/test
      Start  1: task_tests
 1/23 Test  #1: task_tests .......................   Passed    0.92 sec
      Start  2: runtime_tests
 2/23 Test  #2: runtime_tests ....................   Passed    0.35 sec
      Start  3: inline_executor_tests
 3/23 Test  #3: inline_executor_tests ............   Passed    0.35 sec
      Start  4: manual_executor_tests
 4/23 Test  #4: manual_executor_tests ............   Passed    9.19 sec
      Start  5: thread_executor_tests
 5/23 Test  #5: thread_executor_tests ............   Passed    0.48 sec
      Start  6: thread_pool_executor_tests
 6/23 Test  #6: thread_pool_executor_tests .......   Passed    5.14 sec
      Start  7: worker_thread_executor_tests
 7/23 Test  #7: worker_thread_executor_tests .....   Passed    0.48 sec
      Start  8: result_tests
 8/23 Test  #8: result_tests .....................   Passed    8.86 sec
      Start  9: result_resolving_tests
 9/23 Test  #9: result_resolving_tests ...........   Passed    0.37 sec
      Start 10: result_awaiting_tests
10/23 Test #10: result_awaiting_tests ............   Passed    0.36 sec
      Start 11: lazy_result_tests
11/23 Test #11: lazy_result_tests ................   Passed    0.39 sec
      Start 12: shared_result_tests
12/23 Test #12: shared_result_tests ..............   Passed    9.40 sec
      Start 13: shared_result_resolving_tests
13/23 Test #13: shared_result_resolving_tests ....   Passed    0.36 sec
      Start 14: shared_result_awaiting_tests
14/23 Test #14: shared_result_awaiting_tests .....   Passed    0.37 sec
      Start 15: make_result_tests
15/23 Test #15: make_result_tests ................   Passed    0.41 sec
      Start 16: result_promise_tests
16/23 Test #16: result_promise_tests .............   Passed    0.41 sec
      Start 17: when_all_tests
17/23 Test #17: when_all_tests ...................   Passed    0.46 sec
      Start 18: when_any_tests
18/23 Test #18: when_any_tests ...................   Passed    0.96 sec
      Start 19: resume_on
19/23 Test #19: resume_on ........................   Passed    0.35 sec
      Start 20: coroutine_promise_tests
20/23 Test #20: coroutine_promise_tests ..........   Passed    0.35 sec
      Start 21: coroutine_tests
21/23 Test #21: coroutine_tests ..................   Passed    0.65 sec
      Start 22: timer_queue_tests
22/23 Test #22: timer_queue_tests ................   Passed    1.17 sec
      Start 23: timer_tests

@David-Haim
Copy link
Owner

Yes, the timer test takes about 6 minutes to finish.
What seems to be weird on release mode?

@Mirocos
Copy link
Author

Mirocos commented Aug 31, 2021

here is compiler error on release mode:

[ 24%] Linking CXX executable timer_queue_tests
[ 24%] Built target timer_queue_tests
[ 25%] Building CXX object CMakeFiles/when_all_tests.dir/source/tests/result_tests/when_all_tests.cpp.o
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal (use -v to see invocation)
Apple clang version 12.0.5 (clang-1205.0.22.11)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /var/folders/22/k1fh525n4g1ctbjlgm5dq9v00000gn/T/when_all_tests-16c24e.cpp
clang: note: diagnostic msg: /var/folders/22/k1fh525n4g1ctbjlgm5dq9v00000gn/T/when_all_tests-16c24e.sh
clang: note: diagnostic msg: Crash backtrace is located in
clang: note: diagnostic msg: /Users/mirocos/Library/Logs/DiagnosticReports/clang_<YYYY-MM-DD-HHMMSS>_<hostname>.crash
clang: note: diagnostic msg: (choose the .crash file that corresponds to your crash)
clang: note: diagnostic msg: 

********************
make[2]: *** [CMakeFiles/when_all_tests.dir/source/tests/result_tests/when_all_tests.cpp.o] Error 254
make[1]: *** [CMakeFiles/when_all_tests.dir/all] Error 2
make: *** [all] Error 2

@Mirocos
Copy link
Author

Mirocos commented Aug 31, 2021

Test in debug version all passed.
And here is the mentioned files in release mode:
bug.zip

@David-Haim
Copy link
Owner

So ApplecClang crashes when it tries to compile heavy coroutine code, great.
Unfortunately we don't have much to do besides to wait for future AppleClang versions, which support both binary_semaphore and don't crash when compiling complicated coroutine code.
From my experience opening a bug for them doesn't help either - they just ignore it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Mirocos @David-Haim