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

Build compatibility with non-glibc systems #635

Closed
lynxlynx opened this Issue Dec 11, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@lynxlynx

lynxlynx commented Dec 11, 2017

I am using a system with musl libc as the only libc available. It provides different standard headers as well as different dynamic linking interface.
edb builds and runs just fine, but for better portability you may need to make these adjustments:

  1. plugins/DebuggerCore/unix/linux/DebuggerCore.cpp misses #include <sys/wait.h>. Without it, __WALL macro for waitpid() is missing and compile errors pop out.
  2. plugins/DebuggerCore/unix/linux/arch/x86-generic/PlatformThread.cpp relies on enum __ptrace_request as first ptrace() argument. This is fine and conforming probably, but musl uses int instead. I had to add #define __ptrace_request int just after all includes but before // doesn't always seem to be defined in the headers defines.

While 1 definitely wants to be fixed, 2 is questionable.

@10110111

This comment has been minimized.

Show comment
Hide comment
@10110111

10110111 Dec 11, 2017

Contributor

I suppose typedef would be better than #define, but in any case this one will need some CMake checks to be really viable (like "if __ptrace_request doesn't compile in a test, then declare a typedef for it in some config header").

Contributor

10110111 commented Dec 11, 2017

I suppose typedef would be better than #define, but in any case this one will need some CMake checks to be really viable (like "if __ptrace_request doesn't compile in a test, then declare a typedef for it in some config header").

eteran added a commit that referenced this issue Jan 11, 2018

@lynxlynx lynxlynx closed this Sep 5, 2018

@eteran

This comment has been minimized.

Show comment
Hide comment
@eteran

eteran Sep 6, 2018

Owner

@lynxlynx is this issue resolved? Or do you feel that it just hasn't gotten attention?

Owner

eteran commented Sep 6, 2018

@lynxlynx is this issue resolved? Or do you feel that it just hasn't gotten attention?

@lynxlynx

This comment has been minimized.

Show comment
Hide comment
@lynxlynx

lynxlynx Sep 6, 2018

I think first one was fixed by your commit and second one not really that important since it's minor portability issue. So I think it's resolved now. Thanks!

lynxlynx commented Sep 6, 2018

I think first one was fixed by your commit and second one not really that important since it's minor portability issue. So I think it's resolved now. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment