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.

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

Closed
imalyavskiy opened this issue Nov 5, 2018 · 32 comments

Comments

@imalyavskiy
Copy link

imalyavskiy commented Nov 5, 2018

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.

@klemens-morgenstern
Copy link
Collaborator

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 :: before the sigemptyset in the headers and it should work.

@imalyavskiy
Copy link
Author

imalyavskiy commented Nov 5, 2018

Thanks for such a quick reply. The output is right below.

` shm-typed-array@ install /Users/AUser/project/SHMTypedArray

node-gyp rebuild

CXX(target) Release/obj.target/shm/src/gnuipcstub.o
CXX(target) Release/obj.target/shm/src/ipc_conductor.o
In file included from ../src/ipc_conductor.cpp:1:
In file included from ../src/node_shm.h:13:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process.hpp:24:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process/async_system.hpp:22:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process/child.hpp:21:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process/detail/child_decl.hpp:30:
/Users/AUser/project/SHMTypedArray/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)
^
In file included from ../src/ipc_conductor.cpp:1:
In file included from ../src/node_shm.h:13:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process.hpp:24:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process/async_system.hpp:22:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process/child.hpp:21:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process/detail/child_decl.hpp:30:
/Users/AUser/project/SHMTypedArray/boost/boost/process/detail/posix/wait_for_exit.hpp:61:7: error: expected unqualified-id
::sigaddset(&sigset, SIGCHLD);
^
/usr/include/signal.h:122:31: note: expanded from macro 'sigaddset'
#define sigaddset(set, signo) (
(set) |= sigbits(signo), 0)
^
In file included from ../src/ipc_conductor.cpp:1:
In file included from ../src/node_shm.h:13:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process.hpp:24:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process/async_system.hpp:22:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process/child.hpp:21:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process/detail/child_decl.hpp:30:
/Users/AUser/project/SHMTypedArray/boost/boost/process/detail/posix/wait_for_exit.hpp:87:26: error: no member named 'sigtimedwait' in the global namespace
auto ret_sig = ::sigtimedwait(&sigset, nullptr, &ts);
~~^
In file included from ../src/ipc_conductor.cpp:1:
In file included from ../src/node_shm.h:13:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process.hpp:25:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process/group.hpp:32:
/Users/AUser/project/SHMTypedArray/boost/boost/process/detail/posix/wait_group.hpp:64:7: error: expected unqualified-id
::sigemptyset(&sigset);
^
/usr/include/signal.h:125:26: note: expanded from macro 'sigemptyset'
#define sigemptyset(set) ((set) = 0, 0)
^
In file included from ../src/ipc_conductor.cpp:1:
In file included from ../src/node_shm.h:13:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process.hpp:25:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process/group.hpp:32:
/Users/AUser/project/SHMTypedArray/boost/boost/process/detail/posix/wait_group.hpp:65:7: error: expected unqualified-id
::sigaddset(&sigset, SIGCHLD);
^
/usr/include/signal.h:122:31: note: expanded from macro 'sigaddset'
#define sigaddset(set, signo) (
(set) |= sigbits(signo), 0)
^
In file included from ../src/ipc_conductor.cpp:1:
In file included from ../src/node_shm.h:13:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process.hpp:25:
In file included from /Users/AUser/project/SHMTypedArray/boost/boost/process/group.hpp:32:
/Users/AUser/project/SHMTypedArray/boost/boost/process/detail/posix/wait_group.hpp:90:17: error: no member named 'sigtimedwait' in the global namespace
ret = ::sigtimedwait(&sigset, nullptr, &ts);
~~^
../src/ipc_conductor.cpp:181:10: warning: unused variable 'sz_stk' [-Wunused-variable]
auto sz_stk = ipc_index
[resId].size();
^
../src/ipc_conductor.cpp:180:10: warning: unused variable 'sz_ref' [-Wunused-variable]
auto sz_ref = ipc_index
[resId].top()->use_count();
^
../src/ipc_conductor.cpp:248:10: warning: unused variable 'sz_ref' [-Wunused-variable]
auto sz_ref = ipc_index
[resId].top()->use_count();
^
../src/ipc_conductor.cpp:255:14: warning: unused variable 'p' [-Wunused-variable]
uint8_t* p = ipc_index
[resId].top()->get<uint8_t>();
^
../src/ipc_conductor.cpp:249:10: warning: unused variable 'sz_stk' [-Wunused-variable]
auto sz_stk = ipc_index_[resId].size();
^
5 warnings and 6 errors generated.
make: *** [Release/obj.target/shm/src/ipc_conductor.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:262:23)
gyp ERR! stack at ChildProcess.emit (events.js:182:13)
gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:240:12)
gyp ERR! System Darwin 17.7.0
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/AUser/project/SHMTypedArray
gyp ERR! node -v v10.13.0
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! shm-typed-array@ install: node-gyp rebuild
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the shm-typed-array@ install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! /Users/AUser/.npm/_logs/2018-11-04T04_54_54_133Z-debug.log
AUsers-MBP:SHMTypedArray user$`

