using MODGO_MODNAME.
This is needed to work around this issue:
https://github.com/golang/go/issues/27455
which makes `make clean` because of the restrictive permissions.
input and corrections from sthen@ and jca@
ok sthen@ jca@ espie@
I shoudn't have introduced EPOCH in the revert to camlp4-4.08+1, it was
not needed (the update to camlp4-4.10+1 didn't build) and it lead to
this PKGSPEC issue that I overlooked.
This fixes net/mldonkey, the last consumer of camlp4. Reported by naddy@
This allows for cleaning up the Makefile and for at least a chance
to get things like -z notext and -z wxneeded merged upstream for
amd64 *and* i386.
It also removes a -fno-pie hidden in patches/patch-configure.
Looks good to Greg, who also tested it by building xmonad and all
of its dependencies using cabal (in addition to my ordinary build
tests).
With this a port can be easily generated for Go applications that support Go
modules (there will be a go.mod file in the root of the project).
For example: https://github.com/jrick/domain/blob/master/go.mod
The mod file lists "github.com/jrick/domain" as the module name, so a portgen
command to build the above tool would be:
portgen go github.com/jrick/domain
OK afresh1@ kmos@
The build was broken due to some libffi defines being undefined on powerpc;
issue that does not cause runtime errors.
mips64 was impacted by the same issue, but later the build fails with a
SIGBUS (thanks to Janne Johansson who tested it there).
OK jca@
sthen@ reported that clisp sometimes fails to build, with an error at
MAP_ANON. Some tests, including MAP_ANON, might give a random 'no' when
their fixed addresses conflict with ASLR. Override to 'yes'.
ok sthen@
Python" messages, Python 2 development has finished so this is not a
sensible option to use as default.
(It is still kept in the ports tree for now, as some important software
has not been updated to use Python 3).
ok tracey aja mariani rpointel
From https://www.python.org/doc/sunset-python-2/, "We are volunteers who
make and take care of the Python programming language. We have decided
that January 1, 2020, was the day that we sunset Python 2. That means
that we will not improve it anymore after that day, even if someone
finds a security problem in it. You should upgrade to Python 3 as soon
as you can."
in the past (seen in "checking for Apache 2.0 handler-module support via DSO
through APXS" around Apr 2019), it's no longer happening, so remove the
block and allow building the Apache module on aarch64.
