"augh not another one of these alpine-specific posts" don't worry i feel the same way
!TODO insert screenshot here once i get it working
the audio stuff works fine, but it crashes when i try to open the ui
stack trace from carla --gdb:
#0 __restore_sigs (set=set@entry=0x7fffffffbb50) at ./arch/x86_64/syscall_arch.h:40
#1 0x00006f000005de1b in raise (sig=sig@entry=6) at src/signal/raise.c:11
#2 0x00006f00000419ad in abort () at src/exit/abort.c:11
#3 0x00007fffdede17e7 in std::sys::unix::abort_internal () from /usr/local/lib/vst3/nyasynth.vst3/Contents/x86_64-linux/nyasynth.so
#4 0x00007fffdeddf2d0 in rust_panic () from /usr/local/lib/vst3/nyasynth.vst3/Contents/x86_64-linux/nyasynth.so
#5 0x00007fffdeddf132 in std::panicking::rust_panic_with_hook () from /usr/local/lib/vst3/nyasynth.vst3/Contents/x86_64-linux/nyasynth.so
#6 0x00007fffdeddee77 in std::panicking::begin_panic_handler::{{closure}} () from /usr/local/lib/vst3/nyasynth.vst3/Contents/x86_64-linux/nyasynth.so
#7 0x00007fffdeddd936 in std::sys_common::backtrace::__rust_end_short_backtrace () from /usr/local/lib/vst3/nyasynth.vst3/Contents/x86_64-linux/nyasynth.so
#8 0x00007fffdeddebc2 in rust_begin_unwind () from /usr/local/lib/vst3/nyasynth.vst3/Contents/x86_64-linux/nyasynth.so
#9 0x00007fffdec35743 in core::panicking::panic_fmt () from /usr/local/lib/vst3/nyasynth.vst3/Contents/x86_64-linux/nyasynth.so
#10 0x00007fffdec35be3 in core::result::unwrap_failed () from /usr/local/lib/vst3/nyasynth.vst3/Contents/x86_64-linux/nyasynth.so
#11 0x00007fffdec51201 in baseview::x11::window::Window::open_parented () from /usr/local/lib/vst3/nyasynth.vst3/Contents/x86_64-linux/nyasynth.so
#12 0x00007fffdec966a6 in egui_baseview::window::EguiWindow<State,U>::open_parented () from /usr/local/lib/vst3/nyasynth.vst3/Contents/x86_64-linux/nyasynth.so
#13 0x00007fffdeca20cf in <nih_plug_egui::editor::EguiEditor<T> as nih_plug::editor::Editor>::spawn () from /usr/local/lib/vst3/nyasynth.vst3/Contents/x86_64-linux/nyasynth.so
#14 0x00007fffdec90d5f in <nih_plug::wrapper::vst3::view::WrapperView<P> as vst3_sys::gui::iplugview::IPlugView>::attached () from /usr/local/lib/vst3/nyasynth.vst3/Contents/x86_64-linux/nyasynth.so
#10 and #11 look relevant
nyasynth uses nih_plug uses egui uses baseview which doesn't support wayland, so that explains the x11
yes.
happens with carla, zrythm, ardour on my machine
also tried running in sway and rootful Xwayland, that didn't work either
not gonna install X11 just for this so let's try compiling it on my arch install
😐
tested with river and it runs perfectly fine too
???
three possibilities:
the error is a failed unwrap in baseview::x11::window::Window::open_parented
found baseview x11/window.rs in ~/.cargo/ why must it dump these in my home directory??
pub fn open_parented<P, H, B>(parent: &P, options: WindowOpenOptions, build: B) -> WindowHandle
where
P: HasRawWindowHandle,
H: WindowHandler + 'static,
B: FnOnce(&mut crate::Window) -> H,
B: Send + 'static,
{
// Convert parent into something that X understands
let parent_id = match parent.raw_window_handle() {
RawWindowHandle::Xlib(h) => h.window as u32,
RawWindowHandle::Xcb(h) => h.window,
h => panic!("unsupported parent handle type {:?}", h),
};
let (tx, rx) = mpsc::sync_channel::<WindowOpenResult>(1);
let (parent_handle, mut window_handle) = ParentHandle::new();
thread::spawn(move || {
Self::window_thread(Some(parent_id), options, build, tx.clone(), Some(parent_handle));
});
let raw_window_handle = rx.recv().unwrap().unwrap(); // one of these here??
window_handle.raw_window_handle = Some(raw_window_handle.0);
window_handle
}
i have a few questions:
also this is AWFUL to debug, i wish there was a proper backtrace
one web browsing later...
ookay so it's SUPPOSED to have a backtrace with the debug build? highly suspect gdb or carla messing with stuff
fortunately there's a standalone build option
18:24:03 [INFO] Initalizing VST...
18:24:03 [ERROR] thread 'unnamed' panicked at 'called `Option::unwrap()` on a `None` value': /home/choc/.cargo/git/checkouts/baseview-9d6c750431f4479e/eae4033/src/gl/x11.rs:50
...
7: core::option::unwrap_failed
8: baseview::gl::x11::get_proc_address
...
18:24:03 [ERROR] thread 'unnamed' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError': /home/choc/.cargo/git/checkouts/baseview-9d6c750431f4479e/eae4033/src/x11/window.rs:143
...
6: core::result::unwrap_failed
7: <nih_plug_egui::editor::EguiEditor<T> as nih_plug::editor::Editor>::spawn
...
18:24:03 [ERROR] thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError': /home/choc/.cargo/git/checkouts/baseview-9d6c750431f4479e/7001c25/src/x11/window.rs:181
...
6: core::result::unwrap_failed
7: nih_plug::wrapper::standalone::wrapper::Wrapper<P,B>::run
8: nih_plug::wrapper::standalone::nih_export_standalone_with_args
9: standalone::main
...
well this certainly doesn't look like a libc problem
you've heard of running glibc programs on alpine, now get ready for musl-linked programs on glibc :P
if the same well, aside from linking binary works on arch then we can prove it isn't a compile issue
patchelf nyasynth-standalone --remove-needed libc.musl-x86_64.so.1 --set-interpreter /lib/ld-linux-x86-64.so.2
that's it. that's the whole process
and it Just Works because why wouldn't it!
T-T
welp guess we can rule out possibility #1 now
maybe arch might have different libs (and drivers? it's a different device after all) so let's try with something a bit closer to alpine
if you really need to run glibc apps, check out distrobox.
suggestions for thee but not for me :P tbf im not currently using this for any load-bearing workstuff soooo i should really rewrite the script to use void and bwrap but lazy
patch the binary...
patchelf nyasynth-standalone --remove-needed libc.musl-x86_64.so.1 --set-interpreter /lib/ld-linux-x86-64.so.2
add the usual packages...
apk add xcb-util-wm mesa-gl alsa-lib
...
wait, i'd rather deal with that than figure out library-versioning hell
bbut gcompat doesn't change anything...
maybe this was a bug that got fixed?
the version of nih-plug that nyasynth uses is pretty outdated cos there's some custom changes
thankfully the changes reapply cleanly
but the compile has a few errors
uhoh
at least the compiler gives some helpful hints
it seems like they refactored this ui.memory function?
what's a closure??
oh i figured it out
yippee!!
now to run it...
AUGH IT STILL FAILS WITH THE SAME ERROR
wolfiproot is failing to load the iris driver hmmm
that's cos wolfi doesn't have mesa-dri-gallium
which is inconvenient but understandable, it's not meant for desktop use
hypothesis: iris driver is messing with stuff
test: disable iris driver
export LIBGL_ALWAYS_SOFTWARE=true
gets rid of the "failed to load iris" error in wolfiproot and runs fine there
but still doesn't fix it for alpine :/
compiled an egui example plugin from nih-plug
gives the same gl::get_proc_address unwrap error
so this isn't just nyasynth
oaugh
gonna triage a bit more but it looks like i'll have to file an issue and im kinda lazy to do that
maybe when i start procrastinating other stuff :'P
(please contact me if you have any suggestions or ideas on how to fix this!)
made with <3 and /.gen.sh