if a port needs 2.x then set MODPY_VERSION=${MODPY_DEFAULT_VERSION_2}.
This commit doesn't change any versions currently used; it may be that
some ports have MODPY_DEFAULT_VERSION_2 but don't require it, those
should be cleaned up in the course of updating ports where possible.
Python module ports providing py3-* packages should still use
FLAVOR=python3 so that we don't have a mixture of dependencies some
using ${MODPY_FLAVOR} and others not.
Upstream now considers this the Classic Flang compiler in contrast to the
new Flang compiler, formerly known as f18, that has recently been
upstreamed into LLVM.
This requires the use of eg++ to build libpgmath; about a year and a half
ago, building the arm64-specific math routines broke when compiling with
clang (a clang bug) so we switched to the generic math routines only. Now,
build system changes make building generic math routines only impossible,
so we now must build libpgmath on arm64 with eg++. I have gotten tired of
waiting for a potential fix to allow building with clang again.
Thanks to phessler@, who put the diff into a bulk build (and spotted me
fat-fingering the linker invocation).
Flang now again builds and works properly on arm64. No change on amd64.
!amd64 to be unsigned int, which doesn't fly here.
No change on amd64; this fix fixes a preprocessor branch that is only
followed on arm64.
Noticed from the latest aarch64 bulk build log.
This syncs the flang patches with the devel/llvm patches, as well as
updates flang to its latest upstream code.
My test suite passes on amd64. Any arm64 changes, if needed, will be
committed in the coming days.
Do the same thing we do with the flang driver and force linking with the
static libraries instead.
Reported off-list by j <AT> bitminer <DOT> ca -- thanks!
While here, remove some comments in Makefile.inc about flang being
integrated into LLVM. That's no longer happening; the new f18 compiler is
scheduled to be integrated into LLVM instead.
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.
libpgmath CMakeLists.txt files. This worked out to -mcpu=native on the
arm64 package builders, which clang doesn't support. Remove all those flags
which should get flang building again on arm64.
Found looking at phessler@'s arm64 bulk build report.
update also brings in an MD version of libpgmath for arm64 (like it is on
amd64); however, this arm64 MD version is currently disabled until I am
able to test it.
