-
Notifications
You must be signed in to change notification settings - Fork 4
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
Handle semaphore compilation / dtrace on linux #2
base: master
Are you sure you want to change the base?
Conversation
After adding the 4th temporary file, extracting this fragment makes sense.
Not sure if this is monitored, so pinging @Hywan |
I'm no longer working for Wasmer. You should ping @syrusakbary for that. |
Thanks for sharing! Wish you all the best in your new path |
@viniciusd Thanks for putting together this patch. @syrusakbary This patch works as expected and I would like to add to the docs to illustrate the linux eBPF scenario wtih Would it be possible to land this? |
I wish I were responsible for the changes, but I cannot take @viraptor's credits. Either way, looking forward to having it merged (and thanks @viraptor) |
Sincere Apologies @viraptor |
I'm not sure exactly what the differences are between the system where this was tested and mine, I ran into the problem described in issue #1 .
The build failed first because of an
-arch
dtrace argument not available on my system (comes from systemtap 4.5). This was made an optional argument (default off).Then it failed because of the semaphore file not being linked in. This was solved by adding an option to either compile without the semaphore object file (original behaviour, default), or to explicitly generate it (option).
If this doesn't play well with other systems this library was tested on, I'm happy to put some cfg guards around the functionality.
Fixes #1