@imalyavskiy
Copy link
Author

Hello, @klemens-morgenstern ! how is it going? Any updates?

@klemens-morgenstern
Copy link
Collaborator

I just realized that sigtimedwait does not exist on OSX, so I have (again) no idea how to solve that, except for letting the thing go into an infinite loop until or create some workaround. That'll sadly take some time.

@imalyavskiy
Copy link
Author

Does this mean that your advice above will not help?

@klemens-morgenstern
Copy link
Collaborator

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.

@imalyavskiy
Copy link
Author

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.

@klemens-morgenstern
Copy link
Collaborator

boost::interprocess should not depend on boost::process, at least that would be a change to it I am not aware off. Will keep the issue around until fixed.

@imalyavskiy
Copy link
Author

Should I create an issue in boost::interprocess to mention this?

@klemens-morgenstern
Copy link
Collaborator

According to you compiler output you include it yourself in node_shm.h:13, and not through interprocess.

@imalyavskiy
Copy link
Author

imalyavskiy commented Nov 9, 2018

Yep... you are definitely right... :-)

@imalyavskiy
Copy link
Author

So... finally boost::interprocess does not depend on boost::process in any way. I used to include boost::brocess for the only thing boost::this_process::get_id();

@klemens-morgenstern
Copy link
Collaborator

Ah ok, well glad your problem is solved, I still need to find a fix for that. Thanks for reporting!

@pdimov
Copy link
Member

pdimov commented Dec 12, 2018

The macro sigemptyset is still a problem in 1.69 according to @HowardHinnant.

@klemens-morgenstern
Copy link
Collaborator

Sadly, I know. Still working on the fix.

@jake-at-work
Copy link
Contributor

Turns out that MacOS isn't the only platform that defines sigemptyset, sigaddset. That is an easy fix since all you need to do is drop the :: qualifier. As for the sigtimedwait, that too isn't common on all platforms. Strangely, stripping the :: qualifier from that one gets the code to compile. I am guessing that template is never instantiated so the fact the method does not exits isn't causing us problems.

I can supply a patch but it is nothing more than stripping :: from those 3 identifiers.

@jake-at-work
Copy link
Contributor

Never mind, I see you have fixes for this in the develop branch already.

@klemens-morgenstern
Copy link
Collaborator

So can this issue be closed?

@imalyavskiy
Copy link
Author

Up to you :)

@imalyavskiy
Copy link
Author

Sorry this question was not addressed to me as I see...

@jake-at-work
Copy link
Contributor

@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.

tabe added a commit to flintproject/Flint that referenced this issue Jan 8, 2019
@toonetown
Copy link
Contributor

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...)?

@toonetown
Copy link
Contributor

I tried stripping the :: as suggested in #55 (comment) - however, it's still failing for me with undeclared identifier sigtimedwait.

@toonetown
Copy link
Contributor

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?

@klemens-morgenstern
Copy link
Collaborator

You should be able to just poke that into 1.69. Will be in 1.70.

toonetown added a commit to toonetown/boostorg-boost that referenced this issue Jan 9, 2019
@toonetown
Copy link
Contributor

So - it looks like there are still some issues with this fix on macOS. Here is what I'm seeing:

  • Building with boost 1.69.0, libs/process set to c3b707b (what shipped in 1.69.0)
    • ASIO-related code fails to compile with the unqualified-id (as described in this bug)
  • Building with boost 1.69.0, libs/process set to 03cba8f (suggested fix from this bug)
    • ASIO-related code compiles, but running unit tests (using boost::test) seem to spawn a TON of child processes (appears to be one per test suite in my codebase) - which never exit even though the main unit test process does exit.
  • Building with boost 1.69.0, libs/process set to e2e2b5d (current master branch of this repo)
    • ASIO-related code compiles, but running unit tests (using boost::test) still spawns the child processes which never exit (same behavior as the previous case).
  • Building with boost 1.69.0, libs/process set to 44162ec (what shipped in 1.68.0)
    • ASIO-related code compiles, and unit tests build and run as expected.

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 boost::process and just trying it to see if it works or not...but there appear to be a lot of different branches and repos involved (so I don't know what to attempt to test against).

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 - but I'm seeing side effects of this issue in both boost::asio and boost::test.

toonetown added a commit to toonetown/boostorg-boost that referenced this issue Jan 9, 2019
@ppLorins
Copy link

I'm also facing the same issue in 1.69 under OSX . Now have to roll back to some early versions.

@klemens-morgenstern
Copy link
Collaborator

@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 wait_for and wait_until functions not working. I set up a OSX test on travis, so I hope to avoid mistakes like that in the future.

3nids added a commit to qgis/QGIS that referenced this issue Mar 6, 2019
not sure if this is the right way to fix this 
seen here boostorg/process#55 (comment) and mostly here boostorg/process#55 (comment)
3nids added a commit to qgis/QGIS that referenced this issue Mar 7, 2019
not sure if this is the right way to fix this 
seen here boostorg/process#55 (comment) and mostly here boostorg/process#55 (comment)
@toonetown
Copy link
Contributor

toonetown commented Apr 20, 2019

The unit test hang is still happening in 1.70.0. (It does appear to happen with the wait_for call)

@toonetown
Copy link
Contributor

toonetown commented Apr 20, 2019

@klemens-morgenstern
After some trial-and-error investigation, I think I was able to get it to work by replacing the -15 with SIGTERM in both detail/posix/wait_for_exit.hpp and detail/posix/wait_group.hpp.

On macOS, at least, SIGTERM is defined as 15, not -15.

I can put up a PR if you can tell me which repo to submit it against.

toonetown added a commit to toonetown/boostorg-boost that referenced this issue Apr 20, 2019
@klemens-morgenstern
Copy link
Collaborator

@toonetown thanks, against klemens-morgenstern/boost-process would be awesome, since that got all the CI setup.

toonetown added a commit to toonetown/km-boost-process that referenced this issue Apr 25, 2019
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.
toonetown added a commit to toonetown/boostorg-process that referenced this issue Apr 25, 2019
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.
toonetown added a commit to toonetown/km-boost-process that referenced this issue Apr 26, 2019
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.
toonetown added a commit to toonetown/km-boost-process that referenced this issue Apr 26, 2019
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.
@Nelson-numerical-software

Boost 1.70 not yet available on brew (always 1.69)
Very blocking trouble :(

toonetown added a commit to toonetown/km-boost-process that referenced this issue Aug 27, 2019
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.
toonetown added a commit to toonetown/boostorg-process that referenced this issue Aug 27, 2019
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.
toonetown added a commit to toonetown/km-boost-process that referenced this issue Dec 12, 2019
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.
toonetown added a commit to toonetown/boostorg-boost that referenced this issue Dec 12, 2019
toonetown added a commit to toonetown/boostorg-process that referenced this issue May 19, 2020
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.
toonetown added a commit to toonetown/boostorg-boost that referenced this issue May 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants