-
Notifications
You must be signed in to change notification settings - Fork 17
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
Doesn't build on x86_64 musl #4
Comments
doesn't build on musl yet, see: rust-minidump/minidump-writer#4 probably won't build on ppc either, see: https://github.com/msirringhaus/minidump_writer_linux/tree/main/src/thread_info
doesn't build on musl yet, see: rust-minidump/minidump-writer#4 probably won't build on ppc either, see: https://github.com/msirringhaus/minidump_writer_linux/tree/main/src/thread_info
Thanks for reporting this. The quickest workaround to build Firefox would probably be to switch back to the old breakpad code. |
Indeed, I'm looking into this now. It seems |
hm, maybe it will work in a new nix version? |
Yes, this plus your To test, you could just pull this crate, update the I don't have a musl-system at hand at the moment. If it does work, there would need to be a bugreport at Mozilla, asking for a new version of |
It will probably work, given nix-rust/nix#1198, I can test in a bit! Hm, I will try to create a bug report, haven't used the firefox bug tracker ever. Might be nice to fix nix so it works on x86-musl as well, not only x86_64. |
A test would be good. Might be some other symbols missing. |
Good thing you asked for a test :) I applied this diff
and got back:
I'm not sure how to proceed forward, but there seem to be two issues: a type mismatch and an API mismatch. |
minidump_writer_linux has issues on musl and doesn't support all platforms Void does (thread_info doesn't touch ppc*), so we add a patch to not build it at all. It seems to be a build system bug where oxidized_breakpad can be enabled even when --disable-backtrace is set. If next version still only enables it for x86_64, it might build/work fine for us, see: rust-minidump/minidump-writer#4
Ah yes, I remember the first one. There was some breaking API changes in |
minidump_writer_linux has issues on musl and doesn't support all platforms Void does (thread_info doesn't touch ppc*), so we add a patch to not build it at all. It seems to be a build system bug where oxidized_breakpad can be enabled even when --disable-backtrace is set. If next version still only enables it for x86_64, it might build/work fine for us, see: rust-minidump/minidump-writer#4
diff --git a/src/linux_ptrace_dumper.rs b/src/linux_ptrace_dumper.rs
index 0e34a6d..42a6223 100644
--- a/src/linux_ptrace_dumper.rs
+++ b/src/linux_ptrace_dumper.rs
@@ -102,7 +102,7 @@ impl LinuxPtraceDumper {
match wait::waitpid(pid, Some(wait::WaitPidFlag::__WALL)) {
Ok(_) => break,
Err(e @ nix::Error::Sys(Errno::EINTR)) => {
- ptrace::detach(pid).map_err(|e| DetachErr(child, e))?;
+ ptrace::detach(pid, None).map_err(|e| DetachErr(child, e))?;
return Err(DumperError::WaitPidError(child, e));
}
Err(_) => continue,
@@ -132,7 +132,7 @@ impl LinuxPtraceDumper {
skip_thread = true;
}
if skip_thread {
- ptrace::detach(pid).map_err(|e| DetachErr(child, e))?;
+ ptrace::detach(pid, None).map_err(|e| DetachErr(child, e))?;
return Err(DumperError::DetachSkippedThread(child));
}
}
@@ -143,7 +143,7 @@ impl LinuxPtraceDumper {
pub fn resume_thread(child: Pid) -> Result<(), DumperError> {
use DumperError::PtraceDetachError as DetachErr;
let pid = nix::unistd::Pid::from_raw(child);
- ptrace::detach(pid).map_err(|e| DetachErr(child, e))?;
+ ptrace::detach(pid, None).map_err(|e| DetachErr(child, e))?;
Ok(())
}
diff --git a/src/thread_info/thread_info_x86.rs b/src/thread_info/thread_info_x86.rs
index 6dbf6c2..7800859 100644
--- a/src/thread_info/thread_info_x86.rs
+++ b/src/thread_info/thread_info_x86.rs
@@ -5,8 +5,8 @@ use crate::minidump_cpu::RawContextCPU;
#[cfg(target_arch = "x86_64")]
use crate::thread_info::to_u128;
use core::mem::size_of_val;
-use libc;
-use libc::user;
+use nix::libc;
+use nix::libc::user;
use memoffset;
use nix::sys::ptrace;
use nix::unistd; Was indeed enough, but idk if this counts as punting the problem forward? Maybe most (all?) of the |
FYI, the proposed patch doesn't work:
|
@Whissi you're missing the previous patch that updates the nix version. |
minidump_writer_linux has issues on musl and doesn't support all platforms Void does (thread_info doesn't touch ppc*), so we add a patch to not build it at all. It seems to be a build system bug where oxidized_breakpad can be enabled even when --disable-backtrace is set. If next version still only enables it for x86_64, it might build/work fine for us, see: rust-minidump/minidump-writer#4
OK, I think I managed to create a patch for Firefox 87.0 with the change and all crate updates, https://dev.gentoo.org/~whissi/stuff/firefox-87.0-musl-minidump_writer_linux.patch.gz -- at least it will allow me to build on glibc x86_64. But on a msul system, it will fail:
|
Hm, have to wait for the libc release with those constants, I think (my patch pulled from libc git)... Maybe keeping a libc crate only for constants in here would help not being bound by the version nix is using. |
By the way, I've submitted a patch to fix the bug that this crate was being built, even if crashreporter is disabled: https://bugzilla.mozilla.org/show_bug.cgi?id=1701623 |
Firefox is now vendoring libc 0.2.97 which should include the fix above and nix 0.15.0. Would that be enough to fix this? |
No, from what I can tell the |
Addendum: The missing function in tl;dr: nix version 0.18.0 should be enough for building this on musl systems, but not for running |
I see, thanks for checking! |
Hi! I'm trying to build firefox 87.0 on a musl system, and this crate won't build there, which stops the whole build process.
I opened rust-lang/libc#2121 to solve the
libc
constants, but I'm not sure how to fix thegetregs
dependency.I have added this patch, which copies the actual restriction used by the
nix
crate (would be nice if Rust allowed querying for function availability instead of having to copy assignments):but I still get the following build failure:
I can't figure out how to clean up that file to work on musl, it seems just throwing in a
#[cfg ...]
won't be enough.The text was updated successfully, but these errors were encountered: