Hi Mathieu, Thanks for reporting this.
This appears to be an upstream GDB issue affecting musl builds. The failure comes from set_custom_baudrate_linux() in gdb/ser-unix.c , which directly accesses struct termios members c_ospeed / c_ispeed. These fields exist with those names in glibc, but musl exposes them as __c_ospeed / __c_ispeed , which explains the build breakage you’re seeing. There is an upstream Bugzilla report tracking this issue: https://sourceware.org/bugzilla/show_bug.cgi?id=33747 I’ve been participating in the discussion there and shared some investigation and a possible direction, but there is *no agreed-upon fix yet*. A few important points from the upstream discussion so far: * Simply switching to cfset [io] speed() is not sufficient in all cases, since musl rejects non-standard baud rates and the existing GDB code intentionally bypasses that API. * Using libc-specific field names via #ifdef is fragile. * One possible approach under discussion is using a Linux termios2 -based path guarded by TCGETS2 , but this needs careful handling (e.g. BOTHER values differ across architectures). Given this, it seems best to let this get resolved upstream rather than adding a temporary OE-Core workaround. I’ll keep an eye on the upstream bug and follow up once there’s either a merged fix or a clearly recommended approach we can backport. Thanks, Sunil
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#228748): https://lists.openembedded.org/g/openembedded-core/message/228748 Mute This Topic: https://lists.openembedded.org/mt/116913831/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
