Re: [PATCH v0 0/2] Add C23 stdbit.h functions
Joel Sherrill <[email protected]> Tue, 17 Mar 2026 18:04:59 -0500
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <CAF9ehCUHtQ7jF5F8uRczUOSiiD39mQJ_OuU_rP0hcZpPzm+R8A@mail.gmail.com> |
On Tue, Mar 17, 2026 at 12:35 PM Corinna Vinschen <[email protected]> wrote: > Hi Joel, > > On Mar 13 12:03, Joel Sherrill wrote: > > This patch series is a draft and feedback is appreciated on what > > is required to run "autoreconf" to get build infrastructure that > > does not give an error. See > > https://sourceware.org/pipermail/newlib/2026/022334.html for > > details on the make error. > > > > Once this builds, I can foresee at least one more problem. > > The header file stdbit.h does not have C23 guards and neither > > do any of the implementation files. If these function files > > are to be compiled by an older compiler without C23 support, > > they should be disabled. At this point, I see adding a C23 > > guard to stdbit.c and stdbit/*.c files. > > Actually, no. > OK. That makes it easier. > > - The fact that these functions are only required by a C23 environment > doesn't mean that an older compiler shouldn't be able to build them. > They should be buildable and built, as long as the compiler provides > the matching builtins. > > - The header doesn't offically exist prior to C23. So if a source file > includes this file, it's building for C23 or later by default. > There's no guard required. It's different *only* for the compiler > building newlib itself, but this compiler should have access to the > header. > > The problem with stdbit/Makefile.inc is that you used %D instead of %D%. > This breaks the generated Makefile. > Thanks. and Grrrr.. one character mistakes can be so hard to spot. :( > > With that fixed, your code still doesn't build (with gcc 13.4.0, > cross-building for Cygwin), because the compiler complains about missing > definitions for UINT_WIDTH, ULLONG_WIDTH, etc. Maybe you should use > __LONG_WIDTH__ etc.? > That code is unmodified from FreeBSD. Once I get this far, I can address that. Right now, after autoreconf, I see this error: I see this pattern with git diff which looks wrong. Lots of lines in Makefile.in where the libm_ part disappeared after "common/" -libm/common/libm_a-sf_fpclassify.$(OBJEXT): \ - libm/common/$(am__dirstamp) \ +libm/common/a-sf_fpclassify.$(OBJEXT): libm/common/$(am__dirstamp) \ And missing the libc_ part after "argz" -@ELIX_LEVEL_1_FALSE@ libc/argz/libc_a-envz_strip.$(OBJEXT) +@ELIX_LEVEL_1_FALSE@am__objects_1 = libc/argz/a-argz_add.$(OBJEXT) \ I do not see any modified files that would do this. I have run autoreconf with Rocky 9 autotools and locally built unmodified versions. autoconf (GNU Autoconf) 2.69 automake (GNU automake) 1.16.5 Sorry to be a problem. I just do not seem to be able to regenerate a working Makefile.in Help appreciated. --joel > > Thanks, > Corinna >