Searches without login should now work. You must get asked to click a button.
Port details
python39Interpreted object-oriented programming language
3.9.24langΣ=21 3.9.24Version of this port present on the latest quarterly branch.
DEPRECATED: Upgrade to a newer Python version. 3.9 is in maintenance status and gets security fixes only. End-of-Life: 2025-10. See https://devguide.python.org/versions/ This port expired on: 2025-10-31
===> The following configuration options are available for python39-3.9.24:
DEBUG=off: Build with debugging support
IPV6=on: IPv6 protocol support
LIBMPDEC=on: Use libmpdec from ports instead of bundled version
LTO=off: Use Link-Time Optimization
NLS=on: Enable gettext support for the locale module
PYMALLOC=on: Enable specialized mallocs
====> Hash Algorithm (PEP-456): you can only select none or one of them
FNV=off: Modified Fowler-Noll-Vo Algorithm
SIPHASH=off: SipHash24 Algorithm
===> Use 'make config' to modify these settings
port deleted on 2025-11-01 REASON: Has expired: Upgrade to a newer Python version. 3.9 is in maintenance status and gets security fixes only. End-of-Life: 2025-10. See https://devguide.python.org/versions/
port moved here from lang/python38 on 2025-03-31 REASON: Has expired: Reached end-of-life in October 2024
lang/python39: Remove expired port
2025-10-31 lang/python39: Upgrade to a newer Python version. 3.9 is in
maintenance status and gets security fixes only. End-of-Life: 2025-10. See
https://devguide.python.org/versions/
python.mk: rename PYTHON_EXT_SUFFIX to PYTHON_TAG, document, etc
EXT_SUFFIX, according to PEP 3149, refers to the full tag and
extension for compiled extension module objects, eg .cpython-311.so,
.cpython-313t.so, etc. We do not use the correct semantic meaning,
and this usage becomes ambiguous and confusing when tags do not
match between bytecode and compiled extension module objects.
Rename our PYTHON_EXT_SUFFIX to PYTHON_TAG to align with PEP 3147's
specification of a magic tag, which consists of implementation name
and shorthand version only. This is meant for bytecode and other
files containing this tag in their filename that do not depend on
a specific Python ABI for the same version. Chase all existing
consumers.
(Only the first 15 lines of the commit message are shown above )
lang/python39: Deprecate/Set to expire
* Python 3.9 will reach its End-of-Life on 2025-10. Set the expiration
date accordingly.
Reviewed by: sunpoet (python, maintainer)
Differential Revision: https://reviews.freebsd.org/D48900
*/*: Sunset 12.4-RELEASE/12-STABLE from ports tree
- Remove all references to defunct ARCH arm
- Remove all references to defunct ARCH sparc64
- Remove x11-drivers/xf86-video-sunffb which requires defunct sparc64
ARCH
- Remove sysutils/afbinit requires defunct sparc64 ARCH
- Remove all references to bktr driver
- Remove all references to defunct FreeBSD_12
- Remove all references to OSVERSION/OSREL corresponding to 12
- Remove conditionals in Mk/Uses/cabal.mk
- Remove sparc reference from Mk/Uses/qt-dist.mk
- Remove BROKEN_sparc64/NOT_FOR_ARCH=sparc64
- Remove BROKEN_FreeBSD_12* from:
- Remove OpenSSL patches from:
- Remove conditional flags for OSVERSION >= 1300000 to fixed flags.
Also move conditional flags for non sparc64/arm ARCH to fixed flags.
Reviewed by: brooks, jbeich, rene, salvadore
Differential Revision: https://reviews.freebsd.org/D42068
lang/python: restore USES=python variables and SUB_LIST (no-op)
Has been a to do item for time. These are independent from but used
by the bytecode trigger.
lang/python: Revert "add bytecode trigger"
This reverts commit c17ddfbf66e2801ec620d49979aca3d7077d7002.
This causes breakage on several ports, and the next iteration
requires a full exp-run. See:
Differential Revision: https://reviews.freebsd.org/D34739
lang/python3: allow using LTO on powerpc64
It was recently fixed and will be available in 13.2-RELEASE.
Since LTO is not enabled by default, it's ok to make it available.
lang/python: add bytecode trigger
Facilitates compiling, writing and removing bytecode files (.pyc)
in site-packages after all pkg transactions have been completed.
Technical details: https://wiki.freebsd.org/Python/CompiledPackages
Fixes reports of Python port builds as root failing on filesystem
violations due to bytecode file writes where the port did not include
them in the package.
For those ports/packages that currently package bytecode, some
checksum mismatches on those files may occur. This is harmless and
will be rectified, in large as part of a USE_PYTHON=distutils
overhaul to reduce churn.
While here, implement a long-standing todo item of letting lang/python
ports use python.mk bits. Not only does this obviate duplicate
variables in each Makefile, but SUB_LIST (also added) is used for
these triggers.
Co-authored by: tcberner
Approved by: tcberner (mentor)
Differential Revision: https://reviews.freebsd.org/D34739
Remove WWW entries moved into port Makefiles
Commit b7f05445c00f has added WWW entries to port Makefiles based on
WWW: lines in pkg-descr files.
This commit removes the WWW: lines of moved-over URLs from these
pkg-descr files.
Approved by: portmgr (tcberner)
Add WWW entries to port Makefiles
It has been common practice to have one or more URLs at the end of the
ports' pkg-descr files, one per line and prefixed with "WWW:". These
URLs should point at a project website or other relevant resources.
Access to these URLs required processing of the pkg-descr files, and
they have often become stale over time. If more than one such URL was
present in a pkg-descr file, only the first one was tarnsfered into
the port INDEX, but for many ports only the last line did contain the
port specific URL to further information.
There have been several proposals to make a project URL available as
a macro in the ports' Makefiles, over time.
(Only the first 15 lines of the commit message are shown above )
lang: remove 'Created by' lines
A big Thank You to the original contributors of these ports:
* Aaron Dalton <aaron@FreeBSD.org>
* Adam Weinberger <adamw@FreeBSD.org>
* Akinori MUSHA aka knu <knu@idaemons.org>
* Alex Dupre <ale@FreeBSD.org>
* Alexey Dokuchaev <danfe@FreeBSD.org>
* Alonso Cardenas Marquez <acm@FreeBSD.org>
* Andreas Klemm <andreas@klemm.gtn.com>
* Andrew Pantyukhin <infofarmer@FreeBSD.org>
* Andrey Zakhvatov
* Anton Berezin <tobez@FreeBSD.org>
* Anton Berezin <tobez@tobez.org>
(Only the first 15 lines of the commit message are shown above )
lang/python3*: add LTO option and enable by default everywhere except powerpc64
and riscv64
PR: 261974
Approved by: python (koobs got his commit bit revoked during review process)
lang/python3(6|7|8|9|10|11): work around unwanted multiarch detection again
In ports 6bef09666460 we patched out python's erroneous multiarch
detection using sed, but upstream changed the surrounding parts in the
configure script to defeat the regex we were using. Update the regex to
cope with the change.
PR: 259896, 258377
MFH: 2021Q4
Approved by: maintainer timeout (9 days)
lang/python3X: Fix library installation
The Python ports install the library libpython3.x.so under $PREFIX/lib,
and they set USE_LDCONFIG, but these libraries are not registered, due
to a missing symlink, and they are not found by `ldconfig -r'.
This commit make them to be registered, and for some reason it helps the
dynamic linker to find them, and this allows to fix an error in
french/aster. It also helps to fix errors in newer releases of math/sage
(not yet ready to be committed due to other problems).
No exp-run, but it has been tested with many ports on several platforms.
PR: 257864
Approved by: koobs (Python team)
MFH: 2021Q4
lang/python3([6-9]|10): disable detection of multiarch
It breaks with clang >= 13, which adds a major.minor version number in
-print-multiarch output, and the dot confuses Python:
ModuleNotFoundError: No module named
'_sysconfigdata__freebsd14_x86_64-unknown-freebsd14'
Since we do not support multiarch, and the configure script has no way
to disable the multiarch check, stub it out during post-patch.
PR: 258377
Approved by: maintainer timeout (2 weeks)
MFH: 2021Q3
lang/python*: Replace DISABLED_EXTENSIONS with Setup.local
Currently, lang/python38 and lang/python39 don't honor
DISABLED_EXTENSIONS because patch-issue20210 was removed when
lang/python38 was added to the ports tree. patch-issue20210 is still
present on lang/python36 and lang/python37.
Building with poudriere is not affected because builds are executed in a
clean environment.
Setup.local is the more canonical and recommended method for customizing
Python builds for shared extensions & third party libraries.
Support for a *disabled* marker in Setup files was introduced in Python
3.7, so backport this fix to it to keep consistency in the ports tree.
PR: 243358 [1]
PR: 243937 [2]
Reported by: ngie [1]
Reported by: jcfyecrayz@liamekaens.com [2]
Reported by: tuxillo (IRC) DPorts
Reviewed by: koobs (python, maintainer)
Approved by: koobs, dbaio (python, maintainer)
MFH: 2021Q3 (build bugfix)
Differential Revision: https://reviews.freebsd.org/D31086
lang/python3[89]: remove LIBFFI option
Python now requires libffi from ports and does not build with LIBFFI
disabled, so remove the option.
PR: 256141
Reported by: majo-bugs.freebsd.org@cerny.sk
Reviewed by: koobs (python)
Approved by: koobs (python)
MFH: 2020Q2 (bugfix)
Mk: switch from PYTHON_PORTVERSION to PYTHON_DISTVERSION
This brings python framework in consistense with handbook recommendations
to prefer DISTVERSION and simplifies adding prerelease versions of
python
PR: 255013
Differential Revision: https://reviews.freebsd.org/D29418
Exp-run by: antoine
Approved by: wen@, no objection from python@ or portmgr@
lang/python3{6,7,8,9}: Backport close_range patches
Worked out over BPO-40422 and BPO-40423, this is the culmination of months
of work to coordinate with Linux and get close_range(2) added to FreeBSD,
then the usage accepted into CPython. It has landed for Python 3.10 and here
I've backported it locally to all the supported Python 3 versions we have.
Note that this does include and supercede our previous closefrom(2) patches.
There was a lot of intersection between the work done, so this patch against
the ports tree does remove those patches from each of the ports in favor of
this patch. All the patches involved have been accepted and merged upstream.
This patch will bring a performance boost in some more situations on 12.2
and 13.0, as close_range exists there.
There is one additional patch sitting in an upstream PR that shuffles the
_Py_closerange implementation into a different file -- this is not important
for the backport, and the absence of that patch here will not realistically
cause any issues.
PR: 250322
Approved by: lwhsu (python)
lang/python39: fix build on GCC architectures
Use newer GCC:
/wrkdirs/usr/ports/lang/python39/work/Python-3.9.0/Modules/_zoneinfo.c: In
function 'calendarrule_new':
/wrkdirs/usr/ports/lang/python39/work/Python-3.9.0/Modules/_zoneinfo.c:1227:
error: #pragma GCC diagnostic not allowed inside functions
/wrkdirs/usr/ports/lang/python39/work/Python-3.9.0/Modules/_zoneinfo.c:1228:
error: #pragma GCC diagnostic not allowed inside functions
/wrkdirs/usr/ports/lang/python39/work/Python-3.9.0/Modules/_zoneinfo.c:1229:
warning: comparison is always false due to limited range of data type
/wrkdirs/usr/ports/lang/python39/work/Python-3.9.0/Modules/_zoneinfo.c:1230:
error: #pragma GCC diagnostic not allowed inside functions
