Re: [PATCH] src/libs/libxutil/XFontName.c(utoa): non-GNU stdlib.h conflict

[Brian Inglis]

On 2023-02-23 20:17, G. Branden Robinson wrote:
> Hi Brian,
>
> At 2023-02-23T10:04:41-0700, Brian Inglis wrote:
> > On 2023-02-23 09:07, G. Branden Robinson wrote:
> > > At 2023-02-23T00:46:45-0700, Brian Inglis wrote:
> > > > gcc 11.3 build failure when static utoa definition in XFontName.c
> > > > conflicts with extern utoa declared in stdlib.h
> > > Can you say specifically which system you built on?
> > newlib under Cygwin - catches glibc and linux assumptions
> Okay.  I haven't heard from the Cygwin folks for years, and last few
> times I tried to get feedback on defect reports or patches for bugs that
> they were experiencing, I never heard back.
> If you build there regularly, and are willing, you could be helpful in
> getting a few issues resolved.[1]
> (Same with the Guix folks.[2])

> > Did not find any related functions in current code base.

> groff has its own itoa and uitoa functions in libgroff, but tellingly
> they are named i_to_a and ui_to_a.  It might make sense to port this
> libxutil thing to use that.  If it even links with libgroff already,
> which it may not.
> I know for sure I don't want to screw with cross-language library
> linkage issues just before a (knock wood) final release.  There is a
> circle of Hell called "ABI"; Dante just didn't know how to describe it.

Not a problem, will point the official maintainer to the bug, and hope any patch 
fails to apply next release! ;^>

> > Done    https://savannah.gnu.org/bugs/index.php?63831

> Thanks.  This will help keep it from being forgotten in a possible
> flurry of distractions after the release.
> [1] https://savannah.gnu.org/bugs/?55708

No longer an issue - perhaps did not run bootstrap (hey good guess - that exists 
on sv!) after git pull, or autoreconf before building from download, etc.

Rest are Windows ports possibly using msys2/msys/mingw64/mingw32/mingw?
Cygwin is not Windows - motto/slogan - "Get that Linux feeling - on Windows"!
The project volunteers commonly submit config patches moving `Windows | Cygwin)` 
cases to `Unix | Cygwin)`!

>      https://savannah.gnu.org/bugs/?55695
>      https://savannah.gnu.org/bugs/?55335
>      https://savannah.gnu.org/bugs/?55300
>      https://savannah.gnu.org/bugs/?55299
> [2] https://savannah.gnu.org/bugs/?55475

[Cygwin uses newlib (somewhat BSD derived and licensed) as lightish embedded 
libc (basis for lighter nanolibc and picolibc) under cross-g++ emulator which 
sometimes overrides or replaces newlib with extensive BSD/GNU hosted 
functionality, some provided by Windows interfaces, others from BSD/GNU 
libraries - providing bidirectional interoperability and integration - enough to 
support the X Window system using X.org packages with ssh connections.
Support for Windows features, paths, and line ends has been disappearing as 
developers and package maintainers focus more on POSIX over native 
compatibility, but not Linux kernel compatibility, more generic glibc level.
It is widely used for hosting embedded development, especially that based on 
newlib, such as RTEMS, AmigaOS4, including supporting non-commercial and 
commercial embedded GCC toolchain development distributions.]

--
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                -- Antoine de Saint-Exupéry