Fedora Account System
Red Hat Associate
Red Hat Customer
This is a fairly recent regression, it was working until a few weeks ago: $ cat test.c #include <stdio.h> #include "Python.h" $ gcc -Wall -c test.c `pkgconf --cflags python-3.14-embed` In file included from /usr/include/python3.14/pyconfig.h:6, from /usr/include/python3.14/Python.h:14, from test.c:2: /usr/include/python3.14/pyconfig-64.h:2007:9: warning: ‘_POSIX_C_SOURCE’ redefined 2007 | #define _POSIX_C_SOURCE 200809L | ^~~~~~~~~~~~~~~ In file included from /usr/include/bits/libc-header-start.h:33, from /usr/include/stdio.h:28, from test.c:1: /usr/include/features.h:319:10: note: this is the location of the previous definition 319 | # define _POSIX_C_SOURCE 202405L | ^~~~~~~~~~~~~~~ Reproducible: Always Version: python3-devel-3.14.0-2.fc44.x86_64 Steps to Reproduce: 1. See instructions above.
This breaks nbdkit compilation with ./configure --enable-gcc-warnings
It gets stranger. I tried downgrading to the previous version of Python I was using (python3-devel-3.14.0~rc2-1.fc44.x86_64), and that has the same behaviour. So the problem was not caused by upgrading Python. I think it was caused by updating glibc (old: glibc-2.42.9000-8.fc44 current: glibc-2.42.9000-11.fc44). glibc has this change: -# define _POSIX_C_SOURCE 200809L +# define _POSIX_C_SOURCE 202405L Perhaps Python needs to be rebuilt against the new glibc? It would still be better if Python didn't try to define/redefine _POSIX_C_SOURCE, which could be easily done using #ifndef .. #endif around the definition.
The problem is this part: #include <stdio.h> #include "Python.h" The order is wrong. Those glibc feature test macros need to be defined first. | These directives must come before any #include of a system header file. <https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html>
Python.h must always be included first: https://docs.python.org/3/c-api/intro.html#include-files > Note > > Since Python may define some pre-processor definitions which affect the standard headers on some systems, you must include Python.h before any standard headers are included.
(In reply to Elliott Sales de Andrade from comment #4) > Python.h must always be included first: > https://docs.python.org/3/c-api/intro.html#include-files > > > Note > > > > Since Python may define some pre-processor definitions which affect the standard headers on some systems, you must include Python.h before any standard headers are included. I read this too, it's just I think this is a very dumb way of doing it. No other language binding needs this. Why would Python want to affect what the rest of the source file (user code) is doing?
(In reply to Richard W.M. Jones from comment #5) > (In reply to Elliott Sales de Andrade from comment #4) > > Python.h must always be included first: > > https://docs.python.org/3/c-api/intro.html#include-files > > > > > Note > > > > > > Since Python may define some pre-processor definitions which affect the standard headers on some systems, you must include Python.h before any standard headers are included. > > I read this too, it's just I think this is a very dumb way of doing it. No > other language binding needs this. Why would Python want to affect what > the rest of the source file (user code) is doing? It's required to set up things like _FILE_OFFSET_BITS to get the correct ABI. If other language bindings don't do this, it's likely they do not work correctly on 32-bit systems.
Not sure this is the place to litigate this, but the problem is Python setting _POSIX_C_SOURCE & _XOPEN_SOURCE. _FILE_OFFSET_BITS is also an issue, but Python itself would be wrong if it used off_t in any public APIs.
Not sure if we can do something about this on Fedora level.
> It's required to set up things like _FILE_OFFSET_BITS to get the correct ABI. Correct. See https://github.com/python/cpython/issues/141784 is a concrete recent example of this problem. On 32-bit Linux, ino_t type is 32-bit or 64-bit depending on the header include order. In short, as it has been said above, Python.h must be included first to get the expected type (64-bit ino_t). > Not sure if we can do something about this on Fedora level. I suggest to report this issue to Python upstream. Maybe there is a way to detect that some feature macro are already defined and emit a warning to guide developers to the fix (move Python.h include first).
We don't consider this a bug in Python. If you do, I encourage you to bring it upstream.