Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

static_assert undefined (with C11 compiler) on macOS <= 10.10 #99069

Closed
jmroot opened this issue Nov 3, 2022 · 10 comments
Closed

static_assert undefined (with C11 compiler) on macOS <= 10.10 #99069

jmroot opened this issue Nov 3, 2022 · 10 comments
Labels
OS-mac type-bug An unexpected behavior, bug, or error

Comments

@jmroot
Copy link
Contributor

jmroot commented Nov 3, 2022

Bug report

Python 3.11 fails to build on macOS 10.10 because static_assert is not defined by the libc headers, even when using a C11 compiler. A workaround like the one in place for FreeBSD is needed.

Your environment

  • CPython versions tested on: 3.11.0
  • Operating system and architecture: macOS 10.10 x86_64
@jmroot jmroot added the type-bug An unexpected behavior, bug, or error label Nov 3, 2022
@JelleZijlstra
Copy link
Member

Isn't MacOS 10.10 unsupported since 2017?

jmroot added a commit to jmroot/cpython that referenced this issue Nov 3, 2022
Several platforms don't define the static_assert macro despite having
compiler support for the _Static_assert keyword. The macro needs to be
defined since it is used unconditionally in the Python code. So it
should always be safe to define it if undefined and not in C++11 (or
later) mode.

Hence, remove the checks for particular platforms or libc versions,
and just define static_assert anytime it needs to be defined but isn't.
That way, all platforms that need the fix will get it, regardless of
whether someone specifically thought of them.

Also document that certain macOS versions are among the platforms that
need this.
@ned-deily
Copy link
Member

ned-deily commented Nov 3, 2022

Isn't MacOS 10.10 unsupported since 2017?

By Apple, but there are still many users of older versions of macOS. The python.org macOS installers currently support running on systems back through macOS 10.9 (but the binaries are built on newer versions on macOS so would not see this build error) and the MacPorts project (where this issue originated) supports back to macOS 10.6 and earlier.

@ambv
Copy link
Contributor

ambv commented Nov 7, 2022

I have no issue on principle with supporting builds on Mac OS X 10.9 even if that's no longer supported by Apple. That being said, it's a question worth asking: how long will we commit to supporting ancient macOS versions with the latest Python? I mean, GH-94766 isn't particularly bad but it's one example of additional maintenance required.

For Windows we dropped Windows 7 support not long after it was dropped by Microsoft and the first Windows 7-specific issue arose. There are some complaints about that but it's a somewhat strange requirement: the latest Python version on a very old operating system. For Windows users, we said: hey, Python 3.7 and 3.8 are still supported, use those instead on Windows 7.

Maybe at some point we should say the same about 10.9 Mavericks, unsupported since September 2016? Again, there are still-supported versions of Python that you can install on those old operating systems. The question is: should 3.12 keep piling workarounds for it?

@jmroot
Copy link
Contributor Author

jmroot commented Nov 7, 2022

From our (MacPorts) point of view, we're going to be adding these workarounds downstream anyway for a long time to come, so we might as well send them upstream.

@ronaldoussoren
Copy link
Contributor

Isn't MacOS 10.10 unsupported since 2017?

By Apple, but there are still many users of older versions of macOS. The python.org macOS installers currently support running on systems back through macOS 10.9 (but the binaries are built on newer versions on macOS so would not see this build error) and the MacPorts project (where this issue originated) supports back to macOS 10.6 and earlier.

Off-topic for this issue, but we need to start thinking about which OS releases we want to support in the installer. The Xcode 14 release notes mention:

Building for deployment to OS releases older than macOS 10.13, iOS 11, tvOS 11, and watchOS 4 is no longer supported. (92834476)

Apple no longer supports deploying to older macOS versions than 10.13 with the latest version of Xcode, while we should use the latest compiler and SDK to get best performance and access to new APIs.

W.r.t. this particular issue I don't mind adding a workaround for this given that a similar workaround is present for FreeBSD.

@ned-deily
Copy link
Member

WRT the dropping of support for older macOS releases in the latest Xcode/CLT, I plan to provide a new installer variant for 3.12 pre-releases that will use the latest tools. More to follow after alpha 2.

jmroot added a commit to jmroot/cpython that referenced this issue Nov 21, 2022
Several platforms don't define the static_assert macro despite having
compiler support for the _Static_assert keyword. The macro needs to be
defined since it is used unconditionally in the Python code. So it
should always be safe to define it if undefined and not in C++11 (or
later) mode.

Hence, remove the checks for particular platforms or libc versions,
and just define static_assert anytime it needs to be defined but isn't.
That way, all platforms that need the fix will get it, regardless of
whether someone specifically thought of them.

Also document that certain macOS versions are among the platforms that
need this.
@jmroot
Copy link
Contributor Author

jmroot commented Feb 19, 2023

Pinging as per the dev guide since the PR has been awaiting review for over a month.

