Re: Build failure with GCC 15 (defaults to -std=gnu23)
От | Thomas Munro |
---|---|
Тема | Re: Build failure with GCC 15 (defaults to -std=gnu23) |
Дата | |
Msg-id | CA+hUKGJma08NBfwv8kiLAW08wFaz-WxDuXWbENi92XdE46N6ZA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Build failure with GCC 15 (defaults to -std=gnu23) (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: Build failure with GCC 15 (defaults to -std=gnu23)
|
Список | pgsql-bugs |
On Thu, Nov 21, 2024 at 8:23 PM Peter Eisentraut <peter@eisentraut.org> wrote: > On 20.11.24 16:32, Tom Lane wrote: > > Yeah. Our normal theory for this kind of thing is "people are > > likely to build our old branches with modern toolchains", so > > we are going to have to back-patch C23 compatibility sooner or > > later. In fact, we'll have to back-patch to 9.2, or else > > decide that those branches are unbuildable on modern platforms > > and hence out of scope for compatibility testing. > > I have checked that with this patch and the two above (well, one is just > to remove a warning), you can get PG16 and up building cleanly with > gcc-14 -std=gnu23. Thanks. I pushed the <stdbool.h> thing, which didn't require going back very far. > Before that, you get a ton of warnings and errors related to the node > tree walker routines. This is presumably related to commit 1c27d16e6e5. Alligator is now getting past the bool troubles and reaching that stuff. I was expecting it to be green in master. It's OK on my slightly older "gcc version 15.0.0 20241110 (experimental) (FreeBSD Ports Collection)" with -std=gnu23, but alligator now shows a weird error with tsearch data types. Something about flexible array members (casting from non-flex to flex?, without saying where the cast is?), but IDK, it's an internal error asking for a bug to be filed, not a user-facing one. This might be relevant: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688 > Going further back, the bool patch proposed here assumes that stdbool.h > exists unconditionally, which is C99, which is not the baseline for > older branches. I think for those it's probably best to leave it alone > and just use gcc-15 -std=gnu89 or whatever. There's only one C89 branch that knows about <stdbool.h>: REL_11_STABLE. That's recent enough that it's still easy to work with, so I just changed it to use AC_CHECK_HEADER instead. In other words, we've removed the bogus "conforms" check. Whether you still need a presence check depends on the C version, and only for 11 is the answer yes. Obviously nobody is really going to build with an actual C89 system so the presence check is never going to fail, but it would be weird on principle to suddenly require a C99 thing...
В списке pgsql-bugs по дате отправления: