[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Brian Inglis
Subject: Re: [PATCH] src/libs/libxutil/XFontName.c(utoa): non-GNU stdlib.h conflict
Date: Fri, 24 Feb 2023 10:01:58 -0700
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0

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! ;^>


Thanks.  This will help keep it from being forgotten in a possible
flurry of distractions after the release.

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)`!

[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 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]