vstinner added a commit that referenced this issue Apr 5, 2023
Several platforms don't define the static_assert macro despite having
compiler support for the _Static_assert keyword. The macro needs to be
defined since it is used unconditionally in the Python code. So it
should always be safe to define it if undefined and not in C++11 (or
later) mode.

Hence, remove the checks for particular platforms or libc versions,
and just define static_assert anytime it needs to be defined but isn't.
That way, all platforms that need the fix will get it, regardless of
whether someone specifically thought of them.

Also document that certain macOS versions are among the platforms that
need this.

The C2x draft (currently expected to become C23) makes static_assert
a keyword to match C++. So only define the macro for up to C17.

Co-authored-by: Victor Stinner <vstinner@python.org>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Apr 5, 2023
Several platforms don't define the static_assert macro despite having
compiler support for the _Static_assert keyword. The macro needs to be
defined since it is used unconditionally in the Python code. So it
should always be safe to define it if undefined and not in C++11 (or
later) mode.

Hence, remove the checks for particular platforms or libc versions,
and just define static_assert anytime it needs to be defined but isn't.
That way, all platforms that need the fix will get it, regardless of
whether someone specifically thought of them.

Also document that certain macOS versions are among the platforms that
need this.

The C2x draft (currently expected to become C23) makes static_assert
a keyword to match C++. So only define the macro for up to C17.

(cherry picked from commit 96e1901)

Co-authored-by: Joshua Root <jmr@macports.org>
Co-authored-by: Victor Stinner <vstinner@python.org>
miss-islington added a commit that referenced this issue Apr 5, 2023
Several platforms don't define the static_assert macro despite having
compiler support for the _Static_assert keyword. The macro needs to be
defined since it is used unconditionally in the Python code. So it
should always be safe to define it if undefined and not in C++11 (or
later) mode.

Hence, remove the checks for particular platforms or libc versions,
and just define static_assert anytime it needs to be defined but isn't.
That way, all platforms that need the fix will get it, regardless of
whether someone specifically thought of them.

Also document that certain macOS versions are among the platforms that
need this.

The C2x draft (currently expected to become C23) makes static_assert
a keyword to match C++. So only define the macro for up to C17.

(cherry picked from commit 96e1901)

Co-authored-by: Joshua Root <jmr@macports.org>
Co-authored-by: Victor Stinner <vstinner@python.org>
gaogaotiantian pushed a commit to gaogaotiantian/cpython that referenced this issue Apr 8, 2023
Several platforms don't define the static_assert macro despite having
compiler support for the _Static_assert keyword. The macro needs to be
defined since it is used unconditionally in the Python code. So it
should always be safe to define it if undefined and not in C++11 (or
later) mode.

Hence, remove the checks for particular platforms or libc versions,
and just define static_assert anytime it needs to be defined but isn't.
That way, all platforms that need the fix will get it, regardless of
whether someone specifically thought of them.

Also document that certain macOS versions are among the platforms that
need this.

The C2x draft (currently expected to become C23) makes static_assert
a keyword to match C++. So only define the macro for up to C17.

Co-authored-by: Victor Stinner <vstinner@python.org>
warsaw pushed a commit to warsaw/cpython that referenced this issue Apr 11, 2023
Several platforms don't define the static_assert macro despite having
compiler support for the _Static_assert keyword. The macro needs to be
defined since it is used unconditionally in the Python code. So it
should always be safe to define it if undefined and not in C++11 (or
later) mode.

Hence, remove the checks for particular platforms or libc versions,
and just define static_assert anytime it needs to be defined but isn't.
That way, all platforms that need the fix will get it, regardless of
whether someone specifically thought of them.

Also document that certain macOS versions are among the platforms that
need this.

The C2x draft (currently expected to become C23) makes static_assert
a keyword to match C++. So only define the macro for up to C17.

Co-authored-by: Victor Stinner <vstinner@python.org>
@ned-deily
Copy link
Member

@jmroot's fix for the immediate problem was merged by @vstinner to main in #94766 and in 3.11 (for 3.11.4) in #103282.

@th0ma7
Copy link

th0ma7 commented Jul 3, 2023

I believe this last patch #103282 is what makes build to fail on ARMv5 using gcc 4.6.4. This was working previously with Python 3.11.3 and fails since 3.11.4.

Here's my related PR to build Python 3.10 and 3.11 pacakges for Synology linux NAS
SynoCommunity/spksrc#5800

EDIT: Confirmed, now having a revert patch for that specific arch armv5. SynoCommunity/spksrc@8ca07f5
Note for others who may be in the same boat, in order to succesfully build Python 3.x using gcc 4.64 on armv5 where also enforcing C99 thus extending our luck a little longer https://github.com/SynoCommunity/spksrc/blob/master/cross/python311/patches/88f6281/005-configure.ac-remove-unknown-flags.patch

@jmroot
Copy link
Contributor Author

jmroot commented Jul 3, 2023

Relying on _Static_assert being accepted in C99 mode is certainly a hack, but if that's your goal you can probably get away with just removing or modifying the __STDC_VERSION__ >= 201112L part of the check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OS-mac type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

6 participants