all consumers were packaged and installed on amd64 by me; all python2
syntax in consumers appears to have been updated at this point making
it possible to move to the 4.x series.
lang/ghc bits look ok to gnezdo@
ok sthen@ on the rest
Some non-trivial adaptations:
* Remove -Wl,-z,notext from compiler flags
* Backport from ghc HEAD: move debugBelch into IF_DEBUG(linker)
* Move debugBelch into IF_DEBUG(linker) [fixup 3433]
* Undo ghci slowness [fixup 18727]
* Increase open FD limit for test runs to 1024
* Disable haddock on i386 using PFRAG
ok kili
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.
main changes are:
- add a new dep on py-requests
- undo the no longer needed iftex.sty workaround
- move MODPY variables to more standard location
- regen plist
Unfortunately py-sphinx changed the suffix from .txt to .rst.txt in the
1.5 series. This means we have to update PLISTs for about 20+ ports as
a result of this version update. Hopefully future updates of py-sphinx
won't be quite as involved.
ok sthen@
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).
If things go well, I'll try to jump to 8.10 (build 8.8 without
committing, build new bootstrappers from that, and then work on
8.10).
While here, make it possible to build the bootstrappers with
PORTS_PRIVSEP enabled (dirty and brittle, but works for me[tm]).
ghc and the hs-packages now simply include the necessary (haskell)
package description files in lib/ghc/package.conf.d and update the
package.cache by running ghc-pkg recache at the end. register and
unregister scripts are no longer needed.
To my surprise, it just works, and there are no hs library signature
changes, so there's no need to touch all the hs-* ports.
Next steps will be (in no particular order): enable PIE, update to
ghc 8.4, kill W^X, debug and fix the SIG(SEGV|TRAP|BUS|ILL) problems
with tehmplate haskell seen by some people.
are available fails badly if the ghc-prim package contains more
than one entry in the library-dirs: field, which is currently the
case for our ghc port.
Only check for the existance of vertain files in the first entry
of the library-dirs: field to re-enable tons of previously disabled
tests and to get rid of stupid "/bin/sh: [: ... unexpected
operator/operand" errors.
This should be fixed for real at both our side (don't include the
same directory twice in the library-dirs: field) and upstream (don't
rely on the library-dirs: field only containing one directory).
or ghc-8.2.x (yet untested).
Also, don't build iserv with -threading if multithreading is disabled
(which is the case for the bootstrappers we build). I could also have
patched out iserv from the bindist targets, but this way it's simpler.
ghc uses cc for generating object files from assembler files and
passes the CONF_CC_OPTS_STAGE? flags to it, which clang doesn't
like, so add -Wno-unused-command-line-argument to the flags passed
to cc if it's clang.
To let this work for the bootstrap compiler, properly CONFIGURE_ENV
when installing the bootstrap (in post-patch:). This also makes the
hack patching the bootstrap/bin/ghc script in post-patch: obsolete.
prodded by (and with some hints from) espie@
~here are still a lot of warnings, most about macros #defined in
storage/ClosureMacros.h. Those should be fixed in a separate step,
probably after an update to ghc-8.
as the patch shows).
you'll need to wait for a bootstrap/rebootrap yourself so this is actually
effective.
(should cut down *a lot* on the insane number of warnings produced due to
unknown compile options on a clang system)
okay kili@
