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
Facing with compilation errors while building NodeJS module with boost inside on Mac OS X #55
Comments
Not your fault, didn't think that could be a macro, it's normally a function. Will fix that, do you have a full list of errors? in the meantime you can just remove the |
Thanks for such a quick reply. The output is right below. ` shm-typed-array@ install /Users/AUser/project/SHMTypedArray
CXX(target) Release/obj.target/shm/src/gnuipcstub.o npm ERR! A complete log of this run can be found in: |
Hello, @klemens-morgenstern ! how is it going? Any updates? |
I just realized that |
Does this mean that your advice above will not help? |
I fear not. Really sorry that made it into release - if you don't use the timed wait functions (wait_for / wait_until) you might just be able to comment them out. That's nothing I can use as a library solution though, obviously. I will see if I can come up with a solution. |
Actually I do not use them. I use boost::interprocess but it depends on boost::process in some way and at least in 1.68. I got my module built and working with 1.66.0. So this is not critical issue to me. And I understand that bugs appear time to time... Have a good luck! And thank you for what you are doing. |
|
Should I create an issue in boost::interprocess to mention this? |
According to you compiler output you include it yourself in |
Yep... you are definitely right... :-) |
So... finally |
Ah ok, well glad your problem is solved, I still need to find a fix for that. Thanks for reporting! |
The macro |
Sadly, I know. Still working on the fix. |
Turns out that MacOS isn't the only platform that defines I can supply a patch but it is nothing more than stripping |
Never mind, I see you have fixes for this in the develop branch already. |
So can this issue be closed? |
Up to you :) |
Sorry this question was not addressed to me as I see... |
@klemens-morgenstern While I haven't tested your current changes I think you are good to close this. It can always be reopened if the issues persist after the next release. |
... as reported at <boostorg/process#55>.
I'm also getting this when compiling some boost::asio stuff on 1.69.0. What commit is this fixed in (I'm guessing it's post-1.69.0...)? |
I tried stripping the |
I think I found it - looks like 03cba8f is the one where that is fixed. Should I be able to just poke that into my own fork of 1.69.0, or are there more changes that the fix is dependent upon? |
You should be able to just poke that into 1.69. Will be in 1.70. |
So - it looks like there are still some issues with this fix on macOS. Here is what I'm seeing:
Again - this is on macOS specifically. I am willing to log the unit test issue as a separate bug - but don't know if I should log it here (the boostorg/process repo), or the upstream project (the klemens-morgenstern/boost-process repo)? I'm also willing to try grabbing some version of Any guidance would be appreciated as to how/where to reproduce and report the bug against. I'm a bit lost as to how/what is going on, because I don't ever in my code (directly) use |
… boost::process. See boostorg/process#55
I'm also facing the same issue in 1.69 under OSX . Now have to roll back to some early versions. |
@toonetown Sry, I missed the notifications for your comment. The compile issues should be fixed by now (post 1.69), I stil heard reports of runtime-errors, i.e. the |
not sure if this is the right way to fix this seen here boostorg/process#55 (comment) and mostly here boostorg/process#55 (comment)
not sure if this is the right way to fix this seen here boostorg/process#55 (comment) and mostly here boostorg/process#55 (comment)
The unit test hang is still happening in 1.70.0. (It does appear to happen with the |
@klemens-morgenstern On macOS, at least, I can put up a PR if you can tell me which repo to submit it against. |
@toonetown thanks, against klemens-morgenstern/boost-process would be awesome, since that got all the CI setup. |
Related (I believe) to boostorg/process#55 With the fix from klemens-morgenstern#197, multiple processes can still at times be spawned, and they take extremely high CPU usage. This PR basically uses the same approach used for boost 1.68.0 (which was the last time wait_for seemed to work reliably) and guards it for macOS compilations only.
Related (I believe) to boostorg#55 With the fix from klemens-morgenstern/boost-process#197, multiple processes can still at times be spawned, and they take extremely high CPU usage. This PR basically uses the same approach used for boost 1.68.0 (which was the last time wait_for seemed to work reliably) and guards it for macOS compilations only.
Related (I believe) to boostorg/process#55 With the fix from klemens-morgenstern#197, multiple processes can still at times be spawned, and they take extremely high CPU usage. This PR basically uses the same approach used for boost 1.68.0 (which was the last time wait_for seemed to work reliably) but adds a 1ms sleep to each iteration of the loop so as not to spike the CPU.
Related (I believe) to boostorg/process#55 With the fix from klemens-morgenstern#197, multiple processes can still at times be spawned, and they take extremely high CPU usage. This PR basically uses the same approach used for boost 1.68.0 (which was the last time wait_for seemed to work reliably) but adds a 1ms sleep to each iteration of the loop so as not to spike the CPU.
Boost 1.70 not yet available on brew (always 1.69) |
Related (I believe) to boostorg/process#55 With the fix from klemens-morgenstern#197, multiple processes can still at times be spawned, and they take extremely high CPU usage. This PR basically uses the same approach used for boost 1.68.0 (which was the last time wait_for seemed to work reliably) but adds a 1ms sleep to each iteration of the loop so as not to spike the CPU.
Related (I believe) to boostorg#55 With the fix from klemens-morgenstern/boost-process#197, multiple processes can still at times be spawned, and they take extremely high CPU usage. This PR basically uses the same approach used for boost 1.68.0 (which was the last time wait_for seemed to work reliably) but adds a 1ms sleep to each iteration of the loop so as not to spike the CPU.
Related (I believe) to boostorg/process#55 With the fix from klemens-morgenstern#197, multiple processes can still at times be spawned, and they take extremely high CPU usage. This PR basically uses the same approach used for boost 1.68.0 (which was the last time wait_for seemed to work reliably) but adds a 1ms sleep to each iteration of the loop so as not to spike the CPU.
Related (I believe) to boostorg#55 With the fix from klemens-morgenstern/boost-process#197, multiple processes can still at times be spawned, and they take extremely high CPU usage. This PR basically uses the same approach used for boost 1.68.0 (which was the last time wait_for seemed to work reliably) but adds a 1ms sleep to each iteration of the loop so as not to spike the CPU.
MacOS Sierra 10.12
MacOS High Sierra 10.13.6
In file included from ~/boost/boost/process.hpp:24:
In file included from ~/boost/boost/process/async_system.hpp:22:
In file included from ~/boost/boost/process/child.hpp:21:
In file included from ~/boost/boost/process/detail/child_decl.hpp:30:
/boost/boost/process/detail/posix/wait_for_exit.hpp:60:7: error: expected unqualified-id
::sigemptyset(&sigset);
^
/usr/include/signal.h:125:26: note: expanded from macro 'sigemptyset'
#define sigemptyset(set) (*(set) = 0, 0)
^
What am I doing wrong? Any ideas? Thanks in advance.
and few same errors....
PS: I am using boost 1.68.0 built from sources.
The text was updated successfully, but these errors were encountered: