getting added to _sysconfigdata, which results in some compiled Python
extensions picking it up.
noticed while investigating surprising memory use in LLVM 18+ while
compiling cython-generated C code (~700MB in LLVM 16/17; 10GB+ in 18).
llvm #124749
(since any python branch switch touches thousands of ports):
- stop using FLAVOR=python3 / MODPY_FLAVOR / etc in py3 ports.
- rename MODPY_EGG_VERSION (which refers to an obsolete packaging
format) with MODPY_DISTV (easier to type and line up in Makefiles)
bumps and adjustments to follow. lots of help from tb@, thanks!
with Python 3.9+'s definition of PyMODINIT_FUNC and our readline headers
https://github.com/openbsd/src/blob/master/gnu/lib/libreadline/rlstdc.h#L41
(Due to some other strangeness in the build system, on 3.9 it rebuilt a
working version after the first attempt failed and the file was moved out
of the way, but that no longer happens with 3.10+ where readline just
failed).
Fix up PLISTs and WANTLIB for Python 3.11 while there.
Joint work with landry@ tb@ kmos@, ok tb kmos
This unbreaks python 3.* on powerpc. The build had enabled PGO
(Profile Guided Optimization), then got "Segmentation fault" from the
./python binary. This seems to be a bug in clang or lld specific to
32-bit powerpc. We continue to --enable-optimizations on powerpc64.
ok kmos@, sthen@
except for Python-2.7, which stays with 8.5.
Make COMMENTs and DESCRs consistent with Tk.
Fix typo in 3.10/files/CHANGES.OpenBSD.
OKs and thanks to kmos@, sthen@.
if you want to run some software that needs an older or newer version
of Python you can do so in most cases. For the default versions (2.7, 3.9)
pip is available from the separate port (devel/py2-pip, devel/py-pip).
Factor out some common parts to ../Makefile.inc while there. OK kmos@
The goal is to shuffle things around allowing us to use this variable in
the packing lists. This should reduce a little bit of churn going
forward given some files get bumped with every point release.
For example in Python 3.9 we make the following update:
-lib/python3.9/lib2to3/Grammar3.9.10.final.0.pickle
+lib/python3.9/lib2to3/Grammar${FULL_VERSION}.final.0.pickle
-lib/python3.9/lib2to3/PatternGrammar3.9.10.final.0.pickle
+lib/python3.9/lib2to3/PatternGrammar${FULL_VERSION}.final.0.pickle
ok kmos@ (MAINTAINER), sthen@
Add a new SUBST_VARS variable that is set to "@comment " on
most Python versions, but is set to "" on the default one. This makes
it easier to swap between default versions because you don't need
to figure out which @comments should be kept and which should be moved.
While there I remove some existing lines with @comment markers for
files that are not created by any of our current Python ports:
@comment bin/pyvenv
@comment lib/libpython3.8m.so (etc)
The @comment -> ${PY_DEFAULTONLY} change doesn't affect the generated
PLISTs at all, so for that a REVISION bump is unnecessary, but removing
the pyvenv/libpython3.Xm.so does require a bump
right now the installed python retains paths to the python build objdir,
and also enforces -L/usr/local/lib when linking python shared extensions
(which might not be desired):
$python3 -m sysconfig|grep LDSH
BLDSHARED = "cc -pthread -shared -fPIC -L/usr/local/lib/ -L/usr/obj/ports/Python-3.8.12/Python-3.8.12 -L/usr/local/lib/"
LDSHARED = "cc -pthread -shared -fPIC -L/usr/local/lib/ -L/usr/obj/ports/Python-3.8.12/Python-3.8.12 -L/usr/local/lib/"
python 3.x provides LDFLAGS_NODIST/CFLAGS_NODIST to avoid that (cf
https://docs.python.org/3/using/configure.html#envvar-CONFIGURE_LDFLAGS_NODIST),
but sadly if we only use it (and remove CPPFLAGS/LDFLAGS pointing at
/usr/local from CONFIGURE_ENV), libintl/textdomain detection during
configure fails.
So, taking inspiration from freebsd PR181721, dont add
CONFIGURE_LDFLAGS/CONFIGURE_CPPFLAGS to PY_LDFLAGS/PY_CPPFLAGS.
extend CHANGES.OpenBSD to explain the change (reminded by sthen@).
went in a bulk build (thanks ajacoutot@!) with a single fallout
(devel/gdb) that will get fixed shortly.
allows some additional debugging features for Python-based software
(for example there's a new "py-bt" command to print a Python backtrace
which can give clues if a py process is hanging).
ok rpointel@
An earlier diff was okayed by rpointel@, kmos@. sthen@ requested to move
the @conflict and @pkgpath markers from 3.7 to 3.8 in the same commit (a
better approach). Final diff was ok sthen@.
already run into it myself. Add comments to hopefully make it simpler
and more understandable for future changes to the default version.
Zero feedback but tests well here, committing before I forget about
it because people will run into this with 6.7.
Follow the upstream recommendations for packagers and switch to
multi-packages:
devel/gettext -> devel/gettext,-runtime
devel/gettext-tools -> devel/gettext,-tools
(new) devel/gettext,-textstyle
- sync WANTLIB
- use do-gen instead of post-patch for the "subst and regen
autoconf files" target
- ALL_TARGET needs setting differently between 2.7 and 3.x;
rather than checking against 3.6 for "all", check against 2.7
for "all ./Lib/plat-openbsd6". needed for newer 3.x.
on clang arches this is a noop, on !clang arches this gives a path to
the estdc++ WANTLIB. needed because this is a multi-package port and
LIB_DEPENDS-main doesn't include the default LIB_DEPENDS added by
gcc4.port.mk.
some existing COMPILER lines with arch restrictions etc. In the usual
case this is now using "COMPILER = base-clang ports-gcc base-gcc" on
ports with c++ libraries in WANTLIB.
This is basically intended to be a noop on architectures using clang
as the system compiler, but help with other architectures where we
currently have many ports knocked out due to building with an unsuitable
compiler -
- some ports require c++11/newer so the GCC version in base that is used
on these archirtectures is too old.
- some ports have conflicts where an executable is built with one compiler
(e.g. gcc from base) but a library dependency is built with a different
one (e.g. gcc from ports), resulted in mixing incompatible libraries in the
same address space.
devel/gmp is intentionally skipped as it's on the path to building gcc -
the c++ library there is unused in ports (and not built by default upstream)
so intending to disable building gmpcxx in a future commit.
This will allow us to drop patches and substitutions in our ports tree. Nowadays
most upstreams don't hardcode the path to python but instead use env(1) to find
the path.
bulk tested
ok sthen@
ok and input from rpointel@ (on an older patch)
with native c++ code worked fine. We no longer need to do that, and
llvm errors out with the non-sensical combination of "c++ -std=c99".
this fixes the python build on arm64
tested by sthen@ in an i386 bulk, thanks!
OK sthen@, rpointel@ (maintainer)
sthen