John Paul Adrian Glaubitz

> The dev team would need access to hardware to properly test an architecture; if an arch is not supported the chances of it actually working even if the check...

This fixes the build although I'm not sure whether it's okay to reduce the chosen bitrate in `beastHandleOption()`: ```diff diff --git a/sdr_beast.c b/sdr_beast.c index 66ecf52..312ff2a 100644 --- a/sdr_beast.c +++ b/sdr_beast.c...

> another ifdef with an else for the default baud rate in beastOpen? OK. > open a PR? Sure, can do. But not today anymore, I'm falling asleep. Good night!

Thanks, builds fine now and testsuite passes without any issues: ``` ============================================================================ Testsuite summary for nut 2.8.4.754 ============================================================================ # TOTAL: 5 # PASS: 5 # SKIP: 0 # XFAIL: 0...

Funny, I just reported [another instance of this bug in different project](https://github.com/wiedehopf/readsb/issues/112). ;-)

Here is the backtrace: ``` #0 Deserializer::read (this=, x=) at ./src/lib/../util/io/../algo/../system/endianness.h:20 20 return psnip_endian_le64(x); (gdb) bt #0 Deserializer::read (this=, x=) at ./src/lib/../util/io/../algo/../system/endianness.h:20 #1 Deserializer::operator>> (this=0x10000637d88, x=) at ./src/lib/../util/io/deserializer.h:100 #2 operator>>...

It looks like the code is using custom functions to convert between big end little endianness. I suggest switching to the endianness functions provided by the [glibc](https://man7.org/linux/man-pages/man3/endian.3.html).

OK, I replaced the custom byte-swap functions with the ones provided by glibc and the crash persists which means that the parameter itself is already misaligned: ``` #0 Deserializer::read (this=,...

I tried the following change in the hope that `read()` contains unaligned access, but the problem still persists: ```C --- diamond-aligner-2.1.9.orig/src/util/binary_buffer.h +++ diamond-aligner-2.1.9/src/util/binary_buffer.h @@ -41,7 +41,8 @@ struct BinaryBuffer :...

> On Oct 20, 2024, at 2:26 PM, Benjamin Buchfink ***@***.***> wrote: > >  > I'll try to look into it but I don't have access to a sparc64...