Re: [PATCH v2] PR gdb/33747: gdb/ser-unix: Avoid musl build failure when setting custom baud rates

[Kevin Buettner <kevinb@redhat.com>]

On Tue, 10 Mar 2026 19:08:15 +0530
Sunil Kumar Dora <sunilkumar.dora@windriver.com> wrote:

> > 3) I'd like to better understand what we might be losing by
> >     eliminating the fallback to TCGETS.  
> While looking into this, I noticed that on some architectures such as 
> PowerPC and Alpha, the normal
> /struct termios/ (not /termios2/) actually has /c_ispeed/ and /c_ospeed/ 
> fields. Because of this,
> those systems *might *still support custom baud rates using the older 
> /TCGETS/ interface.
> 
> The *build failure on musl *happens because musl follows strict POSIX, 
> and its /struct termios/ does not
> include these members (`/c_ispeed`/ and `/c_ospeed`/) on any architecture.
> 
> To handle both cases, would it make sense to keep the /TCGETS/ fallback 
> but guard it with a feature check like
> /AC_CHECK_MEMBERS([struct termios.c_ospeed])/?
> 
> That way we can still support the legacy behavior on glibc systems, 
> while avoiding build issues on musl
> where those fields don't exist.
> 
> This would result in something like the following compile-time paths:
> ----
> /#if defined(HAVE_CFSETSPEED_ARBITRARY)
>    /* Use cfsetispeed()/cfsetospeed() */
> 
> #elif defined(TCGETS2)
>    /* Use Linux termios2 interface with BOTHER */
> 
> #elif defined(HAVE_STRUCT_TERMIOS_C_OSPEED) && defined(BOTHER)
>    /* Legacy fallback using TCGETS/TCSETS */
> 
> #else
>    /* Custom baud rates not supported */
> #endif/
> 
> 
> I’m thinking this might be a reasonable approach, but please let me know 
> if I’m missing something.

That approach looks reasonable to me.

Kevin