Re: Delay lang/ghc upgrade to 9.8.2?
On 2024/05/21 20:29, Greg Steuck wrote: > The only thing we should do with the port soon is remove the AWX-512 > patch. It helped the new machines when base system didn't support > AWX-512. Now that it does, we should drop the patch that breaks some > very old machines. Done on 2024/05/05.
Delay lang/ghc upgrade to 9.8.2?
Hi Matthias, Even though we have everything lined up to switch to ghc-9.8.2, I'm having second thoughts. GHC release plans here deprioritize this branch: https://www.haskell.org/ghc/blog/20240521-ghc-release-priorities.html Unless somebody has a good reason for us to jump, I propose we keep the ports tree following the 9.6 series. If 9.8.3 appears before 9.6.6, we can reconsider. The only thing we should do with the port soon is remove the AWX-512 patch. It helped the new machines when base system didn't support AWX-512. Now that it does, we should drop the patch that breaks some very old machines. Thanks Greg
Re: A couple more lang/ghc fixups
Hi,
On Sat, Jan 27, 2024 at 10:49:42PM -0800, Greg Steuck wrote:
> Now that we landed ghc-9.6 is a good time to have `make test` fixed. It
> took some doing to have them all fixed upstream and even then some of the
> fixes are still not in 9.6. Anyway, OK?
Ok.
Ciao,
Kili
> ---
> lang/ghc/Makefile | 20 ++----------
> lang/ghc/distinfo | 2 --
> 2 files changed, 2 insertions(+), 20 deletions(-)
>
> diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
> index 9aa4f19d65c..1612e816c88 100644
> --- a/lang/ghc/Makefile
> +++ b/lang/ghc/Makefile
> @@ -39,8 +39,8 @@ LIB_DEPENDS = converters/libiconv \
> devel/libffi
>
> BUILD_DEPENDS = archivers/bzip2 \
> - archivers/gtar \
> - textproc/py-sphinx${MODPY_FLAVOR}>=4.0.2
> + archivers/gtar
> +
> RUN_DEPENDS =
>
> SITES =
> https://downloads.haskell.org/ghc/${GHC_VERSION}/
> @@ -61,17 +61,7 @@ DISTFILES.boot = ${BINDISTFILE-${MACHINE_ARCH}}
> DISTFILES.noextract =hadrian-sources-${BIN_VER}.tar.gz
> SITES.noextract =https://openbsd.dead-parrot.de/distfiles/
>
> -# sphinx-rtd-theme update patch set
> -# mirrored from
> https://gitlab.haskell.org/ghc/ghc/-/commit/70526f5bd8886126f49833ef20604a2c6477780a.patch
> -# "GIT binary patch" (gpatch doesn't handle it, patch segfaults)
> -# (sorry! -sthen)
> -SITES.p =https://spacehopper.org/mirrors/
> -DISTFILES.p += ghc-rtd-update-70526f5bd8.diff
> EXTRACT_ONLY = ${DISTFILES} ${DISTFILES.boot}
> -BUILD_DEPENDS += devel/git
> -pre-patch:
> - cd ${WRKSRC}; env -i git apply
> ${FULLDISTDIR}/ghc-rtd-update-70526f5bd8.diff
> -
>
> # Substvars for all libraries, assuming that ghc-boot, ghc-boot-th,
> # ghc-heap and ghci will always have the same version number as ghc.
> @@ -136,9 +126,6 @@ CONFIGURE_ENV +=
> CONF_GCC_LINKER_OPTS_STAGE0="${GHC_CC_OPTS}" \
> CONF_GCC_LINKER_OPTS_STAGE2="${GHC_CC_OPTS}" \
> CONF_CC_OPTS_STAGE2="${GHC_CC_OPTS}"
>
> -# Do not pick up gpatch
> -CONFIGURE_ENV += ac_cv_path_PatchCmd=/usr/bin/patch
> -
> MAKE_FLAGS +=StripLibraries=YES \
> INSTALL_BIN_OPTS=-s \
> HSCOLOUR_SRCS=NO \
> @@ -147,9 +134,6 @@ MAKE_FLAGS += StripLibraries=YES \
> # haddock: ... : commitBuffer: invalid argument (invalid character)
> MAKE_ENV = LC_ALL=en_US.UTF-8
>
> -# For mktexpk (via dvips when building the PostScript documentation):
> -PORTHOME = ${WRKDIR}
> -
> TEST_DEPENDS = print/ghostscript/gnu ${MODPY_RUN_DEPENDS}
>
> post-extract:
> diff --git a/lang/ghc/distinfo b/lang/ghc/distinfo
> index 2a2065aa251..3c92fd3f3be 100644
> --- a/lang/ghc/distinfo
> +++ b/lang/ghc/distinfo
> @@ -2,11 +2,9 @@ SHA256 (ghc/ghc-9.6.4.20240111-amd64.tar.xz) =
> CedJ29vBFZyl1e+DgcUqPfjHMDRKmEOsX
> SHA256 (ghc/ghc-9.6.4.20240111-shlibs-amd64.tar.gz) =
> Nb3trqnIF8H5kfKEkeGLr+sl4rPeFsbW/gfkelRprrY=
> SHA256 (ghc/ghc-9.6.4-src.tar.xz) =
> EL8luLBxdP3ZhotcDFbBfA7x7ctiR7S4ZL6TNlG/1MA=
> SHA256 (ghc/ghc-9.6.4-testsuite.tar.xz) =
> bhMoL76//b+gpJiJQ3REyakM/ldgxHlpzUJFhUwzjXM=
> -SHA256 (ghc/ghc-rtd-update-70526f5bd8.diff) =
> maCALPRglB5J9LJEQxBqMGdVbH4qK2gqVuaU5xmYdNU=
> SHA256 (ghc/hadrian-sources-9.6.4.20240111.tar.gz) =
> wMMJfyP7Pr6xjb/tj9Kz5iZugGr6+duMwJ23aGsUWy0=
> SIZE (ghc/ghc-9.6.4-src.tar.xz) = 29451856
> SIZE (ghc/ghc-9.6.4-testsuite.tar.xz) = 7075820
> SIZE (ghc/ghc-9.6.4.20240111-amd64.tar.xz) = 74706384
> SIZE (ghc/ghc-9.6.4.20240111-shlibs-amd64.tar.gz) = 3544885
> -SIZE (ghc/ghc-rtd-update-70526f5bd8.diff) = 4245853
> SIZE (ghc/hadrian-sources-9.6.4.20240111.tar.gz) = 2125322
> \ No newline at end of file
> --
> 2.43.0
>
> >From 11e6bf454004e8e60894c7259f8c3a8fbd49525d Mon Sep 17 00:00:00 2001
> From: Greg Steuck
> Date: Sat, 27 Jan 2024 19:16:24 -0800
> Subject: [PATCH 2/2] Fix `make test` in lang/ghc
>
> ---
> lang/ghc/Makefile | 31 ++++++-----
> .../patches/patch-compiler_GHC_Unit_State_hs | 2 +-
> .../patch-libraries_process_tests_all_T | 12 +++
> .../patches/patch-testsuite_driver_testlib_py | 10 +++---
> 4 files changed, 33 insertions(+), 22 deletions(-)
> create mode 100644 lang/ghc/patches/patch-libraries_process_tests_all_T
>
> diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
> index 1612e816c88..dc02ebab65a 100644
> --- a/lang/ghc/Makefile
> +++ b/lang/ghc/Makefile
> @@ -132,7 +132,7 @@ MAKE_FLAGS +=
A couple more lang/ghc fixups
Now that we landed ghc-9.6 is a good time to have `make test` fixed. It
took some doing to have them all fixed upstream and even then some of the
fixes are still not in 9.6. Anyway, OK?
>From fe0577aab710d1a3c5c5e4178088ffe96a2da07d Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 14 Jan 2024 14:20:59 -0800
Subject: [PATCH 1/2] Remove sphinx dependency now that we no longer build
lang/ghc docs
---
lang/ghc/Makefile | 20 ++--
lang/ghc/distinfo | 2 --
2 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
index 9aa4f19d65c..1612e816c88 100644
--- a/lang/ghc/Makefile
+++ b/lang/ghc/Makefile
@@ -39,8 +39,8 @@ LIB_DEPENDS = converters/libiconv \
devel/libffi
BUILD_DEPENDS =archivers/bzip2 \
- archivers/gtar \
- textproc/py-sphinx${MODPY_FLAVOR}>=4.0.2
+ archivers/gtar
+
RUN_DEPENDS =
SITES =
https://downloads.haskell.org/ghc/${GHC_VERSION}/
@@ -61,17 +61,7 @@ DISTFILES.boot = ${BINDISTFILE-${MACHINE_ARCH}}
DISTFILES.noextract = hadrian-sources-${BIN_VER}.tar.gz
SITES.noextract = https://openbsd.dead-parrot.de/distfiles/
-# sphinx-rtd-theme update patch set
-# mirrored from
https://gitlab.haskell.org/ghc/ghc/-/commit/70526f5bd8886126f49833ef20604a2c6477780a.patch
-# "GIT binary patch" (gpatch doesn't handle it, patch segfaults)
-# (sorry! -sthen)
-SITES.p = https://spacehopper.org/mirrors/
-DISTFILES.p += ghc-rtd-update-70526f5bd8.diff
EXTRACT_ONLY = ${DISTFILES} ${DISTFILES.boot}
-BUILD_DEPENDS += devel/git
-pre-patch:
- cd ${WRKSRC}; env -i git apply
${FULLDISTDIR}/ghc-rtd-update-70526f5bd8.diff
-
# Substvars for all libraries, assuming that ghc-boot, ghc-boot-th,
# ghc-heap and ghci will always have the same version number as ghc.
@@ -136,9 +126,6 @@ CONFIGURE_ENV +=
CONF_GCC_LINKER_OPTS_STAGE0="${GHC_CC_OPTS}" \
CONF_GCC_LINKER_OPTS_STAGE2="${GHC_CC_OPTS}" \
CONF_CC_OPTS_STAGE2="${GHC_CC_OPTS}"
-# Do not pick up gpatch
-CONFIGURE_ENV += ac_cv_path_PatchCmd=/usr/bin/patch
-
MAKE_FLAGS += StripLibraries=YES \
INSTALL_BIN_OPTS=-s \
HSCOLOUR_SRCS=NO \
@@ -147,9 +134,6 @@ MAKE_FLAGS += StripLibraries=YES \
# haddock: ... : commitBuffer: invalid argument (invalid character)
MAKE_ENV = LC_ALL=en_US.UTF-8
-# For mktexpk (via dvips when building the PostScript documentation):
-PORTHOME = ${WRKDIR}
-
TEST_DEPENDS = print/ghostscript/gnu ${MODPY_RUN_DEPENDS}
post-extract:
diff --git a/lang/ghc/distinfo b/lang/ghc/distinfo
index 2a2065aa251..3c92fd3f3be 100644
--- a/lang/ghc/distinfo
+++ b/lang/ghc/distinfo
@@ -2,11 +2,9 @@ SHA256 (ghc/ghc-9.6.4.20240111-amd64.tar.xz) =
CedJ29vBFZyl1e+DgcUqPfjHMDRKmEOsX
SHA256 (ghc/ghc-9.6.4.20240111-shlibs-amd64.tar.gz) =
Nb3trqnIF8H5kfKEkeGLr+sl4rPeFsbW/gfkelRprrY=
SHA256 (ghc/ghc-9.6.4-src.tar.xz) =
EL8luLBxdP3ZhotcDFbBfA7x7ctiR7S4ZL6TNlG/1MA=
SHA256 (ghc/ghc-9.6.4-testsuite.tar.xz) =
bhMoL76//b+gpJiJQ3REyakM/ldgxHlpzUJFhUwzjXM=
-SHA256 (ghc/ghc-rtd-update-70526f5bd8.diff) =
maCALPRglB5J9LJEQxBqMGdVbH4qK2gqVuaU5xmYdNU=
SHA256 (ghc/hadrian-sources-9.6.4.20240111.tar.gz) =
wMMJfyP7Pr6xjb/tj9Kz5iZugGr6+duMwJ23aGsUWy0=
SIZE (ghc/ghc-9.6.4-src.tar.xz) = 29451856
SIZE (ghc/ghc-9.6.4-testsuite.tar.xz) = 7075820
SIZE (ghc/ghc-9.6.4.20240111-amd64.tar.xz) = 74706384
SIZE (ghc/ghc-9.6.4.20240111-shlibs-amd64.tar.gz) = 3544885
-SIZE (ghc/ghc-rtd-update-70526f5bd8.diff) = 4245853
SIZE (ghc/hadrian-sources-9.6.4.20240111.tar.gz) = 2125322
\ No newline at end of file
--
2.43.0
>From 11e6bf454004e8e60894c7259f8c3a8fbd49525d Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 27 Jan 2024 19:16:24 -0800
Subject: [PATCH 2/2] Fix `make test` in lang/ghc
---
lang/ghc/Makefile | 31 ++-
.../patches/patch-compiler_GHC_Unit_State_hs | 2 +-
.../patch-libraries_process_tests_all_T | 12 +++
.../patches/patch-testsuite_driver_testlib_py | 10 +++---
4 files changed, 33 insertions(+), 22 deletions(-)
create mode 100644 lang/ghc/patches/patch-libraries_process_tests_all_T
diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
index 1612e816c88..dc02ebab65a 100644
--- a/lang/ghc/Makefile
+++ b/lang/ghc/Makefile
@@ -132,7 +132,7 @@ MAKE_FLAGS += StripLibraries=YES \
BUILD_SPHINX_PDF=NO
# haddock: ... : commitBuffer: invalid argument (invalid character)
-MAKE_ENV = LC_ALL=en_US.UTF-8
+MAKE_ENV +=LC_ALL=en_US.UTF-8
TEST_DEPENDS = print/ghostscript/gnu ${MODPY_RUN_DEPENDS}
@@ -162,17 +162,20 @@ post-patch:
cd ${WRKSRC} && \
${MODPY_BIN} hadrian/bootstrap/bootstrap.py --no-archive
Re: new bootstrap for lang/ghc
Hi Greg, On Tue, Sep 26, 2023 at 08:47:09PM -0700, Greg Steuck wrote: > > My internet connection is currently almost completely > > broken. > > Do you also host the bootstrap files there? Should we considering > mirroring them somewhere else? No. The bootstrap files are on a machine running in our data center at work, where also have enough bandwidth. The networking problems are here at home, from where I normally commit. Ciao, Kili
Re: new bootstrap for lang/ghc
Matthias Kilian writes: > Greg asked me to provide a new ghc boostrap. Here it is; i could built > lang/ghc and all ports depending on it with it. Thank you Matthias! > If it's ok to put it in before release, could someone else please > commit it? I intend to your patch as is once my build succeeds unless somebody tells me not to. > My internet connection is currently almost completely > broken. Do you also host the bootstrap files there? Should we considering mirroring them somewhere else? Thanks Greg
Re: new bootstrap for lang/ghc
Marc Espie writes: > On Tue, Sep 26, 2023 at 10:29:57PM +0200, Matthias Kilian wrote: >> Hi, >> >> Greg asked me to provide a new ghc boostrap. Here it is; i could built >> lang/ghc and all ports depending on it with it. >> >> If it's ok to put it in before release, could someone else please >> commit it? My internet connection is currently almost completely >> broken. > Just noticed this bootstrap thingy by accident (grep is a good thing) > and fixed the MASTER_SITES0 to the new style. Thanks for doing the sweeps! > Could we NOT do things this way ? not sure if we have another > bootstrap Makefile for another language in the tree, > but I'd rather there be marked as > IGNORE = reason > and hooked up to the tree. Depending on how badly you want this, we can either fix it after the release or wait a bit longer. The reason for this bizarre scheme is inability of ghc-9.2 series to bootstrap itself via make flow. They deprecated this flow upstream and it will be going away soon. I intend to switch to their almost-ready flow with the 9.4 or 9.6 upgrade. This effort is predicated on my time availability and the Haskell ecosystem readiness to these ghc version. Maybe I'll spend some time on this in November, who knows? Thanks Greg
Re: new bootstrap for lang/ghc
On Tue, Sep 26, 2023 at 10:29:57PM +0200, Matthias Kilian wrote: > Hi, > > Greg asked me to provide a new ghc boostrap. Here it is; i could built > lang/ghc and all ports depending on it with it. > > If it's ok to put it in before release, could someone else please > commit it? My internet connection is currently almost completely > broken. > > Ciao, > Kili Just noticed this bootstrap thingy by accident (grep is a good thing) and fixed the MASTER_SITES0 to the new style. Could we NOT do things this way ? not sure if we have another bootstrap Makefile for another language in the tree, but I'd rather there be marked as IGNORE = reason and hooked up to the tree. Building is easy, just need to set NO_IGNORE on the command line.
new bootstrap for lang/ghc
Hi,
Greg asked me to provide a new ghc boostrap. Here it is; i could built
lang/ghc and all ports depending on it with it.
If it's ok to put it in before release, could someone else please
commit it? My internet connection is currently almost completely
broken.
Ciao,
Kili
Index: ghc-8.10.7/Makefile
===
RCS file: /cvs/ports/lang/ghc-8.10.7/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- ghc-8.10.7/Makefile 26 Sep 2023 11:58:12 - 1.4
+++ ghc-8.10.7/Makefile 26 Sep 2023 19:35:13 -
@@ -162,7 +162,7 @@ post-patch:
# It doesn't matter whether this is the actual date of the bootstrapper
# build. It's just used to get different distfiles whenever new
# bootstrappers have to be built.
-BOOTSTRAP_DATE = 20230613
+BOOTSTRAP_DATE = 20230925
# Create a bootstrapper. This compiles a stripped-down version of
# ghc and creates a `bindist', i.e. a tarball with binaries that
Index: ghc/Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.214
diff -u -p -r1.214 Makefile
--- ghc/Makefile25 Sep 2023 17:07:31 - 1.214
+++ ghc/Makefile26 Sep 2023 19:35:13 -
@@ -14,13 +14,13 @@ USE_NOEXECONLY =Yes
USE_NOBTCFI = Yes
GHC_VERSION = 9.2.7
-REVISION = 3
+REVISION = 4
DISTNAME = ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
# Version of the precompiled binaries
-BIN_VER = 8.10.7.20230613
+BIN_VER = 8.10.7.20230925
# lang/python needed for regression tests.
MODULES = lang/python
Index: ghc/distinfo
===
RCS file: /cvs/ports/lang/ghc/distinfo,v
retrieving revision 1.69
diff -u -p -r1.69 distinfo
--- ghc/distinfo11 Jul 2023 09:49:08 - 1.69
+++ ghc/distinfo26 Sep 2023 19:35:13 -
@@ -1,10 +1,10 @@
-SHA256 (ghc/ghc-8.10.7.20230613-amd64-unknown-openbsd.tar.xz) =
/QCac6kB92pFCO9fzn90h/bFJysRl8GUQjOHBVA/5SA=
-SHA256 (ghc/ghc-8.10.7.20230613-shlibs-amd64.tar.gz) =
LpQDN0fV+YASghLoGTjn0yzEeuYPNW9gtUasieUgu+g=
+SHA256 (ghc/ghc-8.10.7.20230925-amd64-unknown-openbsd.tar.xz) =
nX0+ANvjPFh0fBwvmd/iQ9ZDQE9w1o1IFuLD52aQYbE=
+SHA256 (ghc/ghc-8.10.7.20230925-shlibs-amd64.tar.gz) =
yffppwOB+SajgE2xN/AeFKvMHuWQanDUxDEqsJvh9DQ=
SHA256 (ghc/ghc-9.2.7-src.tar.xz) =
olNWehe3NKTA3Q/6KW0zwqW1pUp335iIBqKh4cp+iLg=
SHA256 (ghc/ghc-9.2.7-testsuite.tar.xz) =
JJSvF12xtiODaWBBo/N+s2VPyN9R8SifTygu6GsJ+1A=
SHA256 (ghc/ghc-rtd-update-70526f5bd8.diff) =
maCALPRglB5J9LJEQxBqMGdVbH4qK2gqVuaU5xmYdNU=
-SIZE (ghc/ghc-8.10.7.20230613-amd64-unknown-openbsd.tar.xz) = 48998912
-SIZE (ghc/ghc-8.10.7.20230613-shlibs-amd64.tar.gz) = 2941676
+SIZE (ghc/ghc-8.10.7.20230925-amd64-unknown-openbsd.tar.xz) = 48988780
+SIZE (ghc/ghc-8.10.7.20230925-shlibs-amd64.tar.gz) = 2951432
SIZE (ghc/ghc-9.2.7-src.tar.xz) = 24610432
SIZE (ghc/ghc-9.2.7-testsuite.tar.xz) = 3219572
SIZE (ghc/ghc-rtd-update-70526f5bd8.diff) = 4245853
Re: lang/* BTI breakage - lang/ghc
On Fri, Jun 30, 2023 at 09:15:55PM +0200, Matthias Kilian wrote:
> Hi,
>
> On Thu, Jun 29, 2023 at 10:55:34PM -0700, Greg Steuck wrote:
> > Christian Weisgerber writes:
> >
> > > Since BTI affects any and all compilers that generate executable code,
> > > I tried to build all lang/* ports on amd64 with BTI enabled. Here's the
> > > list of failures:
> > >
> > > devel/jdk/1.8 # needs new bootstrap
> > > lang/crystal
> > > lang/fpc
> > > lang/gcc/11
> > > lang/ghc
> >
> > Naturally, as kili@ suspected, we need a new bootstrap with the right
> > flags plumbed through. Unfortunately I don't have access to the hardware
> > with this feature.
>
> Same here. Could someone be so kind to try the diff below? It uses a
> bootstrap I built from lang/ghc-8.10.7 with similar changes.
>
> If it works, I'll commit both (lang/ghc and lang/ghc-8.10.7) and also
> look to integrate Gregs work getting rid of USE_NOEXECONLY.
I have build tested lang/ghc on IBT machine, and it was fine.
ok semarie@
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/ghc/Makefile,v
> retrieving revision 1.211
> diff -u -p -r1.211 Makefile
> --- Makefile 17 Mar 2023 10:40:44 - 1.211
> +++ Makefile 30 Jun 2023 19:05:02 -
> @@ -11,14 +11,16 @@ NO_CCACHE = Yes
> # Upstream bug: https://gitlab.haskell.org/ghc/ghc/-/issues/22782
> USE_NOEXECONLY = Yes
>
> +USE_NOBTCFI =Yes
> +
> GHC_VERSION =9.2.7
> -REVISION = 1
> +REVISION = 2
> DISTNAME = ghc-${GHC_VERSION}
> CATEGORIES = lang devel
> HOMEPAGE = https://www.haskell.org/ghc/
>
> # Version of the precompiled binaries
> -BIN_VER =8.10.7.20230316
> +BIN_VER =8.10.7.20230613
>
> # lang/python needed for regression tests.
> MODULES =lang/python
> @@ -114,7 +116,8 @@ CONFIGURE_ARGS += --with-ffi-includes=${
>
> CONFIGURE_ENV += SPHINXBUILD=${LOCALBASE}/bin/sphinx-build${MODPY_BIN_SUFFIX}
>
> -GHC_CC_OPTS =-Wl,--no-execute-only -Qunused-arguments
> +GHC_CC_OPTS =-Wl,--no-execute-only -Qunused-arguments \
> + -Wl,-z,nobtcfi
> CONFIGURE_ENV += CONF_GCC_LINKER_OPTS_STAGE0="${GHC_CC_OPTS}" \
> CONF_GCC_LINKER_OPTS_STAGE1="${GHC_CC_OPTS}" \
> CONF_GCC_LINKER_OPTS_STAGE2="${GHC_CC_OPTS}" \
> Index: distinfo
> ===
> RCS file: /cvs/ports/lang/ghc/distinfo,v
> retrieving revision 1.67
> diff -u -p -r1.67 distinfo
> --- distinfo 17 Mar 2023 10:40:44 - 1.67
> +++ distinfo 30 Jun 2023 19:05:02 -
> @@ -1,8 +1,8 @@
> -SHA256 (ghc/ghc-8.10.7.20230316-amd64-unknown-openbsd.tar.xz) =
> rj7ePY2zwgajLYmuRTyGi+TaJVFnE13TdaNpmPjEd1I=
> -SHA256 (ghc/ghc-8.10.7.20230316-shlibs-amd64.tar.gz) =
> 8QVqNJq6XGI+Xw9Hdf4uMDAeYY9V97U0DDJFPePDe2U=
> +SHA256 (ghc/ghc-8.10.7.20230613-amd64-unknown-openbsd.tar.xz) =
> /QCac6kB92pFCO9fzn90h/bFJysRl8GUQjOHBVA/5SA=
> +SHA256 (ghc/ghc-8.10.7.20230613-shlibs-amd64.tar.gz) =
> LpQDN0fV+YASghLoGTjn0yzEeuYPNW9gtUasieUgu+g=
> SHA256 (ghc/ghc-9.2.7-src.tar.xz) =
> olNWehe3NKTA3Q/6KW0zwqW1pUp335iIBqKh4cp+iLg=
> SHA256 (ghc/ghc-9.2.7-testsuite.tar.xz) =
> JJSvF12xtiODaWBBo/N+s2VPyN9R8SifTygu6GsJ+1A=
> -SIZE (ghc/ghc-8.10.7.20230316-amd64-unknown-openbsd.tar.xz) = 48940296
> -SIZE (ghc/ghc-8.10.7.20230316-shlibs-amd64.tar.gz) = 2923557
> +SIZE (ghc/ghc-8.10.7.20230613-amd64-unknown-openbsd.tar.xz) = 48998912
> +SIZE (ghc/ghc-8.10.7.20230613-shlibs-amd64.tar.gz) = 2941676
> SIZE (ghc/ghc-9.2.7-src.tar.xz) = 24610432
> SIZE (ghc/ghc-9.2.7-testsuite.tar.xz) = 3219572
>
--
Sebastien Marie
Re: lang/ghc and IBT?
Greg Steuck wrote: > Matthias Kilian writes: > > > still slacking around like hell, but I guess we need a new bootstrap > > for lang/ghc. If so, I'll try to enable USE_NOBTCFI, build a new > > bootstrap with it, and then use that for building the regular ghc > > package. > > Yeah, sounds about right. I have no illusions about GHC ever supporting > IBT considering their compilation model. Why not? Intel and ARM with IBT/BTI have confused the public. Branch Target generally means "function entry point". A compiler just needs to put IBT instructions at every calculated branch target, ie. the start of every function that is reached by "calculating" the address. Popping the address off the stack, with a RET, is not considered "calculating". If they end up putting the instructions at non-calculated branch targets, that's OK too. A compiler could generate code that has endbr64 as every 2nd instruction, and it would still work. It would be non-optimal, and silly. But it would work. My point is there is nothing wrong with a compiler that inperfectly places a few endbr64 that are not absolutely required. So I think GHC could do easily adapt to a IBT world.
Re: lang/ghc and IBT?
Matthias Kilian writes: > still slacking around like hell, but I guess we need a new bootstrap > for lang/ghc. If so, I'll try to enable USE_NOBTCFI, build a new > bootstrap with it, and then use that for building the regular ghc > package. Yeah, sounds about right. I have no illusions about GHC ever supporting IBT considering their compilation model. In related news, I managed to get GHC to use xonly[1]. It produces functional binaries without resorting to --no-execute-only now. It's a bit less pretty than I'd like, but we can polish it up. There are also more tests from ghc testsuite broken in this unloved --disable-tables-next-to-code mode. Maybe we should combine the two tasks and rebuild bootstrap only once? [1] https://github.com/blackgnezdo/ports/commit/f1efc1dca03094f37896c64c07aa0cd9ebfc6992 Thanks Greg
lang/ghc and IBT?
Hi, still slacking around like hell, but I guess we need a new bootstrap for lang/ghc. If so, I'll try to enable USE_NOBTCFI, build a new bootstrap with it, and then use that for building the regular ghc package. Ciao, Kili
lang/ghc: drop (broken) pledge(2) interface
Hi,
Remove the pledge(2) interface (broken since OpenBSD-6.3).
If anybody wants to use pledge(2) and unveil(2) from Haskell, this
should be done with a separate library on hackage.haskell.org.
Nothing in the ports tree is using it.
Ok?
Index: Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.209
diff -u -p -r1.209 Makefile
--- Makefile8 Mar 2023 02:30:08 - 1.209
+++ Makefile14 Mar 2023 06:53:07 -
@@ -12,6 +12,7 @@ NO_CCACHE = Yes
USE_NOEXECONLY = Yes
GHC_VERSION = 9.2.7
+REVISION = 0
DISTNAME = ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
@@ -137,9 +138,6 @@ TEST_DEPENDS = print/ghostscript/gnu ${M
post-extract:
cd ${WRKSRC} && ${AUTOCONF_ENV} ./boot
- cd ${WRKSRC}/libraries/unix && \
- mkdir -p System/OpenBSD && \
- install -m 644 ${FILESDIR}/Process.hsc System/OpenBSD
BOOTSTRAP_SHLIBS = ${WRKDIR}/ghc-${BIN_VER}-shlibs-${MACHINE_ARCH}
Index: files/Process.hsc
===
RCS file: files/Process.hsc
diff -N files/Process.hsc
--- files/Process.hsc 24 Mar 2016 20:32:25 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,31 +0,0 @@
-{-# LANGUAGE Safe #-}
-
-module System.OpenBSD.Process ( pledge ) where
-
-import Foreign
-import Foreign.C
-import System.Posix.Internals ( withFilePath )
-
--- | This function provides an interface to the OpenBSD
--- <http://man.openbsd.org/OpenBSD-current/man2/pledge.2 pledge(2)>
--- system call.
---
--- Passing 'Nothing' to the promises or paths arguments has the same
--- effect as passing NULL to the corresponding arguments of the system
--- call (i.e. not changing the current value).
-pledge :: Maybe String -> Maybe [FilePath] -> IO ()
-
-pledge promises paths =
- maybeWith withCString promises $ \cproms ->
- maybeWith withPaths2Array0 paths $ \paths_arr ->
- throwErrnoIfMinus1_ "pledge" (c_pledge cproms paths_arr)
-
-withPaths2Array0 :: [FilePath] -> (Ptr (Ptr CChar) -> IO a) -> IO a
-
-withPaths2Array0 paths f =
- withMany withFilePath paths $ \cstrs ->
- withArray0 nullPtr cstrs $ \paths_arr ->
- f paths_arr
-
-foreign import ccall unsafe "unistd.h pledge"
- c_pledge :: CString -> Ptr CString -> IO CInt
Index: patches/patch-libraries_unix_unix_cabal
===
RCS file: patches/patch-libraries_unix_unix_cabal
diff -N patches/patch-libraries_unix_unix_cabal
--- patches/patch-libraries_unix_unix_cabal 11 Mar 2022 19:29:00 -
1.5
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,11 +0,0 @@
libraries/unix/unix.cabal.orig Thu Feb 4 17:16:38 2016
-+++ libraries/unix/unix.cabal Wed Nov 2 11:07:58 2016
-@@ -112,6 +112,8 @@ library
- System.Posix.Terminal
- System.Posix.Terminal.ByteString
-
-+System.OpenBSD.Process
-+
- other-modules:
- System.Posix.Directory.Common
- System.Posix.DynamicLinker.Common
Index: pkg/PLIST
=======
RCS file: /cvs/ports/lang/ghc/pkg/PLIST,v
retrieving revision 1.30
diff -u -p -r1.30 PLIST
--- pkg/PLIST 8 Mar 2023 02:30:08 - 1.30
+++ pkg/PLIST 14 Mar 2023 06:53:07 -
@@ -5228,10 +5228,6 @@ lib/ghc/unix-${UNIX_VER}/
lib/ghc/unix-${UNIX_VER}/HSunix-${UNIX_VER}.o
lib/ghc/unix-${UNIX_VER}/HSunix-${UNIX_VER}.p_o
lib/ghc/unix-${UNIX_VER}/System/
-lib/ghc/unix-${UNIX_VER}/System/OpenBSD/
-lib/ghc/unix-${UNIX_VER}/System/OpenBSD/Process.dyn_hi
-lib/ghc/unix-${UNIX_VER}/System/OpenBSD/Process.hi
-lib/ghc/unix-${UNIX_VER}/System/OpenBSD/Process.p_hi
lib/ghc/unix-${UNIX_VER}/System/Posix/
lib/ghc/unix-${UNIX_VER}/System/Posix.dyn_hi
lib/ghc/unix-${UNIX_VER}/System/Posix.hi
@@ -7756,7 +7752,6 @@ share/doc/ghc/html/libraries/transformer
share/doc/ghc/html/libraries/transformers-${TRANSFORMERS_VER}/transformers.txt
share/doc/ghc/html/libraries/unix-${UNIX_VER}/
share/doc/ghc/html/libraries/unix-${UNIX_VER}/LICENSE
-share/doc/ghc/html/libraries/unix-${UNIX_VER}/System-OpenBSD-Process.html
share/doc/ghc/html/libraries/unix-${UNIX_VER}/System-Posix-ByteString-FilePath.html
share/doc/ghc/html/libraries/unix-${UNIX_VER}/System-Posix-ByteString.html
share/doc/ghc/html/libraries/unix-${UNIX_VER}/System-Posix-Directory-ByteString.html
Re: lang/ghc: new bootstrap
Hi, On Wed, Feb 22, 2023 at 08:28:58PM -0800, Greg Steuck wrote: > > Use a new bootstrap (still 8.10.7, but built on current from > > 2023-02-18). Attached is some kind of "port" I fiddled together > > from what's in CVS and some newer stuff, only used for "make > > bootstrap". > > Nice! I belive we should keep a variation of this in the tree and > rebuild bootstrap periodically. There's a bit of intentional duplication > and some detritus we could clean up, but we can do it in the tree just > fine. > > Some suggestion before committing this would be to stub it somehow such > that nobody mistakes this for a real package directory. Maybe remove > PLIST/PFRAG* and report an error from do-build: target? Done, except for the do-build: thing (because do-build: is still required for bootstrap:). > Also update the COMMENT to something like: > bootstrap generator for lang/ghc while it can't be self-hosted That's a little bit long for COMMENT, so I shortened it a little ;-) Ok to import this (as lang/ghc-8.10.7)? (I also checked that the bootstrap can be built with itself, using the one that I built and uploaded two weeks ago) Ciao, Kili ghc-8.10.7.tgz Description: application/tar-gz
Re: lang/ghc: new bootstrap
Matthias Kilian writes:
> Use a new bootstrap (still 8.10.7, but built on current from
> 2023-02-18). Attached is some kind of "port" I fiddled together
> from what's in CVS and some newer stuff, only used for "make
> bootstrap".
Nice! I belive we should keep a variation of this in the tree and
rebuild bootstrap periodically. There's a bit of intentional duplication
and some detritus we could clean up, but we can do it in the tree just
fine.
Some suggestion before committing this would be to stub it somehow such
that nobody mistakes this for a real package directory. Maybe remove
PLIST/PFRAG* and report an error from do-build: target? Also update the
COMMENT to something like:
bootstrap generator for lang/ghc while it can't be self-hosted
Thanks
Greg
>
> ghc-9.2.6 builds fine with this for me.
>
> Ciao,
> Kili
>
> Index: Makefile
> =======
> RCS file: /cvs/ports/lang/ghc/Makefile,v
> retrieving revision 1.208
> diff -u -p -r1.208 Makefile
> --- Makefile 21 Feb 2023 23:06:55 - 1.208
> +++ Makefile 22 Feb 2023 22:50:42 -
> @@ -12,13 +12,13 @@ NO_CCACHE = Yes
> USE_NOEXECONLY = Yes
>
> GHC_VERSION =9.2.6
> -REVISION = 1
> +REVISION = 2
> DISTNAME = ghc-${GHC_VERSION}
> CATEGORIES = lang devel
> HOMEPAGE = https://www.haskell.org/ghc/
>
> # Version of the precompiled binaries
> -BIN_VER =8.10.7.20220904
> +BIN_VER =8.10.7.20230222
>
> # lang/python needed for regression tests.
> MODULES =lang/python
> Index: distinfo
> ===
> RCS file: /cvs/ports/lang/ghc/distinfo,v
> retrieving revision 1.65
> diff -u -p -r1.65 distinfo
> --- distinfo 20 Feb 2023 00:02:34 - 1.65
> +++ distinfo 22 Feb 2023 22:50:42 -
> @@ -1,8 +1,8 @@
> -SHA256 (ghc/ghc-8.10.7.20220904-amd64-unknown-openbsd.tar.xz) =
> bH1nISV38j0ogaqDQuRycw55YaE031EEe6XR4vyw+1Q=
> -SHA256 (ghc/ghc-8.10.7.20220904-shlibs-amd64.tar.gz) =
> icwBqEzjeDiW42tw/9kTHC7/Hso9+fjjZaBJ5DF9chY=
> +SHA256 (ghc/ghc-8.10.7.20230222-amd64-unknown-openbsd.tar.xz) =
> JJ/ulkxy4Kl7a6PTTNZndE2e41EdQlyJe9POBrPnGL0=
> +SHA256 (ghc/ghc-8.10.7.20230222-shlibs-amd64.tar.gz) =
> hMSc09Rklbwvj0lUwRp0qPXW90cwwnBW4kqfVn6oqEY=
> SHA256 (ghc/ghc-9.2.6-src.tar.xz) =
> elTPA5itSItO0hnhXR0eZMC2h2xDoFZFUN0R8FQNcwU=
> SHA256 (ghc/ghc-9.2.6-testsuite.tar.xz) =
> YQsidzuDfndyrjAfoGZfpiCt+9KEF4AhjmZvclrWNjk=
> -SIZE (ghc/ghc-8.10.7.20220904-amd64-unknown-openbsd.tar.xz) = 35756988
> -SIZE (ghc/ghc-8.10.7.20220904-shlibs-amd64.tar.gz) = 3686128
> +SIZE (ghc/ghc-8.10.7.20230222-amd64-unknown-openbsd.tar.xz) = 48924640
> +SIZE (ghc/ghc-8.10.7.20230222-shlibs-amd64.tar.gz) = 2929544
> SIZE (ghc/ghc-9.2.6-src.tar.xz) = 24638236
> SIZE (ghc/ghc-9.2.6-testsuite.tar.xz) = 3202896
lang/ghc: new bootstrap
Hi,
Use a new bootstrap (still 8.10.7, but built on current from
2023-02-18). Attached is some kind of "port" I fiddled together
from what's in CVS and some newer stuff, only used for "make
bootstrap".
ghc-9.2.6 builds fine with this for me.
Ciao,
Kili
Index: Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.208
diff -u -p -r1.208 Makefile
--- Makefile21 Feb 2023 23:06:55 - 1.208
+++ Makefile22 Feb 2023 22:50:42 -
@@ -12,13 +12,13 @@ NO_CCACHE = Yes
USE_NOEXECONLY = Yes
GHC_VERSION = 9.2.6
-REVISION = 1
+REVISION = 2
DISTNAME = ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
# Version of the precompiled binaries
-BIN_VER = 8.10.7.20220904
+BIN_VER = 8.10.7.20230222
# lang/python needed for regression tests.
MODULES = lang/python
Index: distinfo
===
RCS file: /cvs/ports/lang/ghc/distinfo,v
retrieving revision 1.65
diff -u -p -r1.65 distinfo
--- distinfo20 Feb 2023 00:02:34 - 1.65
+++ distinfo22 Feb 2023 22:50:42 -
@@ -1,8 +1,8 @@
-SHA256 (ghc/ghc-8.10.7.20220904-amd64-unknown-openbsd.tar.xz) =
bH1nISV38j0ogaqDQuRycw55YaE031EEe6XR4vyw+1Q=
-SHA256 (ghc/ghc-8.10.7.20220904-shlibs-amd64.tar.gz) =
icwBqEzjeDiW42tw/9kTHC7/Hso9+fjjZaBJ5DF9chY=
+SHA256 (ghc/ghc-8.10.7.20230222-amd64-unknown-openbsd.tar.xz) =
JJ/ulkxy4Kl7a6PTTNZndE2e41EdQlyJe9POBrPnGL0=
+SHA256 (ghc/ghc-8.10.7.20230222-shlibs-amd64.tar.gz) =
hMSc09Rklbwvj0lUwRp0qPXW90cwwnBW4kqfVn6oqEY=
SHA256 (ghc/ghc-9.2.6-src.tar.xz) =
elTPA5itSItO0hnhXR0eZMC2h2xDoFZFUN0R8FQNcwU=
SHA256 (ghc/ghc-9.2.6-testsuite.tar.xz) =
YQsidzuDfndyrjAfoGZfpiCt+9KEF4AhjmZvclrWNjk=
-SIZE (ghc/ghc-8.10.7.20220904-amd64-unknown-openbsd.tar.xz) = 35756988
-SIZE (ghc/ghc-8.10.7.20220904-shlibs-amd64.tar.gz) = 3686128
+SIZE (ghc/ghc-8.10.7.20230222-amd64-unknown-openbsd.tar.xz) = 48924640
+SIZE (ghc/ghc-8.10.7.20230222-shlibs-amd64.tar.gz) = 2929544
SIZE (ghc/ghc-9.2.6-src.tar.xz) = 24638236
SIZE (ghc/ghc-9.2.6-testsuite.tar.xz) = 3202896
ghc-8.10.7.tgz
Description: application/tar-gz
Re: Upgrade lang/ghc 9.2.5->9.2.6
Hi, On Sat, Feb 11, 2023 at 07:43:44PM -0800, Greg Steuck wrote: > I rebuilt all our ports with this. Looks like a safe and useful upgrade, > OK? Yes. Ciao, Kili
Re: Upgrade lang/ghc 9.2.5->9.2.6
Works fine for me and rebuilds all my haskell stuff on amd64.
On 2/12/23 04:43, Greg Steuck wrote:
I rebuilt all our ports with this. Looks like a safe and useful upgrade,
OK?
https://www.haskell.org/ghc/blog/20230210-ghc-9.2.6-released.html
From bb3d3aef3c36d2ebb05d9bc546e80907e51e2af5 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 11 Feb 2023 18:44:41 -0800
Subject: [PATCH] Upgrade lang/ghc 9.2.5->9.2.6
---
lang/ghc/Makefile | 7 +++
lang/ghc/distinfo | 8
lang/ghc/pkg/PLIST | 6 ++
3 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
index 99cb2e85ca8..27c1ed025e9 100644
--- a/lang/ghc/Makefile
+++ b/lang/ghc/Makefile
@@ -11,8 +11,7 @@ NO_CCACHE = Yes
# Upstream bug: https://gitlab.haskell.org/ghc/ghc/-/issues/22782
USE_NOEXECONLY = Yes
-GHC_VERSION = 9.2.5
-REVISION = 0
+GHC_VERSION = 9.2.6
DISTNAME =ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE =https://www.haskell.org/ghc/
@@ -66,13 +65,13 @@ GHC_ITEMS = \
ARRAY 0.5.4.0 \
BASE4.16.4.0 \
BINARY 0.8.9.0 \
- BYTESTRING 0.11.3.1 \
+ BYTESTRING 0.11.4.0 \
CONTAINERS 0.6.5.1 \
DEEPSEQ 1.4.6.1 \
DIRECTORY 1.3.6.2 \
EXCEPTIONS 0.10.4 \
FILEPATH1.4.2.2 \
- GHC 9.2.5\
+ GHC 9.2.6\
GHC_BIGNUM 1.2 \
GHC_COMPACT 0.1.0.0 \
GHC_PRIM0.8.0\
diff --git a/lang/ghc/distinfo b/lang/ghc/distinfo
index 7d71490ba1c..e1dcc529840 100644
--- a/lang/ghc/distinfo
+++ b/lang/ghc/distinfo
@@ -1,8 +1,8 @@
SHA256 (ghc/ghc-8.10.7.20220904-amd64-unknown-openbsd.tar.xz) =
bH1nISV38j0ogaqDQuRycw55YaE031EEe6XR4vyw+1Q=
SHA256 (ghc/ghc-8.10.7.20220904-shlibs-amd64.tar.gz) =
icwBqEzjeDiW42tw/9kTHC7/Hso9+fjjZaBJ5DF9chY=
-SHA256 (ghc/ghc-9.2.5-src.tar.xz) =
BgZ5fRs44tiO4iQ/OOxrmhqpPptXjpXw3pqcCkFEAhw=
-SHA256 (ghc/ghc-9.2.5-testsuite.tar.xz) =
dIR05uCVKX/BPR5XIwKi8xdanwZZ1D2K50rG3CIECqY=
+SHA256 (ghc/ghc-9.2.6-src.tar.xz) =
elTPA5itSItO0hnhXR0eZMC2h2xDoFZFUN0R8FQNcwU=
+SHA256 (ghc/ghc-9.2.6-testsuite.tar.xz) =
YQsidzuDfndyrjAfoGZfpiCt+9KEF4AhjmZvclrWNjk=
SIZE (ghc/ghc-8.10.7.20220904-amd64-unknown-openbsd.tar.xz) = 35756988
SIZE (ghc/ghc-8.10.7.20220904-shlibs-amd64.tar.gz) = 3686128
-SIZE (ghc/ghc-9.2.5-src.tar.xz) = 24655072
-SIZE (ghc/ghc-9.2.5-testsuite.tar.xz) = 3198932
+SIZE (ghc/ghc-9.2.6-src.tar.xz) = 24638236
+SIZE (ghc/ghc-9.2.6-testsuite.tar.xz) = 3202896
diff --git a/lang/ghc/pkg/PLIST b/lang/ghc/pkg/PLIST
index 5d6cb87b8f0..80b8821223b 100644
--- a/lang/ghc/pkg/PLIST
+++ b/lang/ghc/pkg/PLIST
@@ -1826,9 +1826,13 @@
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Builder/RealFloat/TableGene
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Char8.dyn_hi
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Char8.hi
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Char8.p_hi
+lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Internal/
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Internal.dyn_hi
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Internal.hi
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Internal.p_hi
+lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Internal/Type.dyn_hi
+lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Internal/Type.hi
+lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Internal/Type.p_hi
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Lazy/
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Lazy.dyn_hi
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Lazy.hi
@@ -7877,6 +7881,7 @@ share/doc/ghc/html/users_guide/9.2.1-notes.html
share/doc/ghc/html/users_guide/9.2.2-notes.html
share/doc/ghc/html/users_guide/9.2.3-notes.html
share/doc/ghc/html/users_guide/9.2.4-notes.html
+share/doc/ghc/html/users_guide/9.2.5-notes.html
share/doc/ghc/html/users_guide/${GHC_VER}-notes.html
share/doc/ghc/html/users_guide/_images/
share/doc/ghc/html/users_guide/_images/prof_scc.svg
@@ -7885,6 +7890,7 @@
share/doc/ghc/html/users_guide/_sources/9.2.1-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/9.2.2-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/9.2.3-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/9.2.4-notes.rst.txt
+share/doc/ghc/html/users_guide/_sources/9.2.5-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/${GHC_VER}-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/bugs.rst.txt
share/doc/ghc/html/users_guide/_sources/codegens.rst.txt
Upgrade lang/ghc 9.2.5->9.2.6
I rebuilt all our ports with this. Looks like a safe and useful upgrade,
OK?
https://www.haskell.org/ghc/blog/20230210-ghc-9.2.6-released.html
>From bb3d3aef3c36d2ebb05d9bc546e80907e51e2af5 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 11 Feb 2023 18:44:41 -0800
Subject: [PATCH] Upgrade lang/ghc 9.2.5->9.2.6
---
lang/ghc/Makefile | 7 +++
lang/ghc/distinfo | 8
lang/ghc/pkg/PLIST | 6 ++
3 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
index 99cb2e85ca8..27c1ed025e9 100644
--- a/lang/ghc/Makefile
+++ b/lang/ghc/Makefile
@@ -11,8 +11,7 @@ NO_CCACHE = Yes
# Upstream bug: https://gitlab.haskell.org/ghc/ghc/-/issues/22782
USE_NOEXECONLY = Yes
-GHC_VERSION = 9.2.5
-REVISION = 0
+GHC_VERSION = 9.2.6
DISTNAME = ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
@@ -66,13 +65,13 @@ GHC_ITEMS = \
ARRAY 0.5.4.0 \
BASE4.16.4.0 \
BINARY 0.8.9.0 \
- BYTESTRING 0.11.3.1 \
+ BYTESTRING 0.11.4.0 \
CONTAINERS 0.6.5.1 \
DEEPSEQ 1.4.6.1 \
DIRECTORY 1.3.6.2 \
EXCEPTIONS 0.10.4 \
FILEPATH1.4.2.2 \
- GHC 9.2.5\
+ GHC 9.2.6\
GHC_BIGNUM 1.2 \
GHC_COMPACT 0.1.0.0 \
GHC_PRIM0.8.0\
diff --git a/lang/ghc/distinfo b/lang/ghc/distinfo
index 7d71490ba1c..e1dcc529840 100644
--- a/lang/ghc/distinfo
+++ b/lang/ghc/distinfo
@@ -1,8 +1,8 @@
SHA256 (ghc/ghc-8.10.7.20220904-amd64-unknown-openbsd.tar.xz) =
bH1nISV38j0ogaqDQuRycw55YaE031EEe6XR4vyw+1Q=
SHA256 (ghc/ghc-8.10.7.20220904-shlibs-amd64.tar.gz) =
icwBqEzjeDiW42tw/9kTHC7/Hso9+fjjZaBJ5DF9chY=
-SHA256 (ghc/ghc-9.2.5-src.tar.xz) =
BgZ5fRs44tiO4iQ/OOxrmhqpPptXjpXw3pqcCkFEAhw=
-SHA256 (ghc/ghc-9.2.5-testsuite.tar.xz) =
dIR05uCVKX/BPR5XIwKi8xdanwZZ1D2K50rG3CIECqY=
+SHA256 (ghc/ghc-9.2.6-src.tar.xz) =
elTPA5itSItO0hnhXR0eZMC2h2xDoFZFUN0R8FQNcwU=
+SHA256 (ghc/ghc-9.2.6-testsuite.tar.xz) =
YQsidzuDfndyrjAfoGZfpiCt+9KEF4AhjmZvclrWNjk=
SIZE (ghc/ghc-8.10.7.20220904-amd64-unknown-openbsd.tar.xz) = 35756988
SIZE (ghc/ghc-8.10.7.20220904-shlibs-amd64.tar.gz) = 3686128
-SIZE (ghc/ghc-9.2.5-src.tar.xz) = 24655072
-SIZE (ghc/ghc-9.2.5-testsuite.tar.xz) = 3198932
+SIZE (ghc/ghc-9.2.6-src.tar.xz) = 24638236
+SIZE (ghc/ghc-9.2.6-testsuite.tar.xz) = 3202896
diff --git a/lang/ghc/pkg/PLIST b/lang/ghc/pkg/PLIST
index 5d6cb87b8f0..80b8821223b 100644
--- a/lang/ghc/pkg/PLIST
+++ b/lang/ghc/pkg/PLIST
@@ -1826,9 +1826,13 @@
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Builder/RealFloat/TableGene
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Char8.dyn_hi
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Char8.hi
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Char8.p_hi
+lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Internal/
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Internal.dyn_hi
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Internal.hi
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Internal.p_hi
+lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Internal/Type.dyn_hi
+lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Internal/Type.hi
+lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Internal/Type.p_hi
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Lazy/
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Lazy.dyn_hi
lib/ghc/bytestring-${BYTESTRING_VER}/Data/ByteString/Lazy.hi
@@ -7877,6 +7881,7 @@ share/doc/ghc/html/users_guide/9.2.1-notes.html
share/doc/ghc/html/users_guide/9.2.2-notes.html
share/doc/ghc/html/users_guide/9.2.3-notes.html
share/doc/ghc/html/users_guide/9.2.4-notes.html
+share/doc/ghc/html/users_guide/9.2.5-notes.html
share/doc/ghc/html/users_guide/${GHC_VER}-notes.html
share/doc/ghc/html/users_guide/_images/
share/doc/ghc/html/users_guide/_images/prof_scc.svg
@@ -7885,6 +7890,7 @@
share/doc/ghc/html/users_guide/_sources/9.2.1-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/9.2.2-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/9.2.3-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/9.2.4-notes.rst.txt
+share/doc/ghc/html/users_guide/_sources/9.2.5-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/${GHC_VER}-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/bugs.rst.txt
share/doc/ghc/html/users_guide/_sources/codegens.rst.txt
--
2.39.1
Upgrade lang/ghc 9.2.4->9.2.5
Hi Matthias,
There's a set of useful fixes in this point release:
https://www.haskell.org/ghc/blog/20221107-ghc-9.2.5-released.html
I confirmed I can build everything directly dependant in the tree with
this new version. The noise about strcpy/sprintf is pretty loud, but
it's the same as with the existing version.
OK?
>From c476295ff8e1aef293595dd1b7551bc9a23fd515 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 26 Nov 2022 16:53:29 -0800
Subject: [PATCH] Upgrade lang/ghc 9.2.4->9.2.5
---
lang/ghc/Makefile | 9 -
lang/ghc/distinfo | 8
lang/ghc/pkg/PLIST | 6 ++
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
index c9e5d699451..3d80cc1c77f 100644
--- a/lang/ghc/Makefile
+++ b/lang/ghc/Makefile
@@ -8,8 +8,7 @@ DPB_PROPERTIES = parallel
# ghc hardcodes ${WRKDIR}/bin/gcc when the package is compiled with ccache
NO_CCACHE = Yes
-GHC_VERSION = 9.2.4
-REVISION = 3
+GHC_VERSION = 9.2.5
DISTNAME = ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
@@ -61,7 +60,7 @@ SUPDISTFILES += ${BINDISTFILE-$m}
GHC_ITEMS = \
CABAL 3.6.3.0 \
ARRAY 0.5.4.0 \
- BASE 4.16.3.0 \
+ BASE 4.16.4.0 \
BINARY 0.8.9.0 \
BYTESTRING 0.11.3.1 \
CONTAINERS 0.6.5.1 \
@@ -69,7 +68,7 @@ GHC_ITEMS = \
DIRECTORY 1.3.6.2 \
EXCEPTIONS 0.10.4 \
FILEPATH 1.4.2.2 \
- GHC 9.2.4 \
+ GHC 9.2.5 \
GHC_BIGNUM 1.2 \
GHC_COMPACT 0.1.0.0 \
GHC_PRIM 0.8.0 \
@@ -79,7 +78,7 @@ GHC_ITEMS = \
MTL 2.2.2 \
PARSEC 3.1.15.0 \
PRETTY 1.1.3.6 \
- PROCESS 1.6.13.2 \
+ PROCESS 1.6.16.0 \
STM 2.5.0.2 \
TEMPLATE-HASKELL 2.18.0.0 \
TERMINFO 0.4.1.5 \
diff --git a/lang/ghc/distinfo b/lang/ghc/distinfo
index 99248910645..7d71490ba1c 100644
--- a/lang/ghc/distinfo
+++ b/lang/ghc/distinfo
@@ -1,8 +1,8 @@
SHA256 (ghc/ghc-8.10.7.20220904-amd64-unknown-openbsd.tar.xz) = bH1nISV38j0ogaqDQuRycw55YaE031EEe6XR4vyw+1Q=
SHA256 (ghc/ghc-8.10.7.20220904-shlibs-amd64.tar.gz) = icwBqEzjeDiW42tw/9kTHC7/Hso9+fjjZaBJ5DF9chY=
-SHA256 (ghc/ghc-9.2.4-src.tar.xz) = FSE4iAZKDsTncj0HXzG4emeM4IUXc9WLRO96o96ZZFg=
-SHA256 (ghc/ghc-9.2.4-testsuite.tar.xz) = 1YaTrD0bx/Agxd/ZLBD2MRPcXW/YzHiTlKr7Qql+sC0=
+SHA256 (ghc/ghc-9.2.5-src.tar.xz) = BgZ5fRs44tiO4iQ/OOxrmhqpPptXjpXw3pqcCkFEAhw=
+SHA256 (ghc/ghc-9.2.5-testsuite.tar.xz) = dIR05uCVKX/BPR5XIwKi8xdanwZZ1D2K50rG3CIECqY=
SIZE (ghc/ghc-8.10.7.20220904-amd64-unknown-openbsd.tar.xz) = 35756988
SIZE (ghc/ghc-8.10.7.20220904-shlibs-amd64.tar.gz) = 3686128
-SIZE (ghc/ghc-9.2.4-src.tar.xz) = 24632968
-SIZE (ghc/ghc-9.2.4-testsuite.tar.xz) = 3193376
+SIZE (ghc/ghc-9.2.5-src.tar.xz) = 24655072
+SIZE (ghc/ghc-9.2.5-testsuite.tar.xz) = 3198932
diff --git a/lang/ghc/pkg/PLIST b/lang/ghc/pkg/PLIST
index 7a36656c1bf..5d6cb87b8f0 100644
--- a/lang/ghc/pkg/PLIST
+++ b/lang/ghc/pkg/PLIST
@@ -3341,6 +3341,9 @@ lib/ghc/ghc-${GHC_VER}/GHC/StgToCmm/Hpc.p_hi
lib/ghc/ghc-${GHC_VER}/GHC/StgToCmm/Layout.dyn_hi
lib/ghc/ghc-${GHC_VER}/GHC/StgToCmm/Layout.hi
lib/ghc/ghc-${GHC_VER}/GHC/StgToCmm/Layout.p_hi
+lib/ghc/ghc-${GHC_VER}/GHC/StgToCmm/Lit.dyn_hi
+lib/ghc/ghc-${GHC_VER}/GHC/StgToCmm/Lit.hi
+lib/ghc/ghc-${GHC_VER}/GHC/StgToCmm/Lit.p_hi
lib/ghc/ghc-${GHC_VER}/GHC/StgToCmm/Monad.dyn_hi
lib/ghc/ghc-${GHC_VER}/GHC/StgToCmm/Monad.hi
lib/ghc/ghc-${GHC_VER}/GHC/StgToCmm/Monad.p_hi
@@ -6731,6 +6734,7 @@ share/doc/ghc/html/libraries/ghc-${GHC_VER}/GHC-StgToCmm-Foreign.html
share/doc/ghc/html/libraries/ghc-${GHC_VER}/GHC-StgToCmm-Heap.html
share/doc/ghc/html/libraries/ghc-${GHC_VER}/GHC-StgToCmm-Hpc.html
share/doc/ghc/html/libraries/ghc-${GHC_VER}/GHC-StgToCmm-Layout.html
+share/doc/ghc/html/libraries/ghc-${GHC_VER}/GHC-StgToCmm-Lit.html
share/doc/ghc/html/libraries/ghc-${GHC_VER}/GHC-StgToCmm-Monad.html
share/doc/ghc/html/libraries/ghc-${GHC_VER}/GHC-StgToCmm-Prim.html
share/doc/ghc/html/libraries/ghc-${GHC_VER}/GHC-StgToCmm-Prof.html
@@ -7872,6 +7876,7 @@ share/doc/ghc/html/users_guide/.buildinfo
share/doc/ghc/html/users_guide/9.2.1-notes.html
share/doc/ghc/html/users_guide/9.2.2-notes.html
share/doc/ghc/html/users_guide/9.2.3-notes.html
+share/doc/ghc/html/users_guide/9.2.4-notes.html
share/doc/ghc/html/users_guide/${GHC_VER}-notes.html
share/doc/ghc/html/users_guide/_images/
share/doc/ghc/html/users_guide/_images/prof_scc.svg
@@ -7879,6 +7884,7 @@ share/doc/ghc/html/users_guide/_sources/
share/doc/ghc/html/users_guide/_sources/9.2.1-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/9.2.2-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/9.2.3-notes.rst.txt
+share/doc/ghc/html/users_guide/_sources/9.2.4-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/${GHC_VER}-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/bugs.rst.txt
share/doc/ghc/html/users_guide/_sources/codegens.rst.txt
--
2.38.1
Re: [PATCH] Upgrade lang/ghc 9.2.{3->4}
Hi, On Thu, Jul 28, 2022 at 09:44:40PM -0700, Greg Steuck wrote: > This was a quick and easy one. I rebuilt all the Haskell ports with the > new compiler. > > Release announcement: https://discourse.haskell.org/t/ghc-9-2-4-released/4851 > > The changes include some fixes for crashes in compiled programs, so I'm > motivated to land this before 7.2. I did notice the crashes myself, but > they were rare and I couldn't properly diagnose. ok. I've rebuilt all haskell ports with it and also tested xmonad. Ciao, Kili ps: new bootstrapper is still work in progress -- I got a bootstrapper but then the build of lang/ghc with it failed in strange ways (missing directories for some object files to be written); will have to compare build logs with old and new bootstrapper and to find the reason the new one fails.
[PATCH] Upgrade lang/ghc 9.2.{3->4}
Hi Matthias,
This was a quick and easy one. I rebuilt all the Haskell ports with the
new compiler.
Release announcement: https://discourse.haskell.org/t/ghc-9-2-4-released/4851
The changes include some fixes for crashes in compiled programs, so I'm
motivated to land this before 7.2. I did notice the crashes myself, but
they were rare and I couldn't properly diagnose.
Thanks
Greg
>From aef0924ef518ff3d4107957fb3a176cdee583154 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Thu, 28 Jul 2022 21:34:37 -0700
Subject: [PATCH] Upgrade lang/ghc 9.2.{3->4}
---
lang/ghc/Makefile | 7 +++
lang/ghc/distinfo | 8
lang/ghc/pkg/PLIST | 2 ++
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
index bdbb2e08e8f..b7359f61f3d 100644
--- a/lang/ghc/Makefile
+++ b/lang/ghc/Makefile
@@ -8,12 +8,11 @@ DPB_PROPERTIES = parallel
# ghc hardcodes ${WRKDIR}/bin/gcc when the package is compiled with ccache
NO_CCACHE =Yes
-GHC_VERSION = 9.2.3
+GHC_VERSION = 9.2.4
DISTNAME = ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
-REVISION = 0
# Version of the precompiled binaries
BIN_VER = 8.10.7.20220419
@@ -62,7 +61,7 @@ SUPDISTFILES += ${BINDISTFILE-$m}
GHC_ITEMS = \
CABAL 3.6.3.0 \
ARRAY 0.5.4.0 \
- BASE4.16.2.0 \
+ BASE4.16.3.0 \
BINARY 0.8.9.0 \
BYTESTRING 0.11.3.1 \
CONTAINERS 0.6.5.1 \
@@ -70,7 +69,7 @@ GHC_ITEMS = \
DIRECTORY 1.3.6.2 \
EXCEPTIONS 0.10.4 \
FILEPATH1.4.2.2 \
- GHC 9.2.3\
+ GHC 9.2.4\
GHC_BIGNUM 1.2 \
GHC_COMPACT 0.1.0.0 \
GHC_PRIM0.8.0\
diff --git a/lang/ghc/distinfo b/lang/ghc/distinfo
index 9f288c55e46..0fbfa192147 100644
--- a/lang/ghc/distinfo
+++ b/lang/ghc/distinfo
@@ -1,8 +1,8 @@
SHA256 (ghc/ghc-8.10.7.20220419-amd64-unknown-openbsd.tar.xz) =
JFa1/AJu2bhYiL80OrKWy0li7ynmO99eCnc9nA+DjSc=
SHA256 (ghc/ghc-8.10.7.20220419-shlibs-amd64.tar.gz) =
zjDaNaYT1AnlqEqupIxr8aoALbQao/a3dypGrDL9X7g=
-SHA256 (ghc/ghc-9.2.3-src.tar.xz) =
UOzcK+8BPlGPmmKhUkXX2w5ECdc3xDsc6nMG/YLhZp4=
-SHA256 (ghc/ghc-9.2.3-testsuite.tar.xz) =
RqbLsMMva02WXbZn7JpZ0v6vnjFgngzb5X5hrzN9PiA=
+SHA256 (ghc/ghc-9.2.4-src.tar.xz) =
FSE4iAZKDsTncj0HXzG4emeM4IUXc9WLRO96o96ZZFg=
+SHA256 (ghc/ghc-9.2.4-testsuite.tar.xz) =
1YaTrD0bx/Agxd/ZLBD2MRPcXW/YzHiTlKr7Qql+sC0=
SIZE (ghc/ghc-8.10.7.20220419-amd64-unknown-openbsd.tar.xz) = 35749140
SIZE (ghc/ghc-8.10.7.20220419-shlibs-amd64.tar.gz) = 2904669
-SIZE (ghc/ghc-9.2.3-src.tar.xz) = 27525456
-SIZE (ghc/ghc-9.2.3-testsuite.tar.xz) = 3193820
+SIZE (ghc/ghc-9.2.4-src.tar.xz) = 24632968
+SIZE (ghc/ghc-9.2.4-testsuite.tar.xz) = 3193376
diff --git a/lang/ghc/pkg/PLIST b/lang/ghc/pkg/PLIST
index 7bbfcf62e4a..84b6fe222d0 100644
--- a/lang/ghc/pkg/PLIST
+++ b/lang/ghc/pkg/PLIST
@@ -7870,12 +7870,14 @@ share/doc/ghc/html/users_guide/
share/doc/ghc/html/users_guide/.buildinfo
share/doc/ghc/html/users_guide/9.2.1-notes.html
share/doc/ghc/html/users_guide/9.2.2-notes.html
+share/doc/ghc/html/users_guide/9.2.3-notes.html
share/doc/ghc/html/users_guide/${GHC_VER}-notes.html
share/doc/ghc/html/users_guide/_images/
share/doc/ghc/html/users_guide/_images/prof_scc.svg
share/doc/ghc/html/users_guide/_sources/
share/doc/ghc/html/users_guide/_sources/9.2.1-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/9.2.2-notes.rst.txt
+share/doc/ghc/html/users_guide/_sources/9.2.3-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/${GHC_VER}-notes.rst.txt
share/doc/ghc/html/users_guide/_sources/bugs.rst.txt
share/doc/ghc/html/users_guide/_sources/codegens.rst.txt
--
2.37.1
Re: Upgrade lang/ghc 9.2.2->9.2.3
Hi, On Sun, May 29, 2022 at 11:39:53PM +0200, Matthias Kilian wrote: > On Sun, May 29, 2022 at 01:00:49PM -0700, Greg Steuck wrote: > > I had another patch in my tree before it, so I'm sending that too. Based > > on my always building with MAKE_JOBS=10 I suspect ghc build is now > > concurrency-friendly, so I removed the admonition. > > I think we could also set DPB_PROPERTIES = parallel. IIRC, the only > reason not to set it were some problems on i386. > > For the update itself, I'll test-build it with all dependencies. To build ghc, I also had to change CONFIGURE_STYLE, otherwise automake is missing as a build dependency: CONFIGURE_STYLE = gnu autoreconf Otherwise ok, both the update and the addition of DPB_PROPERTIES = parallel. Ciao, Kili
Re: Upgrade lang/ghc 9.2.2->9.2.3
Hi Greg, On Sun, May 29, 2022 at 01:00:49PM -0700, Greg Steuck wrote: > I had another patch in my tree before it, so I'm sending that too. Based > on my always building with MAKE_JOBS=10 I suspect ghc build is now > concurrency-friendly, so I removed the admonition. I think we could also set DPB_PROPERTIES = parallel. IIRC, the only reason not to set it were some problems on i386. For the update itself, I'll test-build it with all dependencies. Ciao, Kili
Upgrade lang/ghc 9.2.2->9.2.3
Hi Matthias,
Looks like we can cheaply get to ghc-9.2.3 now. The changelog lists a
few bug fixes:
https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html
I had another patch in my tree before it, so I'm sending that too. Based
on my always building with MAKE_JOBS=10 I suspect ghc build is now
concurrency-friendly, so I removed the admonition.
So far I only built ghc itself and tested it by rebuilding my xmonad.
I'll rebuild all the direct dependents, but might as well ask for an
OK in the meantime.
If you happen to have an urge to build a fresh bootstrap at some point,
we should look into aligning the automake versions between bootstrap and
port builds.
Thanks
Greg
>From dee8ca038ee8f42c9949503da289ce8614f4091e Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 22 May 2022 23:06:36 -0700
Subject: [PATCH 1/2] Remove USE_WXNEEDED from lang/ghc as it's no longer
needed
Verified by rebuilding on a filesystem without wxneeded and running
ghci from /usr/local with wxneeded turned off.
---
lang/ghc/Makefile | 11 ---
1 file changed, 11 deletions(-)
diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
index 9fc34259e4b..d426adec67a 100644
--- a/lang/ghc/Makefile
+++ b/lang/ghc/Makefile
@@ -3,12 +3,6 @@ ONLY_FOR_ARCHS = amd64
COMMENT = compiler for the functional language Haskell
-# Note: please never ever set DPB_PROPERTIES=parallel (or some other
-# magic that enables parallel builds) for this port! Not even if it
-# appears to work. (search the upstream bug tracker for terms like
-# "non-deterministic", "unresolved symbol", "signature mismatch" etc. to
-# find the appropriate bug tickets)
-
# ghc hardcodes ${WRKDIR}/bin/gcc when the package is compiled with ccache
NO_CCACHE =Yes
@@ -42,11 +36,6 @@ BUILD_DEPENDS = archivers/bzip2 \
textproc/py-sphinx${MODPY_FLAVOR}>=4.0.2
RUN_DEPENDS =
-# GHC build uses -Wl,-z,wxneeded on OpenBSD.
-# XXX: wxneeded is a hack. Fix rts/Linker.c, mmapForLinker() and
-# loadObj_() instead.
-USE_WXNEEDED = special
-
MASTER_SITES = https://downloads.haskell.org/ghc/${GHC_VERSION}/
MASTER_SITES0 =https://openbsd.dead-parrot.de/distfiles/
--
2.36.1
>From 6c2431ee764519962a7ad5a712361923570e0f9f Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 29 May 2022 12:43:31 -0700
Subject: [PATCH 2/2] Upgrade lang/ghc 9.2.2->9.2.3
Mostly mechanical, except for having to run ./boot per
https://gitlab.haskell.org/ghc/ghc/-/issues/21626
Removed the %n patches merged into the release. The ./configure patch
is no longer needed and wouldn't apply due to #21626 above.
---
lang/ghc/Makefile | 10 +--
lang/ghc/distinfo | 8 +--
lang/ghc/patches/patch-configure | 12
.../ghc/patches/patch-includes_rts_Messages_h | 32 --
lang/ghc/patches/patch-rts_RtsMessages_c | 63 ---
lang/ghc/patches/patch-rts_Stats_c| 52 ---
lang/ghc/pkg/PLIST| 2 +
7 files changed, 12 insertions(+), 167 deletions(-)
delete mode 100644 lang/ghc/patches/patch-configure
delete mode 100644 lang/ghc/patches/patch-includes_rts_Messages_h
delete mode 100644 lang/ghc/patches/patch-rts_RtsMessages_c
delete mode 100644 lang/ghc/patches/patch-rts_Stats_c
diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
index d426adec67a..a9809beda2c 100644
--- a/lang/ghc/Makefile
+++ b/lang/ghc/Makefile
@@ -6,7 +6,7 @@ COMMENT = compiler for the functional language
Haskell
# ghc hardcodes ${WRKDIR}/bin/gcc when the package is compiled with ccache
NO_CCACHE =Yes
-GHC_VERSION = 9.2.2
+GHC_VERSION = 9.2.3
DISTNAME = ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
@@ -58,15 +58,15 @@ SUPDISTFILES += ${BINDISTFILE-$m}
GHC_ITEMS = \
CABAL 3.6.3.0 \
ARRAY 0.5.4.0 \
- BASE4.16.1.0 \
+ BASE4.16.2.0 \
BINARY 0.8.9.0 \
- BYTESTRING 0.11.3.0 \
+ BYTESTRING 0.11.3.1 \
CONTAINERS 0.6.5.1 \
DEEPSEQ 1.4.6.1 \
DIRECTORY 1.3.6.2 \
EXCEPTIONS 0.10.4 \
FILEPATH1.4.2.2 \
- GHC 9.2.2\
+ GHC 9.2.3\
GHC_BIGNUM 1.2 \
GHC_COMPACT 0.1.0.0 \
GHC_PRIM0.8.0\
@@ -95,6 +95,7 @@ USE_GMAKE = Yes
USE_GROFF =Yes
AUTOCONF_VERSI
Re: lang/ghc-9.2.2 losing i386 support
On 2022/04/21 22:56, Greg Steuck wrote: > kili@ and I are working towards the switch to ghc 9.2.2. Most things are > looking good and I pushed the most recent branch to > https://github.com/blackgnezdo/ports/commits/ghc-9.2 > > We have a couple of issues remaining to consider. > > 1) We can no longer produce a viable bootstrap package for i386. This > problem predates ghc-9.2.2. It has become a problem now because we need > to rebuild the bootstrap to get 9.2.2 building. That's because the new > version requires an extra library that previous ghc versions didn't > need. Our inclination is to drop i386 support from lang/ghc. We have > already been limited by i386 RAM and a couple of packages including > haddock for ghc already can't be built. Having gone through the ghc bootstrap process for i386 before I totally understand this! In terms of practical impact, the thing most likely to be missed is xmonad. Other packages are mostly things that can be run on another machine. Given that machines most likely to be running X on i386 are also going to lose video acceleration with the next major version update of Mesa, and considering the wide availabity of amd64-capable hw (including very low cost second-hand machines) this doesn't seem a bad time to wind down i386 support in GUI ports where the cost/benefit is low. So I am OK with doing this.
Re: lang/ghc-9.2.2 losing i386 support
Hi,
On Thu, Apr 21, 2022 at 10:56:39PM -0700, Greg Steuck wrote:
> 1) We can no longer produce a viable bootstrap package for i386. This
> problem predates ghc-9.2.2. It has become a problem now because we need
> to rebuild the bootstrap to get 9.2.2 building. That's because the new
> version requires an extra library that previous ghc versions didn't
> need. Our inclination is to drop i386 support from lang/ghc. We have
> already been limited by i386 RAM and a couple of packages including
> haddock for ghc already can't be built.
>
> If you feel strongly enough to debug on i386, the bootstrap is
> available in the port. The error is:
> + exec utils/ghc-cabal/dist-install/build/tmp/ghc-cabal copy
> libraries/ghc-prim dist-install strip /usr/ports/pobj/ghc-9.2.2/bootstrap
> /usr/ports/pobj/ghc-9.2.2/bootstrap/lib/ghc
> /usr/ports/pobj/ghc-9.2.2/bootstrap/share/doc/ghc/html/libraries v
> Segmentation fault (core dumped)
>
> To reproduce, just don't apply the removal patch from my chain and try
> to build lang/ghc. The recipe to build your own bootstrap is in the port
> Makefile.
Just in case someone's going to do this, you'll also need (at least part
of) the diff below. It adds the libHSrts_l.a to the bootstrap and also
saves a little bit time by stopping after the stage-1 compiler is built.
Index: Makefile
=======
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.191
diff -u -p -r1.191 Makefile
--- Makefile11 Mar 2022 19:29:00 - 1.191
+++ Makefile19 Apr 2022 19:15:45 -
@@ -222,7 +220,7 @@ _bootstrap_prepare:
echo GhcStage2HcOpts=-O -fasm >> ${WRKSRC}/mk/build.mk
echo SplitObjs=NO >> ${WRKSRC}/mk/build.mk
echo GhcLibWays=v >> ${WRKSRC}/mk/build.mk
- echo GhcRTSWays=thr >> ${WRKSRC}/mk/build.mk
+ echo GhcRTSWays=thr l >> ${WRKSRC}/mk/build.mk
echo GhcWithInterpreter=NO >> ${WRKSRC}/mk/build.mk
echo GhcThreaded=YES >> ${WRKSRC}/mk/build.mk
echo INTEGER_LIBRARY=integer-simple >> ${WRKSRC}/mk/build.mk
@@ -233,12 +231,14 @@ _bootstrap_prepare:
echo GhcWithSMP=NO >> ${WRKSRC}/mk/build.mk
echo LD_OPTS=-optl-static -optl-s >> ${WRKSRC}/mk/build.mk
echo DYNAMIC_GHC_PROGRAMS=No >> ${WRKSRC}/mk/build.mk
+ echo Stage1Only=YES >> ${WRKSRC}/mk/build.mk
+ echo stage=1 >> ${WRKSRC}/mk/build.mk
echo ${BOOTSTRAP_DATE} > ${WRKSRC}/VERSION_DATE
_bootstrap_finish:
mkdir -p
${WRKBUILD}/ghc-${GHC_VERSION}.${BOOTSTRAP_DATE}-shlibs-$$(arch -s)
- ldd ${WRKBUILD}/ghc/stage2/build/tmp/ghc-stage2 | \
+ ldd ${WRKBUILD}/ghc/stage1/build/tmp/ghc-stage1 | \
awk '$$NF ~ /^\/usr\/(local\/)?lib\// { print $$NF }' | \
xargs -J % cp -p %
${WRKBUILD}/ghc-${GHC_VERSION}.${BOOTSTRAP_DATE}-shlibs-$$(arch -s)
cd ${WRKBUILD} && \
Ciao,
Kili
lang/ghc-9.2.2 losing i386 support
kili@ and I are working towards the switch to ghc 9.2.2. Most things are looking good and I pushed the most recent branch to https://github.com/blackgnezdo/ports/commits/ghc-9.2 We have a couple of issues remaining to consider. 1) We can no longer produce a viable bootstrap package for i386. This problem predates ghc-9.2.2. It has become a problem now because we need to rebuild the bootstrap to get 9.2.2 building. That's because the new version requires an extra library that previous ghc versions didn't need. Our inclination is to drop i386 support from lang/ghc. We have already been limited by i386 RAM and a couple of packages including haddock for ghc already can't be built. If you feel strongly enough to debug on i386, the bootstrap is available in the port. The error is: + exec utils/ghc-cabal/dist-install/build/tmp/ghc-cabal copy libraries/ghc-prim dist-install strip /usr/ports/pobj/ghc-9.2.2/bootstrap /usr/ports/pobj/ghc-9.2.2/bootstrap/lib/ghc /usr/ports/pobj/ghc-9.2.2/bootstrap/share/doc/ghc/html/libraries v Segmentation fault (core dumped) To reproduce, just don't apply the removal patch from my chain and try to build lang/ghc. The recipe to build your own bootstrap is in the port Makefile. 2) git-annex is not ready for ghc-9.2.2. I can probably power through this but it's not done yet. Other than that, I feel the branch is almost ready. More tests are always welcome. Thanks Greg
Re: lang/ghc
Matthias Kilian writes:
> New diff, where I only changed the debug stuff (and introduced a
> new typedef for it).
Your change is OK by me.
> The reason I didn't touch the other message
> printing functions is that they call printf(3)-like functions several
> times and don't do any error checking at all, and it's not clear
> what to do with those functions.
One step at a time sounds good to me.
> Fortunately, changing vdebugBelch() / debugMsgFn, rtsDebugMsgFn()
> are enough to kill the %n, and rtsDebugMsgFn() calls vfprintf(3) only
> once, so it's easy to let rtsDebugMsgFn() return the result of
> vfprintf(3).
>
> If upstream is interested, the next thing would be to remove those
> (unnecessary) indirections via function pointers.
Sure, might as well discuss this with them while landing your patch.
Thanks
Greg
>
> Ciao,
> Kili
>
> Index: Makefile
> =======
> RCS file: /cvs/ports/lang/ghc/Makefile,v
> retrieving revision 1.188
> diff -u -p -r1.188 Makefile
> --- Makefile 16 Aug 2021 21:23:18 - 1.188
> +++ Makefile 12 Sep 2021 19:40:01 -
> @@ -19,6 +19,8 @@ DISTNAME = ghc-${GHC_VERSION}
> CATEGORIES = lang devel
> HOMEPAGE = https://www.haskell.org/ghc/
>
> +REVISION = 0
> +
> # Version of the precompiled binaries
> BIN_VER =8.10.3.20210429
>
> Index: patches/patch-includes_rts_Messages_h
> ===
> RCS file: patches/patch-includes_rts_Messages_h
> diff -N patches/patch-includes_rts_Messages_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-includes_rts_Messages_h 12 Sep 2021 19:40:01 -
> @@ -0,0 +1,34 @@
> +$OpenBSD$
> +
> +The debug message function has to return the number of bytes written
> +(like printf(3)), to allow killing a %n format specifier in one in
> +one invocation of statsPrintf() in report_summary() (rts/Stats.c).
> +
> +Index: includes/rts/Messages.h
> +--- includes/rts/Messages.h.orig
> includes/rts/Messages.h
> +@@ -85,20 +85,21 @@ void vsysErrorBelch(const char *s, va_list ap);
> + void debugBelch(const char *s, ...)
> +GNUC3_ATTRIBUTE(format (PRINTF, 1, 2));
> +
> +-void vdebugBelch(const char *s, va_list ap);
> ++int vdebugBelch(const char *s, va_list ap);
> +
> +
> + /* Hooks for redirecting message generation: */
> +
> + typedef void RtsMsgFunction(const char *, va_list);
> ++typedef int RtsMsgFunctionRetLen(const char *, va_list);
> +
> + extern RtsMsgFunction *fatalInternalErrorFn;
> +-extern RtsMsgFunction *debugMsgFn;
> ++extern RtsMsgFunctionRetLen *debugMsgFn;
> + extern RtsMsgFunction *errorMsgFn;
> +
> + /* Default stdio implementation of the message hooks: */
> +
> + extern RtsMsgFunction rtsFatalInternalErrorFn;
> +-extern RtsMsgFunction rtsDebugMsgFn;
> ++extern RtsMsgFunctionRetLen rtsDebugMsgFn;
> + extern RtsMsgFunction rtsErrorMsgFn;
> + extern RtsMsgFunction rtsSysErrorMsgFn;
> Index: patches/patch-rts_RtsMessages_c
> ===
> RCS file: patches/patch-rts_RtsMessages_c
> diff -N patches/patch-rts_RtsMessages_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-rts_RtsMessages_c 12 Sep 2021 19:40:01 -
> @@ -0,0 +1,65 @@
> +$OpenBSD$
> +
> +The debug message function has to return the number of bytes written
> +(like printf(3)), to allow killing a %n format specifier in one in
> +one invocation of statsPrintf() in report_summary() (rts/Stats.c).
> +
> +Index: rts/RtsMessages.c
> +--- rts/RtsMessages.c.orig
> rts/RtsMessages.c
> +@@ -36,7 +36,7 @@
> +
> + // Default to the stdio implementation of these hooks.
> + RtsMsgFunction *fatalInternalErrorFn = rtsFatalInternalErrorFn;
> +-RtsMsgFunction *debugMsgFn = rtsDebugMsgFn;
> ++RtsMsgFunctionRetLen *debugMsgFn = rtsDebugMsgFn;
> + RtsMsgFunction *errorMsgFn = rtsErrorMsgFn;
> + RtsMsgFunction *sysErrorMsgFn= rtsSysErrorMsgFn;
> +
> +@@ -102,10 +102,10 @@ debugBelch(const char*s, ...)
> + va_end(ap);
> + }
> +
> +-void
> ++int
> + vdebugBelch(const char*s, va_list ap)
> + {
> +- (*debugMsgFn)(s,ap);
> ++ return (*debugMsgFn)(s,ap);
> + }
> +
> + /*
> -
> +@@ -285,16 +285,16 @@ rtsSysErrorMsgFn(const char *s, va_list ap)
> + #endif
> + }
> +
> +-void
> ++int
> + rtsDebugMsgFn(const char *s, va_list ap)
> + {
> ++ int r;
> + #if defined(mingw32_HOST_OS)
> + /* Ensure we're in text mode so newlines get encoded pr
Re: lang/ghc
On Mon, Sep 13, 2021 at 09:49:03AM +0200, Matthias Kilian wrote: > New diff, where I only changed the debug stuff (and introduced a > new typedef for it). The reason I didn't touch the other message > printing functions is that they call printf(3)-like functions several > times and don't do any error checking at all, and it's not clear > what to do with those functions. BTW, to test this, run a haskell binary (which might have been compiled with -threaded and -rtsopts) with options +RTS -s --internal-counters or +RTS -sFILE --internal-counters. the former uses the vdebugBelcn() case, the latter writes the statistics into the file FILE. The "interesting" part is this part of the output, because that is where I killed the %n: gen[0].sync0 0 gen[1].sync0 0 I've tested that both variants (without and with an output file) still work, so there is no regression. Ciao, Kili
Re: lang/ghc
On Wed, Sep 08, 2021 at 08:19:57PM +0200, Matthias Kilian wrote:
> > Are you at all intersted in shaving this yak all the way so we can push
> > this fix upstream?
>
> I'll have a look. Shouldn't be too much work, since there are only
> those four function pointers and only for functions actually defined.
New diff, where I only changed the debug stuff (and introduced a
new typedef for it). The reason I didn't touch the other message
printing functions is that they call printf(3)-like functions several
times and don't do any error checking at all, and it's not clear
what to do with those functions.
Fortunately, changing vdebugBelch() / debugMsgFn, rtsDebugMsgFn()
are enough to kill the %n, and rtsDebugMsgFn() calls vfprintf(3) only
once, so it's easy to let rtsDebugMsgFn() return the result of
vfprintf(3).
If upstream is interested, the next thing would be to remove those
(unnecessary) indirections via function pointers.
Ciao,
Kili
Index: Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.188
diff -u -p -r1.188 Makefile
--- Makefile16 Aug 2021 21:23:18 - 1.188
+++ Makefile12 Sep 2021 19:40:01 -
@@ -19,6 +19,8 @@ DISTNAME =ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
+REVISION = 0
+
# Version of the precompiled binaries
BIN_VER = 8.10.3.20210429
Index: patches/patch-includes_rts_Messages_h
===
RCS file: patches/patch-includes_rts_Messages_h
diff -N patches/patch-includes_rts_Messages_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-includes_rts_Messages_h 12 Sep 2021 19:40:01 -
@@ -0,0 +1,34 @@
+$OpenBSD$
+
+The debug message function has to return the number of bytes written
+(like printf(3)), to allow killing a %n format specifier in one in
+one invocation of statsPrintf() in report_summary() (rts/Stats.c).
+
+Index: includes/rts/Messages.h
+--- includes/rts/Messages.h.orig
includes/rts/Messages.h
+@@ -85,20 +85,21 @@ void vsysErrorBelch(const char *s, va_list ap);
+ void debugBelch(const char *s, ...)
+GNUC3_ATTRIBUTE(format (PRINTF, 1, 2));
+
+-void vdebugBelch(const char *s, va_list ap);
++int vdebugBelch(const char *s, va_list ap);
+
+
+ /* Hooks for redirecting message generation: */
+
+ typedef void RtsMsgFunction(const char *, va_list);
++typedef int RtsMsgFunctionRetLen(const char *, va_list);
+
+ extern RtsMsgFunction *fatalInternalErrorFn;
+-extern RtsMsgFunction *debugMsgFn;
++extern RtsMsgFunctionRetLen *debugMsgFn;
+ extern RtsMsgFunction *errorMsgFn;
+
+ /* Default stdio implementation of the message hooks: */
+
+ extern RtsMsgFunction rtsFatalInternalErrorFn;
+-extern RtsMsgFunction rtsDebugMsgFn;
++extern RtsMsgFunctionRetLen rtsDebugMsgFn;
+ extern RtsMsgFunction rtsErrorMsgFn;
+ extern RtsMsgFunction rtsSysErrorMsgFn;
Index: patches/patch-rts_RtsMessages_c
===
RCS file: patches/patch-rts_RtsMessages_c
diff -N patches/patch-rts_RtsMessages_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-rts_RtsMessages_c 12 Sep 2021 19:40:01 -
@@ -0,0 +1,65 @@
+$OpenBSD$
+
+The debug message function has to return the number of bytes written
+(like printf(3)), to allow killing a %n format specifier in one in
+one invocation of statsPrintf() in report_summary() (rts/Stats.c).
+
+Index: rts/RtsMessages.c
+--- rts/RtsMessages.c.orig
rts/RtsMessages.c
+@@ -36,7 +36,7 @@
+
+ // Default to the stdio implementation of these hooks.
+ RtsMsgFunction *fatalInternalErrorFn = rtsFatalInternalErrorFn;
+-RtsMsgFunction *debugMsgFn = rtsDebugMsgFn;
++RtsMsgFunctionRetLen *debugMsgFn = rtsDebugMsgFn;
+ RtsMsgFunction *errorMsgFn = rtsErrorMsgFn;
+ RtsMsgFunction *sysErrorMsgFn= rtsSysErrorMsgFn;
+
+@@ -102,10 +102,10 @@ debugBelch(const char*s, ...)
+ va_end(ap);
+ }
+
+-void
++int
+ vdebugBelch(const char*s, va_list ap)
+ {
+- (*debugMsgFn)(s,ap);
++ return (*debugMsgFn)(s,ap);
+ }
+
+ /*
-
+@@ -285,16 +285,16 @@ rtsSysErrorMsgFn(const char *s, va_list ap)
+ #endif
+ }
+
+-void
++int
+ rtsDebugMsgFn(const char *s, va_list ap)
+ {
++ int r;
+ #if defined(mingw32_HOST_OS)
+ /* Ensure we're in text mode so newlines get encoded properly. */
+ int mode = _setmode (_fileno(stderr), _O_TEXT);
+ if (isGUIApp())
+ {
+ char buf[BUFSIZE];
+- int r;
+
+ r = vsnprintf(buf, BUFSIZE, s, ap);
+ if (r > 0 && r < BUFSIZE) {
+@@ -305,12 +305,13 @@ rtsDebugMsgFn(const char *s, va_list ap)
+ #endif
+ {
+ /* don't fflush(stdout); WORKAROUND bug in Linux glibc */
+- vfprintf(stderr, s, ap);
++ r = vfprintf(s
Re: lang/ghc
Hi,
On Wed, Sep 08, 2021 at 06:56:05AM -0700, Greg Steuck wrote:
> Matthias Kilian writes:
>
> > +@@ -1024,8 +1024,10 @@ static void report_summary(const RTSSummaryStats*
> > sum)
> > +
> > + for (g = 0; g < RtsFlags.GcFlags.generations; g++) {
> > + int prefix_length = 0;
> > +-statsPrintf("%*s" "gen[%" FMT_Word32 "%n",
> > +-col_width[0], "", g, _length);
> > ++prefix_length = statsPrintf("%*s" "gen[%" FMT_Word32,
> > ++col_width[0], "", g);
> > ++if (prefix_length < 0)
> > ++prefix_length = 0;
> > + prefix_length -= col_width[0];
> > + int suffix_length = col_width[1] + prefix_length;
> > + suffix_length =
>
> This is all cool and proper.
>
> > +@@ -1735,9 +1737,10 @@ void getRTSStats( RTSStats *s )
> > +Dumping stuff in the stats file, or via the debug message interface
> > +
> > --
> > */
> > +
> > +-void
> > ++int
> > + statsPrintf( char *s, ... )
> > + {
> > ++int ret = 0;
> > + FILE *sf = RtsFlags.GcFlags.statsFile;
> > + va_list ap;
> > +
> > +@@ -1745,9 +1748,10 @@ statsPrintf( char *s, ... )
> > + if (sf == NULL) {
> > + vdebugBelch(s,ap);
>
> vdebugBelch should also count the bytes, right? Otherwise we return 0
> below and introduce a bug.
Wouldn't this just cause badly formatted output? I'm not sure for what
that whole beast (report_summary()) is used for, except for looking at
the outpu.
> Looking into the depths of vdebugBelch shows
> that we also need to change the type of debugMsgFn.
The funny thing is that debugMsgFn is only assigned in one place
in the code. The same for the other three RtsMsgFunction function
pointers. This smells like overengineering to me ;-)
> Are you at all intersted in shaving this yak all the way so we can push
> this fix upstream?
I'll have a look. Shouldn't be too much work, since there are only
those four function pointers and only for functions actually defined.
> The least appealing part is testing the change as %n this seems to only
> be used with somewhat esoteric runtime settings.
Well, %n popped up in /var/log/messages of the bulk build machines,
so it shouldn't appear with the fix.
At the moment I'm waiting for the rebuild of all haskell ports on
my machine (with my diff from yesterday). When that is ready, I'll look
at the debugMsgFn stuff.
Ciao,
Kili
Re: lang/ghc
Thank you for looking into this, I meant to, but was slightly turned off
by the depth of the rabbit hole. I'll annotate it below.
Matthias Kilian writes:
> +@@ -1024,8 +1024,10 @@ static void report_summary(const RTSSummaryStats* sum)
> +
> + for (g = 0; g < RtsFlags.GcFlags.generations; g++) {
> + int prefix_length = 0;
> +-statsPrintf("%*s" "gen[%" FMT_Word32 "%n",
> +-col_width[0], "", g, _length);
> ++prefix_length = statsPrintf("%*s" "gen[%" FMT_Word32,
> ++col_width[0], "", g);
> ++if (prefix_length < 0)
> ++prefix_length = 0;
> + prefix_length -= col_width[0];
> + int suffix_length = col_width[1] + prefix_length;
> + suffix_length =
This is all cool and proper.
> +@@ -1735,9 +1737,10 @@ void getRTSStats( RTSStats *s )
> +Dumping stuff in the stats file, or via the debug message interface
> +
> -- */
> +
> +-void
> ++int
> + statsPrintf( char *s, ... )
> + {
> ++int ret = 0;
> + FILE *sf = RtsFlags.GcFlags.statsFile;
> + va_list ap;
> +
> +@@ -1745,9 +1748,10 @@ statsPrintf( char *s, ... )
> + if (sf == NULL) {
> + vdebugBelch(s,ap);
vdebugBelch should also count the bytes, right? Otherwise we return 0
below and introduce a bug. Looking into the depths of vdebugBelch shows
that we also need to change the type of debugMsgFn.
Are you at all intersted in shaving this yak all the way so we can push
this fix upstream?
The least appealing part is testing the change as %n this seems to only
be used with somewhat esoteric runtime settings.
Thanks
Greg
lang/ghc (was: Warnings for %n in format strings)
Hi,
On Tue, Sep 07, 2021 at 09:24:31PM +0200, Christian Weisgerber wrote:
> lang/ghcThe OpenBSD ports mailing-list
Untested patch -- I'll probably get a test build with it together
with all ports depending on ghc tomorrow, but if anyone want's to
beat me ...
Ciao,
Kili
Index: Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.188
diff -u -p -r1.188 Makefile
--- Makefile16 Aug 2021 21:23:18 - 1.188
+++ Makefile7 Sep 2021 20:42:00 -
@@ -19,6 +19,8 @@ DISTNAME =ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
+REVISION = 0
+
# Version of the precompiled binaries
BIN_VER = 8.10.3.20210429
Index: patches/patch-rts_Stats_c
===
RCS file: patches/patch-rts_Stats_c
diff -N patches/patch-rts_Stats_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-rts_Stats_c 7 Sep 2021 20:42:00 -
@@ -0,0 +1,53 @@
+$OpenBSD$
+
+Kill use of %n format specifier.
+
+Index: rts/Stats.c
+--- rts/Stats.c.orig
rts/Stats.c
+@@ -69,7 +69,7 @@ static Time *GC_coll_cpu = NULL;
+ static Time *GC_coll_elapsed = NULL;
+ static Time *GC_coll_max_pause = NULL;
+
+-static void statsPrintf( char *s, ... ) GNUC3_ATTRIBUTE(format (PRINTF, 1,
2));
++static int statsPrintf( char *s, ... ) GNUC3_ATTRIBUTE(format (PRINTF, 1, 2));
+ static void statsFlush( void );
+ static void statsClose( void );
+
+@@ -1024,8 +1024,10 @@ static void report_summary(const RTSSummaryStats* sum)
+
+ for (g = 0; g < RtsFlags.GcFlags.generations; g++) {
+ int prefix_length = 0;
+-statsPrintf("%*s" "gen[%" FMT_Word32 "%n",
+-col_width[0], "", g, _length);
++prefix_length = statsPrintf("%*s" "gen[%" FMT_Word32,
++col_width[0], "", g);
++if (prefix_length < 0)
++prefix_length = 0;
+ prefix_length -= col_width[0];
+ int suffix_length = col_width[1] + prefix_length;
+ suffix_length =
+@@ -1735,9 +1737,10 @@ void getRTSStats( RTSStats *s )
+Dumping stuff in the stats file, or via the debug message interface
+--
*/
+
+-void
++int
+ statsPrintf( char *s, ... )
+ {
++int ret = 0;
+ FILE *sf = RtsFlags.GcFlags.statsFile;
+ va_list ap;
+
+@@ -1745,9 +1748,10 @@ statsPrintf( char *s, ... )
+ if (sf == NULL) {
+ vdebugBelch(s,ap);
+ } else {
+-vfprintf(sf, s, ap);
++ret = vfprintf(sf, s, ap);
+ }
+ va_end(ap);
++return ret;
+ }
+
+ static void
[PATCH] Update lang/ghc to 8.10.6
A couple of patches are obsolete now.
I built ghc on amd64 and i386. I rebuilt the majority of haskell ports
on amd64.
OK?
https://downloads.haskell.org/~ghc/8.10.6/docs/html/users_guide/8.10.6-notes.html
---
lang/ghc/Makefile | 15 +--
lang/ghc/distinfo | 8 +++---
.../patches/patch-docs_users_guide_conf_py| 17
...tch-libraries_process_include_runProcess_h | 26 ---
lang/ghc/pkg/PFRAG.no_i386| 6 +++--
5 files changed, 15 insertions(+), 57 deletions(-)
delete mode 100644 lang/ghc/patches/patch-docs_users_guide_conf_py
delete mode 100644
lang/ghc/patches/patch-libraries_process_include_runProcess_h
diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
index 18154271f33..a5c0bee96e3 100644
--- a/lang/ghc/Makefile
+++ b/lang/ghc/Makefile
@@ -14,11 +14,10 @@ COMMENT = compiler for the functional language
Haskell
# ghc hardcodes ${WRKDIR}/bin/gcc when the package is compiled with ccache
NO_CCACHE =Yes
-GHC_VERSION = 8.10.5
+GHC_VERSION = 8.10.6
DISTNAME = ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
-REVISION = 0
# Version of the precompiled binaries
BIN_VER = 8.10.3.20210429
@@ -73,24 +72,24 @@ SUPDISTFILES += ${BINDISTFILE-$m}
GHC_ITEMS = \
CABAL 3.2.1.0 \
ARRAY 0.5.4.0 \
-BASE 4.14.2.0 \
+BASE 4.14.3.0 \
BINARY 0.8.8.0 \
BYTESTRING 0.10.12.0\
-CONTAINERS 0.6.4.1 \
+CONTAINERS 0.6.5.1 \
DEEPSEQ1.4.4.0 \
DIRECTORY 1.3.6.0 \
EXCEPTIONS 0.10.4 \
FILEPATH 1.4.2.1 \
-GHC8.10.5 \
+GHC8.10.6 \
GHC_COMPACT0.1.0.0 \
GHC_PRIM 0.6.1\
-HASKELINE 0.8.0.1 \
+HASKELINE 0.8.2\
HPC0.6.1.0 \
INTEGER_GMP1.0.3.0 \
MTL2.2.2\
PARSEC 3.1.14.0 \
PRETTY 1.1.3.6 \
-PROCESS1.6.9.0 \
+PROCESS1.6.13.2 \
STM2.5.0.1 \
TEMPLATE-HASKELL2.16.0.0 \
TERMINFO0.4.1.4 \
@@ -108,7 +107,7 @@ SUBST_VARS += ${_i}_VER
USE_GMAKE =Yes
USE_GROFF =Yes
-AUTOCONF_VERSION = 2.69
+AUTOCONF_VERSION = 2.71
CONFIGURE_STYLE = gnu autoconf no-autoheader
CONFIGURE_ARGS += --with-ffi-includes=${LOCALBASE}/include \
--with-ffi-libraries=${LOCALBASE}/lib \
diff --git a/lang/ghc/distinfo b/lang/ghc/distinfo
index 0175fe6c8ec..b8ccc7a99c1 100644
--- a/lang/ghc/distinfo
+++ b/lang/ghc/distinfo
@@ -2,11 +2,11 @@ SHA256 (ghc/ghc-8.10.3.20210429-amd64-unknown-openbsd.tar.xz)
= GR5pHBh8PWUn12UK
SHA256 (ghc/ghc-8.10.3.20210429-i386-unknown-openbsd.tar.xz) =
T1OMZYN2sr+E88g88qElX6RYZbPdqANXGhWgCfKdFiY=
SHA256 (ghc/ghc-8.10.3.20210429-shlibs-amd64.tar.gz) =
M+B6p7cC4v3f1BrArX1DW6sie+HX3itEW5cTftI9yZE=
SHA256 (ghc/ghc-8.10.3.20210429-shlibs-i386.tar.gz) =
A/paDCY65gLRxas7/mNGUg0W7lR9XWJcJmnAJkcf5C4=
-SHA256 (ghc/ghc-8.10.5-src.tar.xz) =
8QlB8W5PvZhYCrUkG5JxuwhRMEVgxNXKEn47DiDjB28=
-SHA256 (ghc/ghc-8.10.5-testsuite.tar.xz) =
ppkkqER2FLzgE3WJZm5EX2FxO2XlHmj1Rtgsl8k5mG0=
+SHA256 (ghc/ghc-8.10.6-src.tar.xz) =
Q6+6cqUzQItCwUkr0Ee1435fcgTkGlzt0xgsyEFhDOk=
+SHA256 (ghc/ghc-8.10.6-testsuite.tar.xz) =
6yX1PAvNC/Sae0ndofh95GH9kzs/a1FitvidSE298rk=
SIZE (ghc/ghc-8.10.3.20210429-amd64-unknown-openbsd.tar.xz) = 48779544
SIZE (ghc/ghc-8.10.3.20210429-i386-unknown-openbsd.tar.xz) = 49505820
SIZE (ghc/ghc-8.10.3.20210429-shlibs-amd64.tar.gz) = 2910620
SIZE (ghc/ghc-8.10.3.20210429-shlibs-i386.tar.gz) = 2759631
-SIZE (ghc/ghc-8.10.5-src.tar.xz) = 19920148
-SIZE (ghc/ghc-8.10.5-testsuite.tar.xz) = 2270504
+SIZE (ghc/ghc-8.10.6-src.tar.xz) = 19932832
+SIZE (ghc/ghc-8.10.6-testsuite.tar.xz) = 2265044
diff --git a/lang/ghc/patches/patch-docs_users_guide_conf_py
b/lang/ghc/patches/patch-docs_users_guide_conf_py
deleted file mode 100644
index ae2529f9664..000
--- a/lang/ghc/patches/patch-docs_users_guide_conf_py
+++ /dev/null
@@ -1,17 +0,0 @@
-$OpenBSD: patch-docs_users_guide_conf_py,v 1.1 2021/07/06 16:55:33 daniel Exp $
-
-sphinx 4.0.2 build-time fix; part of upstream commit
-83407ffc
Re: [PATCH] Update lang/ghc to 8.10.5
Matthias Kilian writes: > On Sun, Jun 06, 2021 at 11:22:56PM -0700, Greg Steuck wrote: >> A new GHC release with some good enhancements just arrived: >> https://www.haskell.org/ghc/blog/20210605-ghc-8.10.5-released.html >> >> I tested this by rebuilding ghc, cabal-install, and cabal-bundler on >> amd64 so far. I'll rebuild the rest of Haskell ports in due time. >> >> The change in cabal-install has to be synchronized due to some >> internal version numbers being embedded into the JSON file. >> >> OK? > > Yes. Committing. I rebuilt all dependents on amd64 and built the ghc package on i386. Thanks Greg
Re: [PATCH] Update lang/ghc to 8.10.5
Hi, On Sun, Jun 06, 2021 at 11:22:56PM -0700, Greg Steuck wrote: > A new GHC release with some good enhancements just arrived: > https://www.haskell.org/ghc/blog/20210605-ghc-8.10.5-released.html > > I tested this by rebuilding ghc, cabal-install, and cabal-bundler on > amd64 so far. I'll rebuild the rest of Haskell ports in due time. > > The change in cabal-install has to be synchronized due to some > internal version numbers being embedded into the JSON file. > > OK? Yes. Ciao, Kili
[PATCH] Update lang/ghc to 8.10.5
A new GHC release with some good enhancements just arrived: https://www.haskell.org/ghc/blog/20210605-ghc-8.10.5-released.html I tested this by rebuilding ghc, cabal-install, and cabal-bundler on amd64 so far. I'll rebuild the rest of Haskell ports in due time. The change in cabal-install has to be synchronized due to some internal version numbers being embedded into the JSON file. OK? 0001-Update-lang-ghc-to-8.10.5.patch.gz Description: Binary data
Re: Bootstrap lang/ghc with GHC 8.10.3
Hi Greg,
On Sun, May 02, 2021 at 09:38:47AM -0700, Greg Steuck wrote:
> The new bootstrap you kindly built works fine on amd64 and i386. I
> propose we switch to it.
>
> OK?
Yes.
Ciao,
Kili
> >From 4cfc4013dc3200c77a150b110084a660899e4d43 Mon Sep 17 00:00:00 2001
> From: Greg Steuck
> Date: Fri, 30 Apr 2021 18:11:55 -0700
> Subject: [PATCH] Bootstrap lang/ghc with GHC 8.10.3
>
> ---
> lang/ghc/Makefile | 3 ++-
> lang/ghc/distinfo | 16
> 2 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
> index a1b832cd962..4e39258967b 100644
> --- a/lang/ghc/Makefile
> +++ b/lang/ghc/Makefile
> @@ -18,9 +18,10 @@ GHC_VERSION = 8.10.3
> DISTNAME = ghc-${GHC_VERSION}
> CATEGORIES = lang devel
> HOMEPAGE = https://www.haskell.org/ghc/
> +REVISION = 0
>
> # Version of the precompiled binaries
> -BIN_VER =8.6.4.20200921
> +BIN_VER =8.10.3.20210429
>
> # lang/python needed for regression tests.
> MODULES =lang/python
> diff --git a/lang/ghc/distinfo b/lang/ghc/distinfo
> index 6341d6417d8..437c1204df3 100644
> --- a/lang/ghc/distinfo
> +++ b/lang/ghc/distinfo
> @@ -1,12 +1,12 @@
> SHA256 (ghc/ghc-8.10.3-src.tar.xz) =
> zNyDGVSQKKcI1xY+KWc4JnexpaN5/5TZSBlbXPRuuTE=
> SHA256 (ghc/ghc-8.10.3-testsuite.tar.xz) =
> j4LmkGf+aaH9CRYyXYx2yQsFA5Ppw3pwJ01g+bNM/gA=
> -SHA256 (ghc/ghc-8.6.4.20200921-amd64-unknown-openbsd.tar.xz) =
> +GibRIQEpmzfb2Cm2l04iDpHC3AwPURCmrUuW1rajQ4=
> -SHA256 (ghc/ghc-8.6.4.20200921-i386-unknown-openbsd.tar.xz) =
> RGZzrDVc5qF6UA6tAWMUp2T6+uav+WXwqFJiGa1/IxY=
> -SHA256 (ghc/ghc-8.6.4.20200921-shlibs-amd64.tar.gz) =
> 4ZHNJC6zIiV664OI8mhN1GXyOoUqwLlZ5lY3M3QLGXI=
> -SHA256 (ghc/ghc-8.6.4.20200921-shlibs-i386.tar.gz) =
> AxWz+RYTt6O6vrwKW6YKqhbXvhSmYqDPEdiIrwUzpSw=
> +SHA256 (ghc/ghc-8.10.3.20210429-amd64-unknown-openbsd.tar.xz) =
> GR5pHBh8PWUn12UK+XZ6ikB2+xWxkdqAsYaEBsiR0Zo=
> +SHA256 (ghc/ghc-8.10.3.20210429-i386-unknown-openbsd.tar.xz) =
> T1OMZYN2sr+E88g88qElX6RYZbPdqANXGhWgCfKdFiY=
> +SHA256 (ghc/ghc-8.10.3.20210429-shlibs-amd64.tar.gz) =
> M+B6p7cC4v3f1BrArX1DW6sie+HX3itEW5cTftI9yZE=
> +SHA256 (ghc/ghc-8.10.3.20210429-shlibs-i386.tar.gz) =
> A/paDCY65gLRxas7/mNGUg0W7lR9XWJcJmnAJkcf5C4=
> SIZE (ghc/ghc-8.10.3-src.tar.xz) = 19872356
> SIZE (ghc/ghc-8.10.3-testsuite.tar.xz) = 2261376
> -SIZE (ghc/ghc-8.6.4.20200921-amd64-unknown-openbsd.tar.xz) = 52968260
> -SIZE (ghc/ghc-8.6.4.20200921-i386-unknown-openbsd.tar.xz) = 53538452
> -SIZE (ghc/ghc-8.6.4.20200921-shlibs-amd64.tar.gz) = 2908271
> -SIZE (ghc/ghc-8.6.4.20200921-shlibs-i386.tar.gz) = 2751126
> +SIZE (ghc/ghc-8.10.3.20210429-amd64-unknown-openbsd.tar.xz) = 48779544
> +SIZE (ghc/ghc-8.10.3.20210429-i386-unknown-openbsd.tar.xz) = 49505820
> +SIZE (ghc/ghc-8.10.3.20210429-shlibs-amd64.tar.gz) = 2910620
> +SIZE (ghc/ghc-8.10.3.20210429-shlibs-i386.tar.gz) = 2759631
> --
> 2.31.1
Bootstrap lang/ghc with GHC 8.10.3
Hi Matthias,
The new bootstrap you kindly built works fine on amd64 and i386. I
propose we switch to it.
OK?
>From 4cfc4013dc3200c77a150b110084a660899e4d43 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Fri, 30 Apr 2021 18:11:55 -0700
Subject: [PATCH] Bootstrap lang/ghc with GHC 8.10.3
---
lang/ghc/Makefile | 3 ++-
lang/ghc/distinfo | 16
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
index a1b832cd962..4e39258967b 100644
--- a/lang/ghc/Makefile
+++ b/lang/ghc/Makefile
@@ -18,9 +18,10 @@ GHC_VERSION =8.10.3
DISTNAME = ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
+REVISION = 0
# Version of the precompiled binaries
-BIN_VER = 8.6.4.20200921
+BIN_VER = 8.10.3.20210429
# lang/python needed for regression tests.
MODULES = lang/python
diff --git a/lang/ghc/distinfo b/lang/ghc/distinfo
index 6341d6417d8..437c1204df3 100644
--- a/lang/ghc/distinfo
+++ b/lang/ghc/distinfo
@@ -1,12 +1,12 @@
SHA256 (ghc/ghc-8.10.3-src.tar.xz) =
zNyDGVSQKKcI1xY+KWc4JnexpaN5/5TZSBlbXPRuuTE=
SHA256 (ghc/ghc-8.10.3-testsuite.tar.xz) =
j4LmkGf+aaH9CRYyXYx2yQsFA5Ppw3pwJ01g+bNM/gA=
-SHA256 (ghc/ghc-8.6.4.20200921-amd64-unknown-openbsd.tar.xz) =
+GibRIQEpmzfb2Cm2l04iDpHC3AwPURCmrUuW1rajQ4=
-SHA256 (ghc/ghc-8.6.4.20200921-i386-unknown-openbsd.tar.xz) =
RGZzrDVc5qF6UA6tAWMUp2T6+uav+WXwqFJiGa1/IxY=
-SHA256 (ghc/ghc-8.6.4.20200921-shlibs-amd64.tar.gz) =
4ZHNJC6zIiV664OI8mhN1GXyOoUqwLlZ5lY3M3QLGXI=
-SHA256 (ghc/ghc-8.6.4.20200921-shlibs-i386.tar.gz) =
AxWz+RYTt6O6vrwKW6YKqhbXvhSmYqDPEdiIrwUzpSw=
+SHA256 (ghc/ghc-8.10.3.20210429-amd64-unknown-openbsd.tar.xz) =
GR5pHBh8PWUn12UK+XZ6ikB2+xWxkdqAsYaEBsiR0Zo=
+SHA256 (ghc/ghc-8.10.3.20210429-i386-unknown-openbsd.tar.xz) =
T1OMZYN2sr+E88g88qElX6RYZbPdqANXGhWgCfKdFiY=
+SHA256 (ghc/ghc-8.10.3.20210429-shlibs-amd64.tar.gz) =
M+B6p7cC4v3f1BrArX1DW6sie+HX3itEW5cTftI9yZE=
+SHA256 (ghc/ghc-8.10.3.20210429-shlibs-i386.tar.gz) =
A/paDCY65gLRxas7/mNGUg0W7lR9XWJcJmnAJkcf5C4=
SIZE (ghc/ghc-8.10.3-src.tar.xz) = 19872356
SIZE (ghc/ghc-8.10.3-testsuite.tar.xz) = 2261376
-SIZE (ghc/ghc-8.6.4.20200921-amd64-unknown-openbsd.tar.xz) = 52968260
-SIZE (ghc/ghc-8.6.4.20200921-i386-unknown-openbsd.tar.xz) = 53538452
-SIZE (ghc/ghc-8.6.4.20200921-shlibs-amd64.tar.gz) = 2908271
-SIZE (ghc/ghc-8.6.4.20200921-shlibs-i386.tar.gz) = 2751126
+SIZE (ghc/ghc-8.10.3.20210429-amd64-unknown-openbsd.tar.xz) = 48779544
+SIZE (ghc/ghc-8.10.3.20210429-i386-unknown-openbsd.tar.xz) = 49505820
+SIZE (ghc/ghc-8.10.3.20210429-shlibs-amd64.tar.gz) = 2910620
+SIZE (ghc/ghc-8.10.3.20210429-shlibs-i386.tar.gz) = 2759631
--
2.31.1
Re: Revive ONLY_FOR_ARCHS in lang/ghc
Hi, On Mon, Mar 15, 2021 at 09:16:40PM -0700, Greg Steuck wrote: > This was previously in all ghc-dependent ports. Let me know if adding a > similar setting to cabal.port.mk makes or sense. Otherwise I expect the > lang/ghc depedency they all have to effectively block them. > > OK? Sure. Ciao, Kili > Subject: [PATCH] Revive ONLY_FOR_ARCHS in lang/ghc > > It was lost in ghc.port.mk removal, pointed out by tb@ > --- > lang/ghc/Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile > index 7b6c5863bb3..0d7e8dee1fb 100644 > --- a/lang/ghc/Makefile > +++ b/lang/ghc/Makefile > @@ -1,5 +1,8 @@ > # $OpenBSD: Makefile,v 1.182 2021/03/10 01:33:40 gnezdo Exp $ > > +# Not yet ported to other architectures > +ONLY_FOR_ARCHS = i386 amd64 > + > COMMENT =compiler for the functional language Haskell > > # Note: please never ever set DPB_PROPERTIES=parallel (or some other > -- > 2.30.2
Revive ONLY_FOR_ARCHS in lang/ghc
This was previously in all ghc-dependent ports. Let me know if adding a similar setting to cabal.port.mk makes or sense. Otherwise I expect the lang/ghc depedency they all have to effectively block them. OK? Subject: [PATCH] Revive ONLY_FOR_ARCHS in lang/ghc It was lost in ghc.port.mk removal, pointed out by tb@ --- lang/ghc/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile index 7b6c5863bb3..0d7e8dee1fb 100644 --- a/lang/ghc/Makefile +++ b/lang/ghc/Makefile @@ -1,5 +1,8 @@ # $OpenBSD: Makefile,v 1.182 2021/03/10 01:33:40 gnezdo Exp $ +# Not yet ported to other architectures +ONLY_FOR_ARCHS = i386 amd64 + COMMENT = compiler for the functional language Haskell # Note: please never ever set DPB_PROPERTIES=parallel (or some other -- 2.30.2
Re: devel/vabal-install: run_depend on lang/ghc
On Thu, Mar 11, 2021 at 02:35:01PM -0800, Greg Steuck wrote: > I can construct some contrived scenarios like people wanting to use a > custom ghc they built and also wanting to be double-sure there's no ghc > from the package. But this kind of people can figure out how to implement > their desiderata despite the dependency constraint. Having the dependency > is more often helpful than not. So, OK gnezdo. I concur, OK kn.
Re: devel/vabal-install: run_depend on lang/ghc
I can construct some contrived scenarios like people wanting to use a
custom ghc they built and also wanting to be double-sure there's no ghc
from the package. But this kind of people can figure out how to implement
their desiderata despite the dependency constraint. Having the dependency
is more often helpful than not. So, OK gnezdo.
On Thu, Mar 11, 2021 at 2:29 PM Matthias Kilian
wrote:
> Hi,
>
> would anyone use cabal-install without having ghc installed?
>
> Ciao,
> Kili
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/cabal-install/Makefile,v
> retrieving revision 1.26
> diff -u -p -r1.26 Makefile
> --- Makefile10 Mar 2021 01:33:55 - 1.26
> +++ Makefile11 Mar 2021 22:21:50 -
> @@ -4,7 +4,7 @@ COMMENT = command-line interface for Cab
>
> DISTNAME = cabal-install-3.4.0.0
> CATEGORIES = devel
> -REVISION = 0
> +REVISION = 1
>
> GH_ACCOUNT = haskell
> GH_TAGNAME = ${DISTNAME}
> @@ -24,6 +24,8 @@ MODGHC_BUILD = cabal hackage no
> LIB_DEPENDS = converters/libiconv \
> devel/gmp \
> devel/libffi
> +
> +RUN_DEPENDS = lang/ghc
>
> # bootstrap.py handles the extraction of the rest of files.
> EXTRACT_ONLY = ${DISTNAME}.tar.gz
>
--
nest.cx is Gmail hosted, use PGP:
https://pgp.key-server.io/0x0B1542BD8DF5A1B0
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
devel/vabal-install: run_depend on lang/ghc
Hi,
would anyone use cabal-install without having ghc installed?
Ciao,
Kili
Index: Makefile
===
RCS file: /cvs/ports/devel/cabal-install/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- Makefile10 Mar 2021 01:33:55 - 1.26
+++ Makefile11 Mar 2021 22:21:50 -
@@ -4,7 +4,7 @@ COMMENT = command-line interface for Cab
DISTNAME = cabal-install-3.4.0.0
CATEGORIES = devel
-REVISION = 0
+REVISION = 1
GH_ACCOUNT = haskell
GH_TAGNAME = ${DISTNAME}
@@ -24,6 +24,8 @@ MODGHC_BUILD = cabal hackage no
LIB_DEPENDS = converters/libiconv \
devel/gmp \
devel/libffi
+
+RUN_DEPENDS = lang/ghc
# bootstrap.py handles the extraction of the rest of files.
EXTRACT_ONLY = ${DISTNAME}.tar.gz
Re: Question about lang/ghc module (trying to port git-annex)
> > A few notes / questions: > > > > * I fixed a couple of typos in > > > > https://github.com/falsifian/ports/commit/98111e702634842865a3d27675b6848e3fb2b7ca > > > > * I added example usage for cabal-bundler. I hope I got it right: > > > > https://github.com/falsifian/ports/commit/f21cb097f215831b1d08443f9074073895a13731 > > Neat. I'll pick these up. > > > * If I find more time to work on this, should I polish my git-annex > > port, or is there something more useful I could be doing with your > > Cabal infrastructure? (I installed darcs and it seems to work.) > > Great! I don't think there's much else to do besides waiting for > cabal-install 3.4.0.0 to be pushed to Hackage. Depending on how this > aligns with 6.9 release we may or may not ship it then. > > You could try to build your own port of a Haskell binary you use that we > don't have yet. Your experience will likely tell us something about the > level of maturity of this infra. The only unported Haskell binaries I use are personal projects that are not on Hackage. I could try locally porting one of those as an experiment. > > * I tried to enable tests, partly because Darcs has a comprehensive > > test suite. I ran into some trouble. My WIP is here: > > > > https://github.com/falsifian/ports/commit/99cb0e33e2263cf15979a19bf068d345630c > > One problem is that cabal-bundler doesn't seem to be outputting test > > dependencies. > > I keep track of this issue in https://github.com/blackgnezdo/ports/issues/13. > See if you agree with my assessment there. Thanks, I commented there. > > * It's a pity that your approach doesn't allow Cabal-based ports to > > share dependencies. > > I chose to trade-off compute to gain simlpicity and flexibility: > https://github.com/blackgnezdo/ports/issues/3#issuecomment-650823377 > > Until this choice turns to be expensive enough to cause port builders to > complain I'm inclined to keep this approach. Okay, that's reasonable. My only concern: later on if people do complain and it's decided it's a real problem, is there a path forward that builds on what you've already got? Or would you have to start from scratch to address it? (I could complain already, but for me at least your solution is a definite improvement over the status quo. The build times aren't the end of the world.) > > Some thoughts on mitigating or solving this, in decreasing order of > > plausability: > > * Is it possible to hand-pick some particularly slow ones, make > > packages for them, and then tell Cabal to use those packages? E.g. > > aeson takes a while to build. > > Sadly this will move towards tree-wide configuration management which > was a very non-fun thing to do as you experienced first-hand trying to > deal with a ton of ports when you tried to add git-annex. Maybe there could be a rule of thumb, like adding a reusable port is only worth it if it reduces the total time to build all ports by at least X hours? I don't know if there are any libraries that meet that definition for an appropriate value of X. > > I guess it would be ugly to fill the ports tree with hundreds(?) of > > directories each with an auto-generated package. I'm not sure if > > there's a way to smoosh it all into one big file. E.g. I see > > there's something called "multi-packages", but I'm guessing that's > > not designed to handle hundreds of subpackages. > > I've seen how these things play out in much bigger code bases with many > people over time. We don't have enough people working on ports@ to > manage this. That makes sense. I imagine your approach will keep things easier for maintainers: e.g. I'm not going to accidentally break darcs by updating the dependencies of git-annex. > > * Is it possible to cheat, by having all the Cabal-based ports share > > their Cabal directory? So if I build darcs then git-annex, Cabal > > has access to all the build products from darcs when it builds > > git-annex. I guess one problem is this might make the build output > > depend on the order in which you build things, if Cabal > > opportunistically uses whatever versions are there. > > The root of the problem is GHC compilation speed. My preferred and > universally useful optimizations would be: > > * Use/build something like ccache for ghc > * Speed up ghc itself Those would be cool! > > * Are you planning to commit these changes all at once? Or is there > > some way to have an intermediate state where both old-style and > > new-style packages work? > > I don't see how it would be possible to have the old and new coexist. > ghc-8.10 is incompatible with the haskell ports in the tree. My plan is > to land this as a bundle. I wrote it up in an email to ports@ before. I didn't know about the incompatibility. Maybe there could be two separate ghc versions for a while, but I guess that's more trouble than it's worth. > Thanks > Greg -- James
Re: Question about lang/ghc module (trying to port git-annex)
Greg Steuck writes: > You could test pandoc as it is done: > https://github.com/blackgnezdo/ports/commit/609197ce3f84a2e4a147fcabcc5eb71d3cf10ca2 > > The full list is https://github.com/blackgnezdo/ports/commits/ghc-8.10 Splendid! Thank you for this.
Re: Question about lang/ghc module (trying to port git-annex)
On Fri, Feb 19, 2021 at 5:19 AM Ashton Fagg wrote > Hi Greg, > > I've been considering trying to port pandoc, but was put off by the > sheer amount of dependencies that would need to be ported as well. > > I'll give your work a try and see if it works well for that also, if > that's of interest to you? > You could test pandoc as it is done: https://github.com/blackgnezdo/ports/commit/609197ce3f84a2e4a147fcabcc5eb71d3cf10ca2 The full list is https://github.com/blackgnezdo/ports/commits/ghc-8.10 Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
Re: Question about lang/ghc module (trying to port git-annex)
Greg Steuck writes: > This is exactly the problem I want to solve with cabal.port.mk. You > can try to look at > https://marc.info/?l=openbsd-ports=160858285410366=2 > A quick search in the archives will show the justification and the > history of the effort. > > The current state of the work is I'm waiting on cabal 3.4 official > release gated by ghc-9.0. I'm also looking for people needing this work > and your attempt to add git-annex gives me more motivation to finish. Hi Greg, I've been considering trying to port pandoc, but was put off by the sheer amount of dependencies that would need to be ported as well. I'll give your work a try and see if it works well for that also, if that's of interest to you? Cheers, Ash
Re: Question about lang/ghc module (trying to port git-annex)
Hi James, James Cook writes: > Incidentally, I asked the maintainer how man pages are supposed to be > installed, and they said it's best to use the Makefile if you want a > complete installation. Probably not worth changing our port, but > something to keep in mind in case this turns out to be a pattern. > https://git-annex.branchable.com/bugs/__91__Patch__93___fix___34__mdwn2man__58___cannot_execute_-_...__34__/ Thanks. We can leave this as is unless it proves more trouble than adjusting the recipe going forward. > A few notes / questions: > > * I fixed a couple of typos in > > https://github.com/falsifian/ports/commit/98111e702634842865a3d27675b6848e3fb2b7ca > > * I added example usage for cabal-bundler. I hope I got it right: > > https://github.com/falsifian/ports/commit/f21cb097f215831b1d08443f9074073895a13731 Neat. I'll pick these up. > * If I find more time to work on this, should I polish my git-annex > port, or is there something more useful I could be doing with your > Cabal infrastructure? (I installed darcs and it seems to work.) Great! I don't think there's much else to do besides waiting for cabal-install 3.4.0.0 to be pushed to Hackage. Depending on how this aligns with 6.9 release we may or may not ship it then. You could try to build your own port of a Haskell binary you use that we don't have yet. Your experience will likely tell us something about the level of maturity of this infra. > * I tried to enable tests, partly because Darcs has a comprehensive > test suite. I ran into some trouble. My WIP is here: > > https://github.com/falsifian/ports/commit/99cb0e33e2263cf15979a19bf068d345630c > One problem is that cabal-bundler doesn't seem to be outputting test > dependencies. I keep track of this issue in https://github.com/blackgnezdo/ports/issues/13. See if you agree with my assessment there. > * It's a pity that your approach doesn't allow Cabal-based ports to > share dependencies. I chose to trade-off compute to gain simlpicity and flexibility: https://github.com/blackgnezdo/ports/issues/3#issuecomment-650823377 Until this choice turns to be expensive enough to cause port builders to complain I'm inclined to keep this approach. > Some thoughts on mitigating or solving this, in decreasing order of > plausability: > * Is it possible to hand-pick some particularly slow ones, make > packages for them, and then tell Cabal to use those packages? E.g. > aeson takes a while to build. Sadly this will move towards tree-wide configuration management which was a very non-fun thing to do as you experienced first-hand trying to deal with a ton of ports when you tried to add git-annex. > * nixpkgs (the only package system I'm really familiar with) deals > with Cabal by automatically generating package descriptions for > everything on hackage. I wonder if something along those lines > would be do-able. cabal-bundler --openbsd is a play in this area. I just limited it to the absolute minimum I could get away with. > I guess it would be ugly to fill the ports tree with hundreds(?) of > directories each with an auto-generated package. I'm not sure if > there's a way to smoosh it all into one big file. E.g. I see > there's something called "multi-packages", but I'm guessing that's > not designed to handle hundreds of subpackages. I've seen how these things play out in much bigger code bases with many people over time. We don't have enough people working on ports@ to manage this. > * Is it possible to cheat, by having all the Cabal-based ports share > their Cabal directory? So if I build darcs then git-annex, Cabal > has access to all the build products from darcs when it builds > git-annex. I guess one problem is this might make the build output > depend on the order in which you build things, if Cabal > opportunistically uses whatever versions are there. The root of the problem is GHC compilation speed. My preferred and universally useful optimizations would be: * Use/build something like ccache for ghc * Speed up ghc itself > * Are you planning to commit these changes all at once? Or is there > some way to have an intermediate state where both old-style and > new-style packages work? I don't see how it would be possible to have the old and new coexist. ghc-8.10 is incompatible with the haskell ports in the tree. My plan is to land this as a bundle. I wrote it up in an email to ports@ before. Thanks Greg
Re: Question about lang/ghc module (trying to port git-annex)
Hi Greg, > >> I'll dig into this a bit. I simply didn't need to worry about this up > >> until now as all the other ports don't do much custom Setup.hs work. > > > > I don't know if there will be any cases other than man pages and > > git-annex's command aliases. Not sure how much effort it's worth. > > The default action of doing nothing is valid :) Incidentally, I asked the maintainer how man pages are supposed to be installed, and they said it's best to use the Makefile if you want a complete installation. Probably not worth changing our port, but something to keep in mind in case this turns out to be a pattern. https://git-annex.branchable.com/bugs/__91__Patch__93___fix___34__mdwn2man__58___cannot_execute_-_...__34__/ A few notes / questions: * I fixed a couple of typos in https://github.com/falsifian/ports/commit/98111e702634842865a3d27675b6848e3fb2b7ca * I added example usage for cabal-bundler. I hope I got it right: https://github.com/falsifian/ports/commit/f21cb097f215831b1d08443f9074073895a13731 * If I find more time to work on this, should I polish my git-annex port, or is there something more useful I could be doing with your Cabal infrastructure? (I installed darcs and it seems to work.) * I tried to enable tests, partly because Darcs has a comprehensive test suite. I ran into some trouble. My WIP is here: https://github.com/falsifian/ports/commit/99cb0e33e2263cf15979a19bf068d345630c One problem is that cabal-bundler doesn't seem to be outputting test dependencies. (I tried manually adding some, not included in my commit.) Another is that, even if I add test dependencies manually, I end up with strange results like this: falsifian moth darcs $ make test ===> Regression tests for darcs-2.16.2 cd /usr/local/ports/pobj/darcs-2.16.2/darcs-2.16.2 && /usr/bin/env -i PORTSDIR="/usr/ports" LIBTOOL="/usr/bin/libtool" PATH='/usr/local/ports/pobj/darcs-2.16.2/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11R6/bin' PREFIX='/usr/local' LOCALBASE='/usr/local' X11BASE='/usr/X11R6' CFLAGS='-O2 -pipe' TRUEPREFIX='/usr/local' DESTDIR='' HOME='/darcs-2.16.2_writes_to_HOME' PICFLAG="-fpic" BINGRP=bin BINOWN=root BINMODE=755 NONBINMODE=644 DIRMODE=755 INSTALL_COPY=-c INSTALL_STRIP=-s MANGRP=bin MANOWN=root MANMODE=644 BSD_INSTALL_PROGRAM="/usr/local/ports/pobj/darcs-2.16.2/bin/install -c -s -m 755" BSD_INSTALL_SCRIPT="/usr/local/ports/pobj/darcs-2.16.2/bin/install -c -m 755" BSD_INSTALL_DATA="/usr/local/ports/pobj/darcs-2.16.2/bin/install -c -m 644" BSD_INSTALL_MAN="/usr/local/ports/pobj/darcs-2.16.2/bin/install -c -m 644" BSD_INSTALL_PROGRAM_DIR="/usr/local/ports/pobj/darcs-2.16.2/bin/install -d -m 755" BSD_INSTALL_SCRIPT_DIR="/usr/local/ports/pobj/darcs-2.16.2/bin/install -d -m 755" BSD_INSTALL_DATA_DIR="/usr/local/ports/pobj/darcs-2.16.2/bin/install -d -m 755" BSD_INSTALL_MAN_DIR="/usr/local/ports/pobj/darcs-2.16.2/bin/install -d -m 755" HOME=/usr/local/ports/pobj/darcs-2.16.2 /usr/local/bin/cabal v2-test --offline --disable-benchmarks -w /usr/local/bin/ghc -j1 --flags="curl -library" Warning: No remote package servers have been specified. Usually you would have one specified in the config file. Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: random-1.2.0 (user goal) [__1] trying: splitmix-0.1.0.3 (user goal) [__2] trying: splitmix:!bench [__3] rejecting: splitmix:*test (cyclic dependencies; conflict set: random, splitmix) [__1] fail (backjumping, conflict set: random, splitmix) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: random, splitmix splitmix's test target depends on random and random depends on splitmix. Normally this doesn't cause any problem; I don't know why it's a problem here. * It's a pity that your approach doesn't allow Cabal-based ports to share dependencies. Some thoughts on mitigating or solving this, in decreasing order of plausability: * Is it possible to hand-pick some particularly slow ones, make packages for them, and then tell Cabal to use those packages? E.g. aeson takes a while to build. * nixpkgs (the only package system I'm really familiar with) deals with Cabal by automatically generating package descriptions for everything on hackage. I wonder if something along those lines would be do-able. I guess it would be ugly to fill the ports tree with hundreds(?) of directories each with an auto-generated package. I'm not sure if there's a way to smoosh it all into one big file. E.g. I see there's something called "multi-packages", but I'm guessing that's not designed to handle hundreds of subpackages. * Is it possible to cheat, by having all the Cabal-based ports share their Cabal directory? So if I build darcs then git-annex, Cabal has access to all the build products from
Re: Question about lang/ghc module (trying to port git-annex)
James Cook writes:
> Thanks. I split up the long command and removed quotes:
>
> https://github.com/falsifian/ports/commit/e24278e3c1d7fca1b3c4961a0e81a5bb2ca5bcf0
I pushed my update:
https://github.com/blackgnezdo/ports/commit/83db945f59633c848a9ae28627cd8e378e316a09
> Two notes:
>
> * Currently "make post-build" fails if you run it twice. Adding -p in
> "mkdir ${MAN1_STAGING_DIR}" would fix that. I don't know if it's
> better to fail or not if "make post-build" gets run more than once.
It seems unusual for `make rebuild` to fail. Your newly added action is
idempotent.
> * I see you put "@" before the ln -s lines. I wasn't sure whether to
> add them to the other commands. The output is not that interesting.
I added them to your commands as I agree the output is not interesting.
> I confirmed the port works by installing on a different machine.
Thank you for testing this!
> One hitch: I needed to manually uninstall the current cabal-install
> port because it conflicts with the new cabal port. Is there a way to
> tell ports that cabal is a successor to cabal-install?
Yes, we'll need to update the quirks package which provides transitions
for this kind of cases.
> (I considered putting the man-building commands in post-install, but I
> wasn't sure where to put the staging directory if I did that. I wanted
> the staging directory because I assumed I should use the ${INSTALL_MAN}
> macro if possible to put the files in their final place.)
I think what we have now is fine.
>> I'll dig into this a bit. I simply didn't need to worry about this up
>> until now as all the other ports don't do much custom Setup.hs work.
>
> I don't know if there will be any cases other than man pages and
> git-annex's command aliases. Not sure how much effort it's worth.
The default action of doing nothing is valid :)
Thanks
Greg
Re: Question about lang/ghc module (trying to port git-annex)
On Fri, Feb 05, 2021 at 09:57:48PM -0800, Greg Steuck wrote:
> James Cook writes:
>
> >> Would you like to try your hand in extending post-install target with
> >> some man formatting magic like we have in other ports?
> >
> > Done (commit a1c5aec8) in my "git-annex" branch:
> >
> > https://github.com/falsifian/ports/commits/git-annex
>
> Very nice!
>
> > It's not pretty. I replicated some logic from Build/Man.hs, which is
> > called from Setup.hs.
>
> Some quick observations. Makefile allows line-continuation with \ and
> this is how people write long command lines. The for loop would be more
> readable if it were split like that. I also don't see a lot of places in
> ports make files with quotes around variables. I suspect we just expect
> people to not go nuts with spaces in directory names when building
> ports.
Thanks. I split up the long command and removed quotes:
https://github.com/falsifian/ports/commit/e24278e3c1d7fca1b3c4961a0e81a5bb2ca5bcf0
Two notes:
* Currently "make post-build" fails if you run it twice. Adding -p in
"mkdir ${MAN1_STAGING_DIR}" would fix that. I don't know if it's
better to fail or not if "make post-build" gets run more than once.
* I see you put "@" before the ln -s lines. I wasn't sure whether to
add them to the other commands. The output is not that interesting.
> > Normally cabal v2-install would do that work for
> > us (putting the result in .cabal/store/ghc-XXX/git-annex-XXX) but I
> > don't know if it's worth getting that working.
> >
> > Caveat: I took a shortcut when testing this: instead of re-running
> > "make build" I just made the post-build target after adding this in.
> > I'll try building from scratch later if you don't beat me to it.
>
> I believe `make rebuild` should reuse the cabal built pieces. post-build
> seems like a reasonable place for this kind of work. Alternatively
> sticking those man-formatting commands into post-install also seems
> acceptable to me.
I confirmed the port works by installing on a different machine.
One hitch: I needed to manually uninstall the current cabal-install
port because it conflicts with the new cabal port. Is there a way to
tell ports that cabal is a successor to cabal-install?
(I considered putting the man-building commands in post-install, but I
wasn't sure where to put the staging directory if I did that. I wanted
the staging directory because I assumed I should use the ${INSTALL_MAN}
macro if possible to put the files in their final place.)
> > On that branch I also removed the runtime dep on devel/git-lfs (it's
> > just one of a large number of optional backends).
>
> Good call.
>
> >> From what I gathered the v2-install target is largely unusable for
> >> installing packages outside of .cabal tree. At least neither I nor
> >> FreeBSD maintainer found a way to leverage that. Hence the manual
> >> install flow.
> >
> > I probably don't know all the subtleties, but when I run
> > "cabal v2-install", I get a nice set of files under
> > ~/.cabal/ghc-XXX/git-annex-XXX, including the man pages and all three
> > needed binaries. I would guess that just copying those files to the
> > destination would do the trick for most cabal executable packages, but
> > I haven't actually tried it. Maybe it's better to be cautious.
>
> I'll dig into this a bit. I simply didn't need to worry about this up
> until now as all the other ports don't do much custom Setup.hs work.
I don't know if there will be any cases other than man pages and
git-annex's command aliases. Not sure how much effort it's worth.
> Thanks
> Greg
--
James
Re: Question about lang/ghc module (trying to port git-annex)
James Cook writes: >> Would you like to try your hand in extending post-install target with >> some man formatting magic like we have in other ports? > > Done (commit a1c5aec8) in my "git-annex" branch: > > https://github.com/falsifian/ports/commits/git-annex Very nice! > It's not pretty. I replicated some logic from Build/Man.hs, which is > called from Setup.hs. Some quick observations. Makefile allows line-continuation with \ and this is how people write long command lines. The for loop would be more readable if it were split like that. I also don't see a lot of places in ports make files with quotes around variables. I suspect we just expect people to not go nuts with spaces in directory names when building ports. > Normally cabal v2-install would do that work for > us (putting the result in .cabal/store/ghc-XXX/git-annex-XXX) but I > don't know if it's worth getting that working. > > Caveat: I took a shortcut when testing this: instead of re-running > "make build" I just made the post-build target after adding this in. > I'll try building from scratch later if you don't beat me to it. I believe `make rebuild` should reuse the cabal built pieces. post-build seems like a reasonable place for this kind of work. Alternatively sticking those man-formatting commands into post-install also seems acceptable to me. > On that branch I also removed the runtime dep on devel/git-lfs (it's > just one of a large number of optional backends). Good call. >> From what I gathered the v2-install target is largely unusable for >> installing packages outside of .cabal tree. At least neither I nor >> FreeBSD maintainer found a way to leverage that. Hence the manual >> install flow. > > I probably don't know all the subtleties, but when I run > "cabal v2-install", I get a nice set of files under > ~/.cabal/ghc-XXX/git-annex-XXX, including the man pages and all three > needed binaries. I would guess that just copying those files to the > destination would do the trick for most cabal executable packages, but > I haven't actually tried it. Maybe it's better to be cautious. I'll dig into this a bit. I simply didn't need to worry about this up until now as all the other ports don't do much custom Setup.hs work. Thanks Greg
Re: Question about lang/ghc module (trying to port git-annex)
> > From what I gathered the v2-install target is largely unusable for > > installing packages outside of .cabal tree. At least neither I nor > > FreeBSD maintainer found a way to leverage that. Hence the manual > > install flow. > > I probably don't know all the subtleties, but when I run > "cabal v2-install", I get a nice set of files under > ~/.cabal/ghc-XXX/git-annex-XXX, including the man pages and all three > needed binaries. I would guess that just copying those files to the > destination would do the trick for most cabal executable packages, but > I haven't actually tried it. Maybe it's better to be cautious. I mean ~/.cabal/store/ghc-XXX/git-annex-XXX. Also forgot to mention the following git-annex patch (already reported upstream) is needed if anyone does want to experiment with using cabal v2-install to get git-annex man pages. diff --git a/Build/Mans.hs b/Build/Mans.hs index 9fb29d4a3..672dcd71c 100644 --- a/Build/Mans.hs +++ b/Build/Mans.hs @@ -38,7 +38,8 @@ buildMans = do if (Just srcm > destm) then do r <- system $ unwords - [ "./Build/mdwn2man" + [ "perl" + , "Build/mdwn2man" , progName src , "1" , src
Re: Question about lang/ghc module (trying to port git-annex)
On Thu, Feb 04, 2021 at 11:13:43AM -0800, Greg Steuck wrote: > James Cook writes: > > > I don't think that's an rsync problem. Unfortunately the > > git-annex-shell binary is missing, and that's pretty critical (needed > > to access the repository from other machines; sort of like git > > push/pull). > > This part is easy, patch attached. Thanks, I can now access my git-annex repositories remotely without an awful kludge. > > Incidentally, the man pages also seem to be missing. > > Would you like to try your hand in extending post-install target with > some man formatting magic like we have in other ports? Done (commit a1c5aec8) in my "git-annex" branch: https://github.com/falsifian/ports/commits/git-annex It's not pretty. I replicated some logic from Build/Man.hs, which is called from Setup.hs. Normally cabal v2-install would do that work for us (putting the result in .cabal/store/ghc-XXX/git-annex-XXX) but I don't know if it's worth getting that working. Caveat: I took a shortcut when testing this: instead of re-running "make build" I just made the post-build target after adding this in. I'll try building from scratch later if you don't beat me to it. On that branch I also removed the runtime dep on devel/git-lfs (it's just one of a large number of optional backends). > > Alternatively, I think the cabal (v2-)install commands installs what's > > needed (at least, it gets git-annex-shell, which is the really > > important thing). Is there some way to take advantage of that in your > > cabal infrastrsucture? > > From what I gathered the v2-install target is largely unusable for > installing packages outside of .cabal tree. At least neither I nor > FreeBSD maintainer found a way to leverage that. Hence the manual > install flow. I probably don't know all the subtleties, but when I run "cabal v2-install", I get a nice set of files under ~/.cabal/ghc-XXX/git-annex-XXX, including the man pages and all three needed binaries. I would guess that just copying those files to the destination would do the trick for most cabal executable packages, but I haven't actually tried it. Maybe it's better to be cautious. -- James
Re: Question about lang/ghc module (trying to port git-annex)
James Cook writes:
> I don't think that's an rsync problem. Unfortunately the
> git-annex-shell binary is missing, and that's pretty critical (needed
> to access the repository from other machines; sort of like git
> push/pull).
This part is easy, patch attached.
> Incidentally, the man pages also seem to be missing.
Would you like to try your hand in extending post-install target with
some man formatting magic like we have in other ports?
> Alternatively, I think the cabal (v2-)install commands installs what's
> needed (at least, it gets git-annex-shell, which is the really
> important thing). Is there some way to take advantage of that in your
> cabal infrastrsucture?
>From what I gathered the v2-install target is largely unusable for
installing packages outside of .cabal tree. At least neither I nor
FreeBSD maintainer found a way to leverage that. Hence the manual
install flow.
>From f190225986ed8e355ecd0622812539f82e35ac36 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Subject: [PATCH] fixup: git-annex post-install
All 975 tests passed (977.23s)
---
devel/git-annex/Makefile | 5 +
devel/git-annex/pkg/PLIST | 2 ++
2 files changed, 7 insertions(+)
diff --git devel/git-annex/Makefile devel/git-annex/Makefile
index 63996c8f9c3..134fe5a030f 100644
--- devel/git-annex/Makefile
+++ devel/git-annex/Makefile
@@ -27,6 +27,11 @@ MAKE_ENV = LC_ALL=en_US.UTF-8
MODCABAL_STEM =git-annex
MODCABAL_VERSION = 8.20210127
+# Manual reimplementation of postCopy hook of Setup.hs
+post-install:
+ @ln -s git-annex ${PREFIX}/bin/git-annex-shell
+ @ln -s git-annex ${PREFIX}/bin/git-remote-tor-annex
+
# Produced by:
# $ cabal-bundler --openbsd git-annex-8.20210127
# Then manually remove:git-annex 8.20210127 0
diff --git devel/git-annex/pkg/PLIST devel/git-annex/pkg/PLIST
index 2a5b445b27d..d52ede016f8 100644
--- devel/git-annex/pkg/PLIST
+++ devel/git-annex/pkg/PLIST
@@ -1,2 +1,4 @@
@comment $OpenBSD: PLIST,v$
@bin bin/${MODCABAL_STEM}
+bin/${MODCABAL_STEM}-shell
+bin/git-remote-tor-annex
--
2.30.0
Re: Question about lang/ghc module (trying to port git-annex)
> > Assuming it works and that "git annex test" doesn't show any problems, > > is there anything else I can do to help with git-annex? > > The idea to link the test code into the main binary is quite > unorthodox. I can imagine some arguments for it, but I'll have to > overcome a lot of prior beliefs to accept this as a best practice. This is the only place I've seen it. Maybe the author did it this way so that users can reassure themselves that their storage backends are working (using the more specialized "git annex testremote" command). > $ touch /home/greg/.config/git-annex/program > $ git-annex test > ... > get (ssh remote): FAIL (1.20s) > ./Test/Framework.hs:57: > get of file failed (transcript follows) > get foo (from origin...) /bin/sh: git-annex-shell: not foundrsync: > connection unexpectedly closed (0 bytes received so far) [Receiver]rsync > error: error in rsync protocol data stream (code 12) at io.c(228) > [Receiver=3.2.3]rsync exited 12 rsync failed -- run git annex again to > resume file transfer transfer failed Unable to access these remotes: origin > Try making some of these remotes available: > a45e9dcd-c958-4026-96e4-a0d9a6fc322b -- test repo [origin]failedgit-annex: > get: 1 failed > ... > 6 out of 975 tests failed (1002.59s) > (Failures above could be due to a bug in git-annex, or an incompatibility >with utilities, such as git, installed on this system.) > > The failing tests are due to unconfigured rsync stuff. I don't think that's an rsync problem. Unfortunately the git-annex-shell binary is missing, and that's pretty critical (needed to access the repository from other machines; sort of like git push/pull). Incidentally, the man pages also seem to be missing. (I think git-annex tries to connect a local rsync process to a remote git-annex-shell process, which would explain why we also see an rsync error message.) I guess this could be solved with custom logic in devel/git-annex/Makefile. I can try to write some custom install commands, maybe tomorrow or Friday. (If you point me to the appropriate variable for overriding/augmenting the install script, that would help; I'm still pretty new to ports.) Alternatively, I think the cabal (v2-)install commands installs what's needed (at least, it gets git-annex-shell, which is the really important thing). Is there some way to take advantage of that in your cabal infrastrsucture? -- James
Re: Question about lang/ghc module (trying to port git-annex)
James Cook writes: > On Sun, Jan 31, 2021 at 11:58:40PM -0800, Greg Steuck wrote: > Thanks. I'm currently building it and will try it with my repos. > > In devel/cabal/Makefile would it make sense to fix the ghc version, > i.e: > > BUILD_DEPENDS +=lang/ghc=8.10.3 Good call. I was updating everything in lock-step so I never noticed. > I quickly discovered cabal won't build with 8.6.4, which is what I have > right now, because the port expects ghc-prim-0.6.1 which doesn't match. > With the above change, "make build" kicks off a build for ghc-8.10.3 > (which I'm now waiting for). It's not fast. I build with MAKE_JOBS=N to help a bit. >> I didn't bother to pare down the dependency list to exclude the test >> stuff, so MODCABAL_MANIFEST is twice the length it should be. > > Hm, I thought git-annex doesn't have test stuff. cabal v2-test doesn't > work; the way to test it is to build the binary and run git annex > test. Right, that was a mistake on my part. I later realized the list can't be shorter. I was just taken aback with the sheer mass of dependencies. > Assuming it works and that "git annex test" doesn't show any problems, > is there anything else I can do to help with git-annex? The idea to link the test code into the main binary is quite unorthodox. I can imagine some arguments for it, but I'll have to overcome a lot of prior beliefs to accept this as a best practice. $ touch /home/greg/.config/git-annex/program $ git-annex test ... get (ssh remote): FAIL (1.20s) ./Test/Framework.hs:57: get of file failed (transcript follows) get foo (from origin...) /bin/sh: git-annex-shell: not foundrsync: connection unexpectedly closed (0 bytes received so far) [Receiver]rsync error: error in rsync protocol data stream (code 12) at io.c(228) [Receiver=3.2.3]rsync exited 12 rsync failed -- run git annex again to resume file transfer transfer failed Unable to access these remotes: origin Try making some of these remotes available: a45e9dcd-c958-4026-96e4-a0d9a6fc322b -- test repo [origin]failedgit-annex: get: 1 failed ... 6 out of 975 tests failed (1002.59s) (Failures above could be due to a bug in git-annex, or an incompatibility with utilities, such as git, installed on this system.) The failing tests are due to unconfigured rsync stuff. > I use darcs a fair bit; would it help if I built it on your branch and > tested it out? Please do. You are the first person I know who still uses darcs on openbsd :) Thanks Greg
Re: Question about lang/ghc module (trying to port git-annex)
On Sun, Jan 31, 2021 at 11:58:40PM -0800, Greg Steuck wrote: > Greg Steuck writes: > > >> git-annex has at least 50 dependencies I couldn't find in ports, so I > >> want to make sure I understand this before I start porting them one at > >> a time (or just give up)... > > > > This is exactly the problem I want to solve with cabal.port.mk. You > > can try to look at > > https://marc.info/?l=openbsd-ports=160858285410366=2 > > A quick search in the archives will show the justification and the > > history of the effort. > > > > The current state of the work is I'm waiting on cabal 3.4 official > > release gated by ghc-9.0. I'm also looking for people needing this work > > and your attempt to add git-annex gives me more motivation to finish. > > FWIW, a version of git-annex port that can display its help message: > https://github.com/openbsd/ports/commit/0d970c085441b82f0080afee13e2034e47f475c0 Thanks. I'm currently building it and will try it with my repos. In devel/cabal/Makefile would it make sense to fix the ghc version, i.e: BUILD_DEPENDS += lang/ghc=8.10.3 I quickly discovered cabal won't build with 8.6.4, which is what I have right now, because the port expects ghc-prim-0.6.1 which doesn't match. With the above change, "make build" kicks off a build for ghc-8.10.3 (which I'm now waiting for). > I didn't bother to pare down the dependency list to exclude the test > stuff, so MODCABAL_MANIFEST is twice the length it should be. Hm, I thought git-annex doesn't have test stuff. cabal v2-test doesn't work; the way to test it is to build the binary and run git annex test. Assuming it works and that "git annex test" doesn't show any problems, is there anything else I can do to help with git-annex? I use darcs a fair bit; would it help if I built it on your branch and tested it out? > Thanks > Greg -- James
Re: Question about lang/ghc module (trying to port git-annex)
Greg Steuck writes: >> git-annex has at least 50 dependencies I couldn't find in ports, so I >> want to make sure I understand this before I start porting them one at >> a time (or just give up)... > > This is exactly the problem I want to solve with cabal.port.mk. You > can try to look at > https://marc.info/?l=openbsd-ports=160858285410366=2 > A quick search in the archives will show the justification and the > history of the effort. > > The current state of the work is I'm waiting on cabal 3.4 official > release gated by ghc-9.0. I'm also looking for people needing this work > and your attempt to add git-annex gives me more motivation to finish. FWIW, a version of git-annex port that can display its help message: https://github.com/openbsd/ports/commit/0d970c085441b82f0080afee13e2034e47f475c0 I didn't bother to pare down the dependency list to exclude the test stuff, so MODCABAL_MANIFEST is twice the length it should be. Thanks Greg
Re: Question about lang/ghc module (trying to port git-annex)
Hi James, James Cook writes: > I'm trying to write a port for git-annex, which is built using > Haskell's Cabal. I'm new to OpenBSD porting and don't completely > understand the lang/ghc module. > > Basic question: do all of the Haskell dependencies (from git-annex.cabal) need > to already have their own ports (like devel/hs-async, devel/hs-network, etc)? > (Or will the missing ones be magically built like cabal-install normally > does?) > If they do need to all be ported, how isn't there e.g. a devel/hs-containers > port --- doesn't basically every Haskell project depend on the containers > package? Yes, that's the way it currently is in the ports tree. > git-annex has at least 50 dependencies I couldn't find in ports, so I > want to make sure I understand this before I start porting them one at > a time (or just give up)... This is exactly the problem I want to solve with cabal.port.mk. You can try to look at https://marc.info/?l=openbsd-ports=160858285410366=2 A quick search in the archives will show the justification and the history of the effort. The current state of the work is I'm waiting on cabal 3.4 official release gated by ghc-9.0. I'm also looking for people needing this work and your attempt to add git-annex gives me more motivation to finish. BTW, trying to build with cabal also needs devel/libmagic port, or else: cabal: Missing dependency on a foreign library: * Missing (or bad) C library: magic Thanks Greg
Re: Question about lang/ghc module (trying to port git-annex)
> Here is what I have so far. P.S. to anyone trying to build git-annex, you'll need the following patch, which I didn't yet get around to adding to my WIP port: https://git-annex.branchable.com/bugs/__91__PATCH__93___OpenBSD__58___fix_Utility.DirWatcher.Kqueue/?updated#comment-0b3828545e6cf6ec417c0f82645888cb -- James
Question about lang/ghc module (trying to port git-annex)
Hi ports@, I'm trying to write a port for git-annex, which is built using Haskell's Cabal. I'm new to OpenBSD porting and don't completely understand the lang/ghc module. Basic question: do all of the Haskell dependencies (from git-annex.cabal) need to already have their own ports (like devel/hs-async, devel/hs-network, etc)? (Or will the missing ones be magically built like cabal-install normally does?) If they do need to all be ported, how isn't there e.g. a devel/hs-containers port --- doesn't basically every Haskell project depend on the containers package? git-annex has at least 50 dependencies I couldn't find in ports, so I want to make sure I understand this before I start porting them one at a time (or just give up)... Also, I'm using devel/darcs/Makefile as my model but don't understand the following comment. Should I also be listing git-annex's dependencies in BUILD_DEPENDS instead of LIB_DEPENDS? # Yes, build dependencies, because GHC libs are still static and we # don't want to pull in all of ghc. BUILD_DEPENDS = archivers/hs-zip-archive>=0.2.3,<0.4 \ archivers/hs-zlib>=0.6.1.2,<0.7.0.0 \ ... Another question: what is MODGHC_PACKAGE_KEY? ghc.port.mk describes it as the "package key" of the library, but I don't know what that means. Here is what I have so far. I only included the dependencies that are already in ports. Currently make build fails with a compiler error "Could not find module ‘System.FilePath.ByteString’", indicating that it is indeed a problem that there's no filepath-bytestring port. diff --git a/devel/git-annex/Makefile b/devel/git-annex/Makefile new file mode 100644 index 000..57ae7fe1079 --- /dev/null +++ b/devel/git-annex/Makefile @@ -0,0 +1,54 @@ +# $OpenBSD$ +# +# TODO: +# Use /usr/ports/infrastructure/bin/portcheck + +COMMENT = manage files with git without checking in file contents + +DISTNAME = git-annex-8.20210127 +CATEGORIES = devel +HOMEPAGE = https://git-annex.branchable.com/ + +MODULES = lang/ghc +MODGHC_BUILD = cabal hackage nort + +# Many licenses listed in COPYRIGHT. All permit redistribution. +PERMIT_PACKAGE = Yes + +# TODO +# "make port-lib-depends-check" can help +#WANTLIB = ??? + +# TODO +# Dependencies +#BUILD_DEPENDS = ??? +RUN_DEPENDS = net/rsync devel/git-lfs +LIB_DEPENDS = devel/hs-network-uri>=2.6 \ + devel/hs-exceptions>=0.6 \ + devel/hs-data-default \ + devel/hs-random \ + devel/hs-dlist \ + devel/hs-unix-compat \ + devel/hs-async \ + devel/hs-hslogger \ + devel/hs-utf8-string \ + devel/hs-sandi \ + devel/hs-monad-control \ + devel/hs-edit-distance \ + devel/hs-resourcet \ + devel/hs-conduit \ + devel/hs-old-locale \ + devel/hs-unliftio-core \ + devel/hs-vector \ + devel/hs-unordered-containers \ + devel/hs-regex-tdfa \ + devel/hs-byteable \ + security/hs-crypto-api \ + devel/hs-split \ + textproc/hs-attoparsec \ + devel/hs-QuickCheck +#version doesn't match +#devel/hs-network>=3.0.0.0 +TEST_DEPENDS = net/rsync + +.include diff --git a/devel/git-annex/distinfo b/devel/git-annex/distinfo new file mode 100644 index 000..9d9fa1c5788 --- /dev/null +++ b/devel/git-annex/distinfo @@ -0,0 +1,2 @@ +SHA256 (ghc/git-annex-8.20210127.tar.gz) = Y29DlCDyipKoJQufi0IlZ+Q5MV8/LSPLC+o7Cg5XVcM= +SIZE (ghc/git-annex-8.20210127.tar.gz) = 1361993
Re: lang/ghc, some failure on i386
Matthias Kilian writes: >> I guess it will probably build on a retry, but I just ran into this: > [...] >> "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register >> libraries/parsec dist-install >> "/pobj/ghc-8.6.4/bootstrap/lib/ghc/bin/ghc" >> "/pobj/ghc-8.6.4/bootstrap/lib/ghc/bin/ghc-pkg" >> "/pobj/ghc-8.6.4/bootstrap/lib/ghc" '' '/pobj/ghc-8.6.4/bootstrap' >> '/pobj/ghc-8.6.4/bootstrap/lib/ghc' >> '/pobj/ghc-8.6.4/bootstrap/share/doc/ghc/html/libraries' NO >> ghc-cabal: '/pobj/ghc-8.6.4/bootstrap/lib/ghc/bin/ghc' exited with an error: > > During my last builds on i386 (last one two days ago, with a system > from september, 30th), everything went fine, so I din't have an > idea why it failed for you. > > If it continues to fail, please let me know. This is in the bootstrap install phase, we didn't change it since 20200921. I also haven't seen this issue. If there's any chance this can be reproduced we should try to ktrace what's going on. THanks Greg
Re: lang/ghc, some failure on i386
Hi, On Fri, Oct 09, 2020 at 01:11:44PM +0100, Stuart Henderson wrote: > I guess it will probably build on a retry, but I just ran into this: [...] > "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register > libraries/parsec dist-install "/pobj/ghc-8.6.4/bootstrap/lib/ghc/bin/ghc" > "/pobj/ghc-8.6.4/bootstrap/lib/ghc/bin/ghc-pkg" > "/pobj/ghc-8.6.4/bootstrap/lib/ghc" '' '/pobj/ghc-8.6.4/bootstrap' > '/pobj/ghc-8.6.4/bootstrap/lib/ghc' > '/pobj/ghc-8.6.4/bootstrap/share/doc/ghc/html/libraries' NO > ghc-cabal: '/pobj/ghc-8.6.4/bootstrap/lib/ghc/bin/ghc' exited with an error: During my last builds on i386 (last one two days ago, with a system from september, 30th), everything went fine, so I din't have an idea why it failed for you. If it continues to fail, please let me know. Ciao, Kili
lang/ghc, some failure on i386
I guess it will probably build on a retry, but I just ran into this: >>> Building on i386-1 under lang/ghc BDEPENDS = [textproc/groff;devel/libffi;archivers/xz;textproc/py-sphinx,python3;devel/metaauto;devel/gmp;devel/autoconf/2.69;converters/libiconv;archivers/bzip2;archivers/gtar;devel/gmake] DIST = [lang/ghc:ghc/ghc-8.6.4.20200921-i386-unknown-openbsd.tar.xz;lang/ghc:ghc/ghc-8.6.4-testsuite.tar.xz;lang/ghc:ghc/ghc-8.6.4.20200921-shlibs-i386.tar.gz;lang/ghc:ghc/ghc-8.6.4-src.tar.xz] FULLPKGNAME = ghc-8.6.4p6 RDEPENDS = [converters/libiconv;devel/gmp;devel/libffi] (Junk lock obtained for i386-1 at 1602198299.73) >>> Running depends in lang/ghc at 1602198299.76 last junk was in databases/py-redis,python3 /usr/sbin/pkg_add -aI -Drepair gmp-6.2.0 groff-1.22.4p3 libffi-3.3 py3-sphinx-1.4.8p4 was: /usr/sbin/pkg_add -aI -Drepair autoconf-2.69p3 bzip2-1.0.8 gmake-4.3 gmp-6.2.0 groff-1.22.4p3 gtar-1.32p1 libffi-3.3 libiconv-1.16p0 metaauto-1.0p4 py3-sphinx-1.4.8p4 xz-5.2.5 /usr/sbin/pkg_add -aI -Drepair gmp-6.2.0 groff-1.22.4p3 libffi-3.3 py3-sphinx-1.4.8p4 New and changed readme(s): /usr/local/share/doc/pkg-readmes/groff >>> Running show-prepare-results in lang/ghc at 1602198305.66 ===> lang/ghc ===> ghc-8.6.4p6 depends on: bzip2-* -> bzip2-1.0.8 ===> ghc-8.6.4p6 depends on: gtar-* -> gtar-1.32p1 ===> ghc-8.6.4p6 depends on: py3-sphinx-* -> py3-sphinx-1.4.8p4 ===> ghc-8.6.4p6 depends on: metaauto-* -> metaauto-1.0p4 ===> ghc-8.6.4p6 depends on: autoconf-2.69 -> autoconf-2.69p3 ===> ghc-8.6.4p6 depends on: gmake-* -> gmake-4.3 ===> ghc-8.6.4p6 depends on: groff->=1.21 -> groff-1.22.4p3 ===> ghc-8.6.4p6 depends on: xz-* -> xz-5.2.5 ===> ghc-8.6.4p6 depends on: libiconv-* -> libiconv-1.16p0 ===> ghc-8.6.4p6 depends on: gmp-* -> gmp-6.2.0 ===> ghc-8.6.4p6 depends on: libffi-* -> libffi-3.3 ===> Verifying specs: c curses ffi gmp iconv m pthread util ===> found c.96.0 curses.14.0 ffi.1.2 gmp.11.0 iconv.7.0 m.10.1 pthread.26.1 util.15.0 autoconf-2.69p3 bzip2-1.0.8 gmake-4.3 gmp-6.2.0 groff-1.22.4p3 gtar-1.32p1 libffi-3.3 libiconv-1.16p0 metaauto-1.0p4 py3-sphinx-1.4.8p4 xz-5.2.5 (Junk lock released for i386-1 at 1602198306.76) distfiles size=77226138 >>> Running patch in lang/ghc at 1602198306.79 ===> lang/ghc ===> Checking files for ghc-8.6.4p6 `/mnt/distfiles/ghc/ghc-8.6.4-src.tar.xz' is up to date. `/mnt/distfiles/ghc/ghc-8.6.4-testsuite.tar.xz' is up to date. `/mnt/distfiles/ghc/ghc-8.6.4.20200921-i386-unknown-openbsd.tar.xz' is up to date. `/mnt/distfiles/ghc/ghc-8.6.4.20200921-shlibs-i386.tar.gz' is up to date. >> (SHA256) ghc/ghc-8.6.4-src.tar.xz: OK >> (SHA256) ghc/ghc-8.6.4-testsuite.tar.xz: OK >> (SHA256) ghc/ghc-8.6.4.20200921-i386-unknown-openbsd.tar.xz: OK >> (SHA256) ghc/ghc-8.6.4.20200921-shlibs-i386.tar.gz: OK ===> Extracting for ghc-8.6.4p6 cd /pobj/ghc-8.6.4/ghc-8.6.4/libraries/unix && mkdir -p System/OpenBSD && install -m 644 /usr/ports/lang/ghc/files/Process.hsc System/OpenBSD ===> Patching for ghc-8.6.4p6 ===> Applying OpenBSD patch patch-aclocal_m4 Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-aclocal_m4,v 1.3 2020/05/31 19:25:48 kili Exp $ | |Index: aclocal.m4 |--- aclocal.m4.orig |+++ aclocal.m4 -- Patching file aclocal.m4 using Plan A... Hunk #1 succeeded at 691. done ===> Applying OpenBSD patch patch-configure_ac Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-configure_ac,v 1.3 2020/05/31 19:25:48 kili Exp $ | |Index: configure.ac |--- configure.ac.orig |+++ configure.ac -- Patching file configure.ac using Plan A... Hunk #1 succeeded at 678. done ===> Applying OpenBSD patch patch-ghc_mk Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-ghc_mk,v 1.14 2019/09/30 11:44:18 kili Exp $ | |Fix the bindist-list (for building the bootstrapper); without this, |gtar creates an archive which our tar can't extract. | |Index: ghc.mk |--- ghc.mk.orig |+++ ghc.mk -- Patching file ghc.mk using Plan A... Hunk #1 succeeded at 1102. done ===> Applying OpenBSD patch patch-libraries_Cabal_Cabal_Distribution_Simple_Program_Strip_hs Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-libraries_Cabal_Cabal_Distribution_Simple_Program_Strip_hs,v 1.3 2018/01/22 00:42:30 kili Exp $ | |Work around unresolved symbols when linking against hs packages |that use FFI and contain some code compiled from C sources. | |Index: libraries/Cabal/Cabal/Distribution/Simple/Program/Strip.hs |--- libraries/Cabal/Cabal/Distribution/Simpl
Re: Include libHSrts_thr.a into lang/ghc bootstrap
Matthias Kilian writes: > On Mon, Sep 21, 2020 at 04:33:38PM +0200, Matthias Kilian wrote: >> I'll now check wether 8.6.4 still builds with the new bootstrapper. > > It does, including all ports depending on lang/ghc, on both amd64 > and i386. New bootstrap also works great for ghc-8.10.2. Thank you! https://github.com/blackgnezdo/ports/commit/06dd9bc8fae726215819e29b6ab2d720a2175457 Thanks Greg
Re: Include libHSrts_thr.a into lang/ghc bootstrap
On Mon, Sep 21, 2020 at 2:03 PM Matthias Kilian wrote: > On Mon, Sep 21, 2020 at 04:33:38PM +0200, Matthias Kilian wrote: > > I'll now check wether 8.6.4 still builds with the new bootstrapper. > > It does, including all ports depending on lang/ghc, on both amd64 > and i386. > Very cool, thanks for checking! If you want to commit this bootstrap replacement, I'm cool with it. I don't expect much risk from this change given how thoroughly you tested it. Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
Re: Include libHSrts_thr.a into lang/ghc bootstrap
On Mon, Sep 21, 2020 at 04:33:38PM +0200, Matthias Kilian wrote: > I'll now check wether 8.6.4 still builds with the new bootstrapper. It does, including all ports depending on lang/ghc, on both amd64 and i386. Ciao, Kili
Re: Include libHSrts_thr.a into lang/ghc bootstrap
Hi Greg,
On Mon, Sep 21, 2020 at 12:19:55AM -0700, Greg Steuck wrote:
> In my attempts to port ghc 8.10.2 I didn't figure out how to avoid
> requiring threaded rts for ghc bootstrap. I propose we change the
> bootstrap ghc 8.6.4 to include libHSrts_thr.a. So far I confirmed that
> applying the patch below makes libHSrts_thr.a appear in the generated
> *xz file which is then good enough to bootstrap 8.6.4. I will verify
> that I can successfully bootstrap ghc-8.10.2.
Great.
> I don't have a full update yet because I've never updated the bootstrap
> before. Matthias, do you think you can rebuild and host the new
> bootstrap packages starting from this change?
Sure. The files are at the usual plase
(https://openbsd.dead-parrot.de/distfiles/), here are the checksums:
SHA256 (ghc-8.6.4.20200921-amd64-unknown-openbsd.tar.xz) =
f8689b448404a66cdf6f60a6da5d38883a470b70303d44429ab52e5b5ada8d0e
SHA256 (ghc-8.6.4.20200921-i386-unknown-openbsd.tar.xz) =
446673ac355ce6a17a500ead016314a764fafae6aff965f0a8526219ad7f2316
SHA256 (ghc-8.6.4.20200921-shlibs-amd64.tar.gz) =
e191cd242eb322257aeb8388f2684dd465f23a852ac0b959e6563733740b1972
SHA256 (ghc-8.6.4.20200921-shlibs-i386.tar.gz) =
0315b3f91613b7a3babebc0a5ba60aaa16d7be14a662a0cf11d888af0533a52c
> diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
> index 0168e13fe4c..f5f5c53c5ae 100644
> --- a/lang/ghc/Makefile
> +++ b/lang/ghc/Makefile
> @@ -217,9 +217,9 @@ _bootstrap_prepare:
> echo GhcStage2HcOpts=-O -fasm >> ${WRKSRC}/mk/build.mk
> echo SplitObjs=NO >> ${WRKSRC}/mk/build.mk
> echo GhcLibWays=v >> ${WRKSRC}/mk/build.mk
> - echo GhcRTSWays= >> ${WRKSRC}/mk/build.mk
> + echo GhcRTSWays=thr >> ${WRKSRC}/mk/build.mk
> echo GhcWithInterpreter=NO >> ${WRKSRC}/mk/build.mk
> - echo GhcThreaded=NO >> ${WRKSRC}/mk/build.mk
> + echo GhcThreaded=YES >> ${WRKSRC}/mk/build.mk
> echo INTEGER_LIBRARY=integer-simple >> ${WRKSRC}/mk/build.mk
> echo SRC_CC_OPTS+=-g -O0 >> ${WRKSRC}/mk/build.mk
> echo HADDOCK_DOCS=NO >> ${WRKSRC}/mk/build.mk
That diff is ok, just also change BOOTSTRAP_DATE in Makefile to 20200921,
but do NOT yet touch BIN_VER. With that, ok kili@.
I'll now check wether 8.6.4 still builds with the new bootstrapper.
Ciao,
Kili
Include libHSrts_thr.a into lang/ghc bootstrap
Hi Matthias,
In my attempts to port ghc 8.10.2 I didn't figure out how to avoid
requiring threaded rts for ghc bootstrap. I propose we change the
bootstrap ghc 8.6.4 to include libHSrts_thr.a. So far I confirmed that
applying the patch below makes libHSrts_thr.a appear in the generated
*xz file which is then good enough to bootstrap 8.6.4. I will verify
that I can successfully bootstrap ghc-8.10.2.
I don't have a full update yet because I've never updated the bootstrap
before. Matthias, do you think you can rebuild and host the new
bootstrap packages starting from this change?
Thanks
Greg
diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
index 0168e13fe4c..f5f5c53c5ae 100644
--- a/lang/ghc/Makefile
+++ b/lang/ghc/Makefile
@@ -217,9 +217,9 @@ _bootstrap_prepare:
echo GhcStage2HcOpts=-O -fasm >> ${WRKSRC}/mk/build.mk
echo SplitObjs=NO >> ${WRKSRC}/mk/build.mk
echo GhcLibWays=v >> ${WRKSRC}/mk/build.mk
- echo GhcRTSWays= >> ${WRKSRC}/mk/build.mk
+ echo GhcRTSWays=thr >> ${WRKSRC}/mk/build.mk
echo GhcWithInterpreter=NO >> ${WRKSRC}/mk/build.mk
- echo GhcThreaded=NO >> ${WRKSRC}/mk/build.mk
+ echo GhcThreaded=YES >> ${WRKSRC}/mk/build.mk
echo INTEGER_LIBRARY=integer-simple >> ${WRKSRC}/mk/build.mk
echo SRC_CC_OPTS+=-g -O0 >> ${WRKSRC}/mk/build.mk
echo HADDOCK_DOCS=NO >> ${WRKSRC}/mk/build.mk
Re: lang/ghc workaround for clang 10 fallout
Thank you for validating the patch as a clean clean experiment! On Sun, Aug 2, 2020, 11:11 Matthias Kilian wrote: > Hi, > > On Sat, Aug 01, 2020 at 06:32:42PM +0200, Matthias Kilian wrote: > > > Kili, do you feel there's a risk that this might break on i386? > > > > I'll apply Patricks diff (llvm.v1.full.diff) and your diff on i386 > > and give it a try (and your diff for ghc, of course). Results > > hopefully tomorrow. > > Of course, only after starting the test build, I noticed that the > diff was already committed ;-) > > Anyway -- no fallout on i386 building ghc and all hs-ports. > > Ciao, > Kili >
Re: lang/ghc workaround for clang 10 fallout
Hi, On Sat, Aug 01, 2020 at 06:32:42PM +0200, Matthias Kilian wrote: > > Kili, do you feel there's a risk that this might break on i386? > > I'll apply Patricks diff (llvm.v1.full.diff) and your diff on i386 > and give it a try (and your diff for ghc, of course). Results > hopefully tomorrow. Of course, only after starting the test build, I noticed that the diff was already committed ;-) Anyway -- no fallout on i386 building ghc and all hs-ports. Ciao, Kili
Re: lang/ghc workaround for clang 10 fallout
Hi, On Fri, Jul 31, 2020 at 10:07:05PM -0700, Greg Steuck wrote: [...] > I have more confidence in this patch as I built the port and then used > it to build xmonad. > Anybody with clang 10 willing to give the a go and OK? > > Kili, do you feel there's a risk that this might break on i386? I'll apply Patricks diff (llvm.v1.full.diff) and your diff on i386 and give it a try (and your diff for ghc, of course). Results hopefully tomorrow. Ciao, Kili
Re: lang/ghc workaround for clang 10 fallout
> I only tested the attached up to `make patch`. I have a build running > on amd64-current. It shows the export-dynamic token has disappeared > from the build log so far. While the patch is not known to have fixed > the problem with clang 10, it looks promising. I have more confidence in this patch as I built the port and then used it to build xmonad. Anybody with clang 10 willing to give the a go and OK? Kili, do you feel there's a risk that this might break on i386? Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
lang/ghc workaround for clang 10 fallout
I only tested the attached up to `make patch`. I have a build running
on amd64-current. It shows the export-dynamic token has disappeared
from the build log so far. While the patch is not known to have fixed
the problem with clang 10, it looks promising.
Thanks
Greg
P.S. Also in cvs:~gnezdo/lang-ghc-clang10.patch
--
nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
lang/ghc workaround for clang 10 fallout
Adapted from https://gitlab.haskell.org/ghc/ghc/-/issues/17962
--
diff --git lang/ghc/Makefile lang/ghc/Makefile
index e520c1d7bd5..05d364eec53 100644
--- lang/ghc/Makefile
+++ lang/ghc/Makefile
@@ -12,7 +12,7 @@ COMMENT = compiler for the functional language Haskell
NO_CCACHE = Yes
DISTNAME = ghc-${MODGHC_VER}
-REVISION = 4
+REVISION = 5
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
diff --git lang/ghc/patches/patch-utils_iserv_ghc_mk lang/ghc/patches/patch-utils_iserv_ghc_mk
new file mode 100644
index 000..a5ab9a2a46a
--- /dev/null
+++ lang/ghc/patches/patch-utils_iserv_ghc_mk
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Work around https://gitlab.haskell.org/ghc/ghc/-/issues/17962
+
+Index: utils/iserv/ghc.mk
+--- utils/iserv/ghc.mk.orig
utils/iserv/ghc.mk
+@@ -30,8 +30,9 @@ endif
+ # refer to the RTS. This is harmless if you don't use it (adds a bit
+ # of overhead to startup and increases the binary sizes) but if you
+ # need it there's no alternative.
++# Don't do this on systems known to use clang 10 to work around #17962.
+ ifeq "$(TargetElf)" "YES"
+-ifneq "$(TargetOS_CPP)" "solaris2"
++ifeq "$(findstring $(TargetOS_CPP), freebsd openbsd solaris2)" ""
+ # The Solaris linker does not support --export-dynamic option. It also
+ # does not need it since it exports all dynamic symbols by default
+ utils/iserv_stage2_MORE_HC_OPTS += -optl-Wl,--export-dynamic
Re: lang/ghc: more cleanups
On Fri, May 29, 2020 at 5:22 PM Matthias Kilian wrote: > this is mainly for getting rid of overriding things via CONFIGURE_ENV > and CFLAGS in favor of patching aclocal.m4 and configure.ac (and > running autoconf), which may help getting this merged upstream. > > It also kills some left-over -fno-pie which came from > patches/patch-configure. > > I decided to drop the clang-specific > > -Wno-unused-command-line-argument -Wno-expansion-to-defined > > for now, because the warnings, although a little bit annoying, are > harmless, and because this should be fixed elsewhere -- it's not > specific to OpenBSD. > > Tested on amd64 *and* i386 this time, by building all the hs ports > and also by giving ghci a quick try. > > Does this make sense? LGTM Tested on amd64 by rebuilding xmonad with its dependencies (using cabal). Thanks Greg
lang/ghc: more cleanups
Hi,
this is mainly for getting rid of overriding things via CONFIGURE_ENV
and CFLAGS in favor of patching aclocal.m4 and configure.ac (and
running autoconf), which may help getting this merged upstream.
It also kills some left-over -fno-pie which came from
patches/patch-configure.
I decided to drop the clang-specific
-Wno-unused-command-line-argument -Wno-expansion-to-defined
for now, because the warnings, although a little bit annoying, are
harmless, and because this should be fixed elsewhere -- it's not
specific to OpenBSD.
Tested on amd64 *and* i386 this time, by building all the hs ports
and also by giving ghci a quick try.
Does this make sense?
Ciao,
Kili
Index: Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.173
diff -u -p -r1.173 Makefile
--- Makefile17 May 2020 18:06:07 - 1.173
+++ Makefile29 May 2020 21:40:37 -
@@ -12,7 +12,7 @@ COMMENT = compiler for the functional l
NO_CCACHE =Yes
DISTNAME = ghc-${MODGHC_VER}
-REVISION = 3
+REVISION = 4
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
@@ -43,7 +43,7 @@ BUILD_DEPENDS = archivers/bzip2 \
textproc/py-sphinx${MODPY_FLAVOR}
RUN_DEPENDS =
-# GHC build uses -Wl,-z,wxneeded on OpenBSD for amd64.
+# GHC build uses -Wl,-z,wxneeded on OpenBSD.
# XXX: wxneeded is a hack. Fix rts/Linker.c, mmapForLinker() and
# loadObj_() instead.
USE_WXNEEDED = special
@@ -106,14 +106,8 @@ SUBST_VARS += ${_i}_VER
USE_GMAKE =Yes
USE_GROFF =Yes
-.if ${MACHINE_ARCH} == "i386"
-CFLAGS += -Wl,-znotext
-# On i386, we still have to explicitely set -Wl,-z,wxneeded (in
-# addition to -Wl,-znotext).
-GHC_CC_OPTS = -Wl,-znotext -Wl,-z,wxneeded
-.endif
-
-CONFIGURE_STYLE = gnu
+AUTOCONF_VERSION = 2.69
+CONFIGURE_STYLE = gnu autoconf no-autoheader
CONFIGURE_ARGS += --with-ffi-includes=${LOCALBASE}/include \
--with-ffi-libraries=${LOCALBASE}/lib \
--with-gmp-includes=${LOCALBASE}/include \
@@ -127,13 +121,6 @@ CONFIGURE_ARGS += --with-ffi-includes=${
# with /usr/bin/ld.lld: error: cannot preempt symbol: memcpy
CONFIGURE_ARGS += --disable-ld-override
-CONFIGURE_ENV += CONF_CC_OPTS_STAGE0="${GHC_CC_OPTS}" \
- CONF_CC_OPTS_STAGE1="${GHC_CC_OPTS}" \
- CONF_CC_OPTS_STAGE2="${GHC_CC_OPTS}" \
- CONF_GCC_LINKER_OPTS_STAGE0="${GHC_CC_OPTS}" \
- CONF_GCC_LINKER_OPTS_STAGE1="${GHC_CC_OPTS}" \
- CONF_GCC_LINKER_OPTS_STAGE2="${GHC_CC_OPTS}"
-
CONFIGURE_ENV +=
SPHINXBUILD=${LOCALBASE}/bin/sphinx-build${MODPY_BIN_SUFFIX}
# Do not pick up gpatch
@@ -170,6 +157,11 @@ post-patch:
LD_LIBRARY_PATH=${BOOTSTRAP_SHLIBS} \
${MAKE_PROGRAM} install
rm -rf ${WRKDIR}/ghc-${BIN_VER}
+ # HACK for i386 until we have new bootstrappers. This is needed
+ # to let the bootstrapper use -Wl,-znotext building things like
+ # utils/hsc2hs.
+ sed -ie '/"C compiler flags"/s/-U__i686/-Wl,-znotext &/' \
+ ${WRKDIR}/bootstrap/lib/ghc/settings
# - Create some wrapper scripts setting LD_LIBRARY_PATH
cd ${WRKDIR}/bin && \
for f in $$(ls ../bootstrap/bin); do \
@@ -248,12 +240,3 @@ _bootstrap_finish:
pax -wzf ghc-${MODGHC_VER}.${BOOTSTRAP_DATE}-shlibs-$$(arch
-s){.tar.gz,}
.include
-
-# Silence clang when used by ghc to process assembler files and gets
-# flags chat don't make sense for assembly mode. Also, silence warnings
-# about macro expansions producing 'defined' (occuring in
-# includes/rts/storage/ClosureMacros.h, which has already been fixed
-# upstream)
-.if ${PROPERTIES:Mclang}
-GHC_CC_OPTS += -Wno-unused-command-line-argument -Wno-expansion-to-defined
-.endif
Index: patches/patch-aclocal_m4
===
RCS file: patches/patch-aclocal_m4
diff -N patches/patch-aclocal_m4
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-aclocal_m429 May 2020 21:40:37 -
@@ -0,0 +1,19 @@
+$OpenBSD$
+
+Index: aclocal.m4
+--- aclocal.m4.orig
aclocal.m4
+@@ -691,6 +691,13 @@ AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS],
+ $4="$$4 -z wxneeded"
+ ;;
+
++i386-*-openbsd*)
++# On i386, we also need -z notext in addition to -z wxneeded.
++$2="$$2 -Wl,-z,notext"
++$3="$$3 -Wl,-z,wxneeded -Wl,-z,notext"
++$4="$$4 -z wxneeded -z notext"
++;;
++
+ esac
+
+ # If gcc knows about the stack protector, turn it off.
Index: patches/patch-configure
=
Re: [PATCH] lang/ghc cleanup (after ports unfreeze)
Hi Greg, On Sun, May 10, 2020 at 10:05:10PM -0700, Greg Steuck wrote: > I cleaned up lang/ghc a bit over the last couple of weekends. > I tested by rebuilding a few ports (deps of hs-xmonad-contrib). I also > ran ghci manually (which works normally from a wxallowed fs). Also I > can see the ELF marker: > > % objdump -p -j .note.openbsd.ident /usr/local/lib/ghc/bin/ghc | grep > -i WXNEEDED > OPENBSD_WXNEEDED off0x vaddr 0x > paddr 0x align 2**3 Thanks. I'm currently rebuilding ghc and all ports depending on it with your diff. [...] > -REVISION = 2 > +REVISION = 4 That should be 3, not 4. When my build is done, I'll commit with 3, so you may get a conflict on your side when updating. Ciao, Kili
[PATCH] lang/ghc cleanup (after ports unfreeze)
Hi Matthias,
I cleaned up lang/ghc a bit over the last couple of weekends.
I tested by rebuilding a few ports (deps of hs-xmonad-contrib). I also
ran ghci manually (which works normally from a wxallowed fs). Also I
can see the ELF marker:
% objdump -p -j .note.openbsd.ident /usr/local/lib/ghc/bin/ghc | grep
-i WXNEEDED
OPENBSD_WXNEEDED off0x vaddr 0x
paddr 0x align 2**3
Thanks
Greg
--
nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
From dd5d488f4064fc76ac41d5b08725177afab21769 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 5 Apr 2020 14:56:42 -0700
Subject: [PATCH] lang/ghc cleanup
Remove -no-pie from GHC_CC_OPTS. Nothing breaks for 8.6.4 and ghc
8.10.1 port starts working.
Remove ffi related patch: since we use system libffi the patch is
irrelevant.
Remove explicit wxneeded: GHC already sets wxneeded on OpenBSD:
https://github.com/ghc/ghc/blob/ghc-8.6/aclocal.m4#L715-L720
Bump REVISION
---
lang/ghc/Makefile | 16 ++--
lang/ghc/patches/patch-rts_ghc_mk | 19 ---
2 files changed, 6 insertions(+), 29 deletions(-)
delete mode 100644 lang/ghc/patches/patch-rts_ghc_mk
diff --git lang/ghc/Makefile lang/ghc/Makefile
index e77b92e87e8..0656aa1a446 100644
--- lang/ghc/Makefile
+++ lang/ghc/Makefile
@@ -12,7 +12,7 @@ COMMENT = compiler for the functional language Haskell
NO_CCACHE = Yes
DISTNAME = ghc-${MODGHC_VER}
-REVISION = 2
+REVISION = 4
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
@@ -43,12 +43,11 @@ BUILD_DEPENDS = archivers/bzip2 \
textproc/py-sphinx${MODPY_FLAVOR}
RUN_DEPENDS =
-# We can't use the wrapper script, because it then gets hardcoded into
-# the packaged ghc. So we explicitly use -Wl,-z,wxneeded (see
-# CONFIGURE_ENV below)
+# GHC build uses -Wl,-z,wxneeded on OpenBSD.
+# XXX: wxneeded is a hack. Fix rts/Linker.c, mmapForLinker() and
+# loadObj_() instead.
USE_WXNEEDED = special
-
MASTER_SITES = ${HOMEPAGE}dist/${MODGHC_VER}/ \
${HOMEPAGE}dist/stable/dist/
MASTER_SITES0 = https://openbsd.dead-parrot.de/distfiles/
@@ -125,15 +124,12 @@ CONFIGURE_ARGS += --with-ffi-includes=${LOCALBASE}/include \
# with /usr/bin/ld.lld: error: cannot preempt symbol: memcpy
CONFIGURE_ARGS += --disable-ld-override
-# XXX: wxneeded is a hack. Fix rts/Linker.c, mmapForLinker() and
-# loadObj_() instead.
-GHC_CC_OPTS = -fno-pie -nopie
CONFIGURE_ENV += CONF_CC_OPTS_STAGE0="${GHC_CC_OPTS}" \
CONF_CC_OPTS_STAGE1="${GHC_CC_OPTS}" \
CONF_CC_OPTS_STAGE2="${GHC_CC_OPTS}" \
CONF_GCC_LINKER_OPTS_STAGE0="${GHC_CC_OPTS}" \
- CONF_GCC_LINKER_OPTS_STAGE1="${GHC_CC_OPTS} -Wl,-z,wxneeded" \
- CONF_GCC_LINKER_OPTS_STAGE2="${GHC_CC_OPTS} -Wl,-z,wxneeded"
+ CONF_GCC_LINKER_OPTS_STAGE1="${GHC_CC_OPTS}" \
+ CONF_GCC_LINKER_OPTS_STAGE2="${GHC_CC_OPTS}"
CONFIGURE_ENV += SPHINXBUILD=${LOCALBASE}/bin/sphinx-build${MODPY_BIN_SUFFIX}
diff --git lang/ghc/patches/patch-rts_ghc_mk lang/ghc/patches/patch-rts_ghc_mk
deleted file mode 100644
index 0b711c79e1d..000
--- lang/ghc/patches/patch-rts_ghc_mk
+++ /dev/null
@@ -1,19 +0,0 @@
-$OpenBSD: patch-rts_ghc_mk,v 1.1 2019/09/30 11:44:18 kili Exp $
-
-libffi build process seems to be using bundled libtool which only
-produces the .so.8.0 and not a plain .so which is expected to exist.
-The patch forces the dependency on versioned file at the expense of
-hardcoding the version number.
-
-Index: rts/ghc.mk
rts/ghc.mk.orig
-+++ rts/ghc.mk
-@@ -126,7 +126,7 @@ rts/dist/build/$(LIBFFI_DLL): libffi/build/inst/bin/$(
- else
- # This is a little hacky. We don't know the SO version, so we only
- # depend on libffi.so, but copy libffi.so*
--rts/dist/build/lib$(LIBFFI_NAME)$(soext): libffi/build/inst/lib/lib$(LIBFFI_NAME)$(soext)
-+rts/dist/build/lib$(LIBFFI_NAME)$(soext): libffi/build/inst/lib/lib$(LIBFFI_NAME)$(soext).8.0
- cp libffi/build/inst/lib/lib$(LIBFFI_NAME)$(soext)* rts/dist/build
- ifeq "$(TargetOS_CPP)" "darwin"
- install_name_tool -id @rpath/lib$(LIBFFI_NAME)$(soext) rts/dist/build/lib$(LIBFFI_NAME)$(soext)
--
2.26.2
Re: lang/ghc: Use py3 sphinx, sync PLIST
On Sun, Apr 05, 2020 at 08:30:56AM -0700, Greg Steuck wrote:
> I'm not positive that I got py3 stuff exactly right, but at least configure
> goes through fine unlike what happened before:
> https://github.com/blackgnezdo/ports/issues/6
Your Makefile diff looks good, although MODPY_BIN_SUFFIX should be used.
Since the lang/python module version is already set to 3, switching
sphinx is only consequent - we should not require both versions.
Although configure prints a syntax error
checking for sphinx-build... /usr/local/bin/sphinx-build-3
checking for version of sphinx-build... Sphinx (sphinx-build) 1.4.8
./configure[11244]: Sphinx (sphinx-build) 1: unexpected `('
the patch should not be necessary since we pass it explicitly and as per
the configure check, it also detects the sphinx-build version correctly.
Afterall, configure is happy without the diff:
--
Configure completed successfully.
...
sphinx-build : /usr/local/bin/sphinx-build-3
...
Tools to build Sphinx HTML documentation available: YES
Tools to build Sphinx PDF documentation available: NO
ghc configures fine for me without Python 2 installed, build is still
running.
OK kn with the two above mentioned things, see the diff below which does
that for your convenience.
Index: Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.170
diff -u -p -r1.170 Makefile
--- Makefile19 Mar 2020 21:32:58 - 1.170
+++ Makefile28 Apr 2020 20:21:31 -
@@ -12,7 +12,7 @@ COMMENT = compiler for the functional l
NO_CCACHE =Yes
DISTNAME = ghc-${MODGHC_VER}
-REVISION = 1
+REVISION = 2
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
@@ -40,7 +40,7 @@ LIB_DEPENDS = converters/libiconv \
BUILD_DEPENDS =archivers/bzip2 \
archivers/gtar \
- textproc/py-sphinx
+ textproc/py-sphinx${MODPY_FLAVOR}
RUN_DEPENDS =
# We can't use the wrapper script, because it then gets hardcoded into
@@ -134,6 +134,8 @@ CONFIGURE_ENV +=CONF_CC_OPTS_STAGE0="${
CONF_GCC_LINKER_OPTS_STAGE0="${GHC_CC_OPTS}" \
CONF_GCC_LINKER_OPTS_STAGE1="${GHC_CC_OPTS}
-Wl,-z,wxneeded" \
CONF_GCC_LINKER_OPTS_STAGE2="${GHC_CC_OPTS}
-Wl,-z,wxneeded"
+
+CONFIGURE_ENV +=
SPHINXBUILD=${LOCALBASE}/bin/sphinx-build${MODPY_BIN_SUFFIX}
# Do not pick up gpatch
CONFIGURE_ENV += ac_cv_path_PatchCmd=/usr/bin/patch
Index: pkg/PLIST
=======
RCS file: /cvs/ports/lang/ghc/pkg/PLIST,v
retrieving revision 1.13
diff -u -p -r1.13 PLIST
--- pkg/PLIST 30 Sep 2019 11:44:18 - 1.13
+++ pkg/PLIST 28 Apr 2020 20:17:01 -
@@ -738,9 +738,9 @@ lib/ghc/Cabal-${CABAL_VER}/Language/Hask
lib/ghc/Cabal-${CABAL_VER}/Paths_Cabal.dyn_hi
lib/ghc/Cabal-${CABAL_VER}/Paths_Cabal.hi
lib/ghc/Cabal-${CABAL_VER}/Paths_Cabal.p_hi
-lib/ghc/Cabal-${CABAL_VER}/libHSCabal-${CABAL_VER}-ghc${GHC_VER}.so
-lib/ghc/Cabal-${CABAL_VER}/libHSCabal-${CABAL_VER}.a
-lib/ghc/Cabal-${CABAL_VER}/libHSCabal-${CABAL_VER}_p.a
+@so lib/ghc/Cabal-${CABAL_VER}/libHSCabal-${CABAL_VER}-ghc${GHC_VER}.so
+@static-lib lib/ghc/Cabal-${CABAL_VER}/libHSCabal-${CABAL_VER}.a
+@static-lib lib/ghc/Cabal-${CABAL_VER}/libHSCabal-${CABAL_VER}_p.a
lib/ghc/array-${ARRAY_VER}/
lib/ghc/array-${ARRAY_VER}/Data/
lib/ghc/array-${ARRAY_VER}/Data/Array/
@@ -794,9 +794,9 @@ lib/ghc/array-${ARRAY_VER}/Data/Array/Un
lib/ghc/array-${ARRAY_VER}/Data/Array/Unsafe.hi
lib/ghc/array-${ARRAY_VER}/Data/Array/Unsafe.p_hi
lib/ghc/array-${ARRAY_VER}/HSarray-${ARRAY_VER}.o
-lib/ghc/array-${ARRAY_VER}/libHSarray-${ARRAY_VER}-ghc${GHC_VER}.so
-lib/ghc/array-${ARRAY_VER}/libHSarray-${ARRAY_VER}.a
-lib/ghc/array-${ARRAY_VER}/libHSarray-${ARRAY_VER}_p.a
+@so lib/ghc/array-${ARRAY_VER}/libHSarray-${ARRAY_VER}-ghc${GHC_VER}.so
+@static-lib lib/ghc/array-${ARRAY_VER}/libHSarray-${ARRAY_VER}.a
+@static-lib lib/ghc/array-${ARRAY_VER}/libHSarray-${ARRAY_VER}_p.a
lib/ghc/base-${BASE_VER}/
lib/ghc/base-${BASE_VER}/Control/
lib/ghc/base-${BASE_VER}/Control/Applicative.dyn_hi
@@ -1564,9 +1564,9 @@ lib/ghc/base-${BASE_VER}/include/HsBase.
lib/ghc/base-${BASE_VER}/include/HsBaseConfig.h
lib/ghc/base-${BASE_VER}/include/WCsubst.h
lib/ghc/base-${BASE_VER}/include/consUtils.h
-lib/ghc/base-${BASE_VER}/libHSbase-${BASE_VER}-ghc${GHC_VER}.so
-lib/ghc/base-${BASE_VER}/libHSbase-${BASE_VER}.a
-lib/ghc/base-${BASE_VER}/libHSbase-${BASE_VER}_p.a
+@so lib/ghc/base-${BASE_VER}/libHSbase-${BASE_VER}-ghc${GHC_VER}.so
+@static-lib lib/ghc/base-${BASE_VER}/libHS
Update lang/ghc: Remove -no-pie from GHC_CC_OPTS
Hi Matthias,
As promised, the second piece of the 8.10.1-provoked changes
applicable to 8.6.4.
I tested on amd64-current by rebuilding a few packages (the deps of
hs-xmonad-contrib).
Thanks
Greg
--
nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
From ce549a87690a9308af788ea08d3148a6442e3ec7 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 5 Apr 2020 14:56:42 -0700
Subject: [PATCH 2/2] Remove -no-pie from GHC_CC_OPTS.
---
lang/ghc/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git lang/ghc/Makefile lang/ghc/Makefile
index 22c007f734e..b3f4db5f174 100644
--- lang/ghc/Makefile
+++ lang/ghc/Makefile
@@ -12,7 +12,7 @@ COMMENT = compiler for the functional language Haskell
NO_CCACHE = Yes
DISTNAME = ghc-${MODGHC_VER}
-REVISION = 2
+REVISION = 3
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
@@ -127,7 +127,6 @@ CONFIGURE_ARGS += --disable-ld-override
# XXX: wxneeded is a hack. Fix rts/Linker.c, mmapForLinker() and
# loadObj_() instead.
-GHC_CC_OPTS = -fno-pie -nopie
CONFIGURE_ENV += CONF_CC_OPTS_STAGE0="${GHC_CC_OPTS}" \
CONF_CC_OPTS_STAGE1="${GHC_CC_OPTS}" \
CONF_CC_OPTS_STAGE2="${GHC_CC_OPTS}" \
--
2.26.0
lang/ghc: Use py3 sphinx, sync PLIST
Hi Matthias, I'm not positive that I got py3 stuff exactly right, but at least configure goes through fine unlike what happened before: https://github.com/blackgnezdo/ports/issues/6 Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0 0001-Use-py3-sphinx-sync-PLIST.patch.gz Description: application/gzip
Re: lang/ghc fixups
Hi Greg, On Sun, Mar 08, 2020 at 10:25:15PM -0700, Greg Steuck wrote: > I made a couple of simplifications that pass lang/ghc build and the > resulting ghc package works for building a subset of Haskell packages (e.g. > xmonad, xmobar). I only tested on amd64. > > * Remove unneeded patch-libffi_ghc_mk > * Use ghc 8.6 for bootstrap, cut gcc dependency Really cool, thanks! I'll check this against all hs-ports on amd64 and a build of ghc and some hs-ports on i386 before committing this. (May take a day or two, because I'm still waiting for my poppler test builds). Ciao, Kili
lang/ghc fixups
Hi Matthias,
I made a couple of simplifications that pass lang/ghc build and the
resulting ghc package works for building a subset of Haskell packages (e.g.
xmonad, xmobar). I only tested on amd64.
* Remove unneeded patch-libffi_ghc_mk
* Use ghc 8.6 for bootstrap, cut gcc dependency
Thanks
Greg
--
nest.cx is Gmail hosted, use PGP:
https://pgp.key-server.io/0x0B1542BD8DF5A1B0
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
From 5af03d55127188f0427f23781b08559e489d6ab8 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 8 Mar 2020 17:08:16 -0700
Subject: [PATCH 1/2] Remove unneeded patch-libffi_ghc_mk
---
lang/ghc/Makefile| 2 +-
lang/ghc/patches/patch-libffi_ghc_mk | 17 -
2 files changed, 1 insertion(+), 18 deletions(-)
delete mode 100644 lang/ghc/patches/patch-libffi_ghc_mk
diff --git lang/ghc/Makefile lang/ghc/Makefile
index 7a10d6d569a..b6ef0e463c7 100644
--- lang/ghc/Makefile
+++ lang/ghc/Makefile
@@ -12,7 +12,7 @@ COMMENT = compiler for the functional language Haskell
NO_CCACHE = Yes
DISTNAME = ghc-${MODGHC_VER}
-REVISION = 0
+REVISION = 1
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
diff --git lang/ghc/patches/patch-libffi_ghc_mk lang/ghc/patches/patch-libffi_ghc_mk
deleted file mode 100644
index 73a1655df20..000
--- lang/ghc/patches/patch-libffi_ghc_mk
+++ /dev/null
@@ -1,17 +0,0 @@
-$OpenBSD: patch-libffi_ghc_mk,v 1.6 2017/11/07 02:58:34 kili Exp $
-
-Unbreak the build on OpenBSD/amd64: undefined references to
-'ffi_call_unix64', 'ffi_closure_unix64'
-
-gcc supports @unwind sections while ld (binutils 2.15) does not
-
libffi/ghc.mk.orig Mon May 16 19:08:53 2016
-+++ libffi/ghc.mk Wed Nov 2 11:07:58 2016
-@@ -96,6 +96,7 @@ $(libffi_STAMP_CONFIGURE): $(TOUCH_DEP)
- RANLIB=$(REAL_RANLIB_CMD) \
- CFLAGS="$(SRC_CC_OPTS) $(CONF_CC_OPTS_STAGE1) -w" \
- LDFLAGS="$(SRC_LD_OPTS) -w" \
-+libffi_cv_as_x86_64_unwind_section_type=no \
- "$(SHELL)" ./configure \
- --prefix=$(TOP)/libffi/build/inst \
- --libdir=$(TOP)/libffi/build/inst/lib \
--
2.25.1
From e0c681fd62e248f9eb64348c00cfb3038f77a8a9 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 8 Mar 2020 21:59:07 -0700
Subject: [PATCH 2/2] Use ghc 8.6 for bootstrap, cut gcc dependency
---
lang/ghc/Makefile | 12 +++-
lang/ghc/distinfo | 16
2 files changed, 11 insertions(+), 17 deletions(-)
diff --git lang/ghc/Makefile lang/ghc/Makefile
index b6ef0e463c7..59578fd4c46 100644
--- lang/ghc/Makefile
+++ lang/ghc/Makefile
@@ -12,12 +12,12 @@ COMMENT = compiler for the functional language Haskell
NO_CCACHE = Yes
DISTNAME = ghc-${MODGHC_VER}
-REVISION = 1
+REVISION = 2
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
# Version of the precompiled binaries
-BIN_VER = 8.4.2.20190113
+BIN_VER = 8.6.4.20200103
# Pull in lang/ghc to get MODGHC_VER and ONLY_FOR_ARCHS, which is maintained
# in ghc.port.mk. lang/python needed for regression tests.
@@ -43,11 +43,6 @@ BUILD_DEPENDS = archivers/bzip2 \
textproc/py-sphinx
RUN_DEPENDS =
-# The bootstrapping compiler needs gcc, but the new ghc can be built
-# with clang. So we just BUILD_DEPEND on gcc instead of using the gcc
-# MODULE, because the latter would also add some wrapper scripts
-BUILD_DEPENDS += lang/gcc/8>=8,<9
-
# We can't use the wrapper script, because it then gets hardcoded into
# the packaged ghc. So we explicitly use -Wl,-z,wxneeded (see
# CONFIGURE_ENV below)
@@ -170,8 +165,7 @@ post-patch:
cd ${WRKDIR}/ghc-${BIN_VER} && \
LD_LIBRARY_PATH=${BOOTSTRAP_SHLIBS} \
CONFIGURE_ENV=${CONFIGURE_ENV} \
- ./configure --prefix=${WRKDIR}/bootstrap \
- CC=${LOCALBASE}/bin/egcc && \
+ ./configure --prefix=${WRKDIR}/bootstrap CC="${CC}" && \
LD_LIBRARY_PATH=${BOOTSTRAP_SHLIBS} \
${MAKE_PROGRAM} install
rm -rf ${WRKDIR}/ghc-${BIN_VER}
diff --git lang/ghc/distinfo lang/ghc/distinfo
index 953ef0bec1b..a76f191c9b0 100644
--- lang/ghc/distinfo
+++ lang/ghc/distinfo
@@ -1,12 +1,12 @@
-SHA256 (ghc/ghc-8.4.2.20190113-amd64-unknown-openbsd.tar.xz) = mgX+n73l3DcSbSztQDuoLbg7SFNE0thfeyZnoXkP+aA=
-SHA256 (ghc/ghc-8.4.2.20190113-i386-unknown-openbsd.tar.xz) = Lunq6hJN267fQBn8xO91ECDdGDChzF02RLhw/Q2CIwY=
-SHA256 (ghc/ghc-8.4.2.20190113-shlibs-amd64.tar.gz) = fPgINvftpK632NOGqBuQ4Z7G730YRoq99aOaZrQGqAQ=
-SHA256 (ghc/ghc-8.4.2.20190113-shlibs-i386.tar.gz) = vMf8iRC17T9fZx5jcGwX/Y/5CHfQ/BFGq7QMKoyzqNg=
SHA256 (ghc/ghc-8.6.4-src.tar.xz) = W10H5EYyA6Qzw+099GG6bM4RttK5smTbMfNCkHXQMDo=
SHA256 (ghc/ghc-8.6.4-testsuite.tar.xz) = 6gLWerJMD10UfXSW4nuQQ+NlnUkd79LR4cewJo/q6/k=
-SIZE (ghc/ghc-8.4.2.20190113-amd64-unknown-openbsd.tar.xz) = 54549160
-SIZE (ghc/ghc-8.4.2.20190113-i386-unknown-openbsd.tar.xz) = 51355360
-SIZE (ghc/ghc-8.4.2.20190113-shlibs-amd64.tar.gz) = 2911998
-SIZE (ghc/ghc-8.4.2.20190113-shlib
Re: lang/ghc leaves package.cache.lock behind
Hi, On Thu, Sep 19, 2019 at 10:54:46AM -0700, Greg Steuck wrote: [...] > $ doas pkg_delete ghc > > ghc-8.2.2p5: ok [...] > Error deleting directory /usr/local/lib/ghc/package.conf.d: Directory not > empty > Error deleting directory /usr/local/lib/ghc: Directory not empty > $ ls -l /usr/local/lib/ghc/package.conf.d/ > total 0 > -rw-r--r-- 1 root wheel 0 Sep 18 09:49 package.cache.lock Yes, my fault (made on ghc-8.2, IIRC). Annoying but mostly harmless. I tried to drop the @comment on package.cache.lock when switching to @define-tag/@tag, but this lead to another conflict during update, so it will need another quirk for ghc, but I don;t think it's urgent. Ciao, Kili
lang/ghc leaves package.cache.lock behind
Hi Matthias, There seems to be a minor nit with lang/ghc uninstall: $ doas env PKG_PATH= https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ pkg_add ghc quirks-3.180 signed on 2019-09-19T12:12:14Z ghc-8.2.2p5: ok Running tags: ok $ doas pkg_delete ghc ghc-8.2.2p5: ok Running tags: ok Read shared items: ok --- -ghc-8.2.2p5 --- Error deleting directory /usr/local/lib/ghc/package.conf.d: Directory not empty Error deleting directory /usr/local/lib/ghc: Directory not empty $ ls -l /usr/local/lib/ghc/package.conf.d/ total 0 -rw-r--r-- 1 root wheel 0 Sep 18 09:49 package.cache.lock $ Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
Re: switch lang/ghc to @define-tag/@tag
Hi, On Sat, Sep 07, 2019 at 08:55:23PM -0700, Greg Steuck wrote: > On Fri, 2019-08-23 23:31:20 Marc Espie wrote: > >> I'm not sure about wether it's worth to try to avoid the collisions (I'd > >> prefer to just add a small note to the upgrade FAQ), nor am I shure > >> wether I should commit this change (to ghc and *all* hs-ports) now or > >> after I eventually update ghc to something newer. > > > It's probably feasible to quirk the collision away... we did something > > like that a long time ago for texlive. > > I'll have to play a bit with it. > > Do you think I should try incorporating the patch into the ghc upgrade or > is there a chance the approach will change enough? I'll change and commit the current ports hopefully tomorrow or on tuesday and also do the necessary changes to your work and send you a diff or a pull request. > Does it even make sense to combine the two big changes to reduce the total > amount of churn or does this just become harder to land? This should be really done in two steps. Ciao, Kili
Re: switch lang/ghc to @define-tag/@tag
Hi Matthias and Marc, On Fri, 2019-08-23 23:31:20 Marc Espie wrote: >> I'm not sure about wether it's worth to try to avoid the collisions (I'd >> prefer to just add a small note to the upgrade FAQ), nor am I shure >> wether I should commit this change (to ghc and *all* hs-ports) now or >> after I eventually update ghc to something newer. > It's probably feasible to quirk the collision away... we did something > like that a long time ago for texlive. > I'll have to play a bit with it. Do you think I should try incorporating the patch into the ghc upgrade or is there a chance the approach will change enough? Does it even make sense to combine the two big changes to reduce the total amount of churn or does this just become harder to land? Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
Re: switch lang/ghc to @define-tag/@tag
On Fri, Aug 23, 2019 at 11:47:29PM +0200, Matthias Kilian wrote: > The only drawback I can see is the update path from the old to the new > scheme, because pkg_add(8) will complain about collisions when updating > ghc: > > ]# pkg_add -uvx > Old package ghc-8.2.2p4 will run the following commands > - @unexec /usr/bin/env HOME=/nonexistent /usr/local/lib/ghc/unregister.sh > Running update > Collision in ghc-8.2.2p4->8.2.2p5: the following files already exist > /usr/local/lib/ghc/package.conf.d/Cabal-2.0.1.0.conf from ghc-8.2.2p5 > (same checksum) > /usr/local/lib/ghc/package.conf.d/array-0.5.2.0.conf from ghc-8.2.2p5 > (same checksum) > [... ] > It seems to be a missing package registration > Repair ? [y/N/a] y > Adding ghc-8.2.2p4->8.2.2p5 > ghc-8.2.2p5 (extracting) > ghc-8.2.2p5 (skipping) > ghc-8.2.2p4 (deleting) > [...] > > The other hs-ports are *not* affected by this problem, because the > package registration files in package.conf.d no longer have the > MODGHC_PACKAGE_KEY in their file names. > > I'm not sure about wether it's worth to try to avoid the collisions (I'd > prefer to just add a small note to the upgrade FAQ), nor am I shure > wether I should commit this change (to ghc and *all* hs-ports) now or > after I eventually update ghc to something newer. It's probably feasible to quirk the collision away... we did something like that a long time ago for texlive. I'll have to play a bit with it.
switch lang/ghc to @define-tag/@tag
Hi,
this is a sample diff to switch ghc from @exec/@unexec to
@define-tag/@tag. It only includes lang/ghc, devel/hs-stm and
devel/hs-async for now.
Basically, instead of creating all those register/unregister scripts,
the package registration files (of hs libraries) are now included
in the (OpenBSD) packages and ghc-pkg recache will be run after
installations, updates and deletions, by including a @tag ghc-pkg-recache
in the PLIST.
Changes to all the other hs-ports should be simple (bump, build,
update-plist, add the @tag ghc-pkg-recache entry, be sure that the
@exec/@unexec lines are removed).
The only drawback I can see is the update path from the old to the new
scheme, because pkg_add(8) will complain about collisions when updating
ghc:
]# pkg_add -uvx
Old package ghc-8.2.2p4 will run the following commands
- @unexec /usr/bin/env HOME=/nonexistent /usr/local/lib/ghc/unregister.sh
Running update
Collision in ghc-8.2.2p4->8.2.2p5: the following files already exist
/usr/local/lib/ghc/package.conf.d/Cabal-2.0.1.0.conf from ghc-8.2.2p5
(same checksum)
/usr/local/lib/ghc/package.conf.d/array-0.5.2.0.conf from ghc-8.2.2p5
(same checksum)
[... ]
It seems to be a missing package registration
Repair ? [y/N/a] y
Adding ghc-8.2.2p4->8.2.2p5
ghc-8.2.2p5 (extracting)
ghc-8.2.2p5 (skipping)
ghc-8.2.2p4 (deleting)
[...]
The other hs-ports are *not* affected by this problem, because the
package registration files in package.conf.d no longer have the
MODGHC_PACKAGE_KEY in their file names.
I'm not sure about wether it's worth to try to avoid the collisions (I'd
prefer to just add a small note to the upgrade FAQ), nor am I shure
wether I should commit this change (to ghc and *all* hs-ports) now or
after I eventually update ghc to something newer.
Ciao,
Kili
Index: lang/ghc/Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.163
diff -u -p -r1.163 Makefile
--- lang/ghc/Makefile 12 Jul 2019 20:47:18 - 1.163
+++ lang/ghc/Makefile 23 Aug 2019 13:26:02 -
@@ -12,7 +12,7 @@ COMMENT = compiler for the functional l
NO_CCACHE =Yes
DISTNAME = ghc-${MODGHC_VER}
-REVISION = 4
+REVISION = 5
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
@@ -168,28 +168,6 @@ post-patch:
echo 'LD_LIBRARY_PATH=${BOOTSTRAP_SHLIBS} \' && \
printf 'exec ${WRKDIR}/bootstrap/bin/%s "$$@"\n' "$$f"; \
done
-
-post-install:
- cd ${PREFIX}/lib/ghc && \
- GHC_PKG="./bin/ghc-pkg --no-user-package-db --global-package-db
./package.conf.d" && \
- ${INSTALL_SCRIPT} /dev/null register.sh && \
- exec > register.sh && \
- echo '#!/bin/sh' && \
- echo 'p="$${0%/*}/bin/ghc-pkg --no-user-package-db --global-package-db
$${0%/*}/package.conf.d"' && \
- for p in $$($$GHC_PKG dot | sed -n -e 's/^"\([^"]*\)" ->
"\([^"]*\)"$$/\1 \2/p' | tsort -r); do \
- echo \$$p register --force - \<\< \'EOF\' && \
- $$GHC_PKG describe $$p | sed '/^pkgpath:$$/s@$$@ ${PKGPATH}@'
&& \
- echo EOF; \
- done && \
- ${INSTALL_SCRIPT} /dev/null unregister.sh && \
- exec > unregister.sh && \
- echo '#!/bin/sh' && \
- echo 'p="$${0%/*}/bin/ghc-pkg --no-user-package-db --global-package-db
$${0%/*}/package.conf.d"' && \
- for p in $$($$GHC_PKG dot | sed -n -e 's/^"\([^"]*\)" ->
"\([^"]*\)"$$/\1 \2/p' | tsort); do \
- echo \$$p unregister --force $$p; \
- done && \
- rm package.conf.d/* && \
- $$GHC_PKG recache
do-test:
ulimit -c 0 && \
Index: lang/ghc/ghc.port.mk
===
RCS file: /cvs/ports/lang/ghc/ghc.port.mk,v
retrieving revision 1.42
diff -u -p -r1.42 ghc.port.mk
--- lang/ghc/ghc.port.mk22 Jan 2018 00:42:30 - 1.42
+++ lang/ghc/ghc.port.mk23 Aug 2019 21:04:28 -
@@ -23,8 +23,9 @@ BUILD_DEPENDS += lang/ghc
# Set to "cabal" to get the typical Cabal targets defined. Add "haddock"
# to generate API documentation using Haddock. Add "register" to create
-# and include register/unregister scripts (you'll still have to add the
-# necessary tags to your PLIST by hand).
+# and include a package registration file in
+# ${PREFIX}/lib/ghc/package.conf.d (you'll still have to add the
+# necessary @tag ghc-pkg-recache to your PLIST by hand).
# Add "nort" if the port doesn't depend on the GHC runtime. This will
# also turn off the default "hs-" prefix for PK
Re: lang/ghc 8.6.4
criptions.
>
> In other words: when doing operating system distribution packages
> (like our ports), you have to fetch the distfile *and* also watch
> for revised package descriptions, and if there are differences,
> patch the package description contained in the distfile. An example
> of this ist devel/hs-echo/patches/patch-echo_cabal in our ports
> tree.
>
> The haskell eco system is extremely hostile to people who try to
> provide operating system distribution packages -- they think everyone
> just uses cabal-install. That's the reason I try to keep the number
> of hs-ports as low as possible (but to still provide some more or
> less useful tools like darcs or xmonad).
>
> Ciao,
> Kili
diff --git devel/hs-tar/Makefile devel/hs-tar/Makefile
index 07a87426c7c..d9e11ad83f2 100644
--- devel/hs-tar/Makefile
+++ devel/hs-tar/Makefile
@@ -2,8 +2,7 @@
COMMENT = tar bindings for Haskell
-DISTNAME = tar-0.5.0.3
-REVISION = 0
+DISTNAME = tar-0.5.1.0
CATEGORIES = devel archivers
MAINTAINER = Matthias Kilian
@@ -15,6 +14,6 @@ MODULES = lang/ghc
MODGHC_BUILD = cabal hackage haddock register
-MODGHC_PACKAGE_KEY = 4RaKOzbHzG1EpSAqFcpBFH
+MODGHC_PACKAGE_KEY = HaIVxa1LuWJqqT6yxHWqZ
.include
diff --git devel/hs-tar/distinfo devel/hs-tar/distinfo
index 58905b46a93..795e27c1cda 100644
--- devel/hs-tar/distinfo
+++ devel/hs-tar/distinfo
@@ -1,2 +1,2 @@
-SHA256 (ghc/tar-0.5.0.3.tar.gz) = 2Nmth2Nl+IvczQIHMEnlhxXNW6lN4G65jiHVlSRJGKM=
-SIZE (ghc/tar-0.5.0.3.tar.gz) = 38764
+SHA256 (ghc/tar-0.5.1.0.tar.gz) = yJ1pe2RytznbUOYSASUfyvio9bWVsdmkiNOV19XOS2g=
+SIZE (ghc/tar-0.5.1.0.tar.gz) = 39271
diff --git devel/hs-tar/patches/patch-tar_cabal devel/hs-tar/patches/patch-tar_cabal
new file mode 100644
index 000..0409c303e9a
--- /dev/null
+++ devel/hs-tar/patches/patch-tar_cabal
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Bump containers dependency as in hackage revision 1.
+
+Index: tar.cabal
+--- tar.cabal.orig
tar.cabal
+@@ -41,7 +41,7 @@ library
+ build-depends: base == 4.*,
+ filepath < 1.5,
+ array< 0.6,
+- containers >= 0.2 && < 0.6,
++ containers >= 0.2 && < 0.7,
+ deepseq>= 1.1 && < 1.5
+
+ if flag(old-time)
diff --git devel/hs-tar/pkg/PLIST devel/hs-tar/pkg/PLIST
index 0a471f6b0a4..696e052d7f9 100644
--- devel/hs-tar/pkg/PLIST
+++ devel/hs-tar/pkg/PLIST
@@ -38,12 +38,14 @@ share/doc/hs-${DISTNAME}/html/Codec-Archive-Tar-Entry.html
share/doc/hs-${DISTNAME}/html/Codec-Archive-Tar-Index.html
share/doc/hs-${DISTNAME}/html/Codec-Archive-Tar.html
share/doc/hs-${DISTNAME}/html/doc-index.html
-share/doc/hs-${DISTNAME}/html/haddock-util.js
+share/doc/hs-${DISTNAME}/html/haddock-bundle.min.js
share/doc/hs-${DISTNAME}/html/hslogo-16.png
share/doc/hs-${DISTNAME}/html/index.html
+share/doc/hs-${DISTNAME}/html/meta.json
share/doc/hs-${DISTNAME}/html/minus.gif
share/doc/hs-${DISTNAME}/html/ocean.css
share/doc/hs-${DISTNAME}/html/plus.gif
+share/doc/hs-${DISTNAME}/html/quick-jump.css
share/doc/hs-${DISTNAME}/html/synopsis.png
share/doc/hs-${DISTNAME}/html/tar.haddock
@exec /usr/bin/env HOME=/nonexistent %D/lib/ghc/${DISTNAME}/register.sh -v0
diff --git security/hs-cryptohash-sha256/Makefile security/hs-cryptohash-sha256/Makefile
index 9d57c802130..3c87b8ad500 100644
--- security/hs-cryptohash-sha256/Makefile
+++ security/hs-cryptohash-sha256/Makefile
@@ -5,6 +5,7 @@
COMMENT= fast, pure and practical SHA-256 implementation
DISTNAME= cryptohash-sha256-0.11.101.0
+REVISION= 0
CATEGORIES= security
# BSD3
@@ -14,6 +15,6 @@ MODULES= lang/ghc
MODGHC_BUILD = cabal hackage haddock register
-MODGHC_PACKAGE_KEY = 2y5kOPF2abcAQTysw8Z7cK
+MODGHC_PACKAGE_KEY = 4hEdGCusAXMBLiu8h413L1
.include
diff --git security/hs-cryptohash-sha256/patches/patch-cryptohash-sha256_cabal security/hs-cryptohash-sha256/patches/patch-cryptohash-sha256_cabal
new file mode 100644
index 000..01e8a64460d
--- /dev/null
+++ security/hs-cryptohash-sha256/patches/patch-cryptohash-sha256_cabal
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Relax base bound, following hackage revision 2.
+
+Index: cryptohash-sha256.cabal
+--- cryptohash-sha256.cabal.orig
cryptohash-sha256.cabal
+@@ -74,7 +74,7 @@ library
+ Trustworthy
+ Unsafe
+
+- build-depends: base >= 4.5 && < 4.11
++ build-depends: base >= 4.5 && < 4.13
+, bytestring >= 0.9.2 && < 0.11
+
+ ghc-options: -Wall
diff --git security/hs-cryptohash-sha256/pkg/PLIST security/hs-cryptohash-sha256/pkg/PLIST
index 7ccbe556817..75f1996232b 100644
--- security/hs-cryptohash-sha256/pkg/PLIST
+++ security/hs-cryptohash-sha256/pkg/PLIST
@@ -17,12 +17,14 @@ share/doc/hs-${DISTNAME}/html/
share/doc/hs-${DISTN
Re: lang/ghc 8.6.4
On Thu, May 30, 2019 at 06:37:50PM -0400, Daniel Moerner wrote: > Thanks a lot for your work on this. I just built some of ghc 8.6.4 on > a machine running -current using your patches. > > Unfortunately, devel/hs-async doesn't build with this version of ghc > and base (4.12): > > Configuring async-2.2.1... > [...] > Setup: Encountered missing dependencies: > base >=4.3 && <4.12, hashable >=1.1.1.0 && <1.3, stm >=2.2 && <2.5 > > Looking into this a bit, hackage says that async 2.2.1 supports base > (>=4.3 && <4.13) (https://hackage.haskell.org/package/async), but this > just seems to be a mistake in hackage. At present async supports base > 4.12 only in git (and there's a fairly old issue request for a new > release https://github.com/simonmar/async/issues/89). The cabal / hackage / library people are clueless if it comes to version limits in dependencies and when which part of a library should be bumped. Instead of correcting this, they invented a mechanism to publish "revised" meta data for a package via hackage. For async-2.2.1, the "revised" package description can be found at http://hackage.haskell.org/package/async-2.2.1/async.cabal If you compare this against the package description contained in the distfile (or at http://hackage.haskell.org/package/async-2.2.1/src/async.cabal), you'll see that the revised onealready as less strict dependencies (but of course, this will fail again with the next update of ghc): --- async.cabal-dist Fri May 31 11:09:12 2019 +++ async.cabal-hackage Fri May 31 11:10:12 2019 @@ -1,5 +1,6 @@ name:async version: 2.2.1 +x-revision: 2 -- don't forget to update ./changelog.md! synopsis:Run IO operations asynchronously and wait for their results @@ -50,14 +51,14 @@ if impl(ghc>=7.1) other-extensions: Trustworthy exposed-modules: Control.Concurrent.Async -build-depends: base >= 4.3 && < 4.12, hashable >= 1.1.1.0 && < 1.3, stm >= 2.2 && < 2.5 +build-depends: base >= 4.3 && < 4.13, hashable >= 1.1.1.0 && < 1.4, stm >= 2.2 && < 2.6 test-suite test-async default-language: Haskell2010 type: exitcode-stdio-1.0 hs-source-dirs: test main-is:test-async.hs -build-depends: base >= 4.3 && < 4.12, +build-depends: base >= 4.3 && < 4.13, async, stm, test-framework, See http://hackage.haskell.org/package/async-2.2.1/revisions/ for that concept of 'revised' package descriptions. In other words: when doing operating system distribution packages (like our ports), you have to fetch the distfile *and* also watch for revised package descriptions, and if there are differences, patch the package description contained in the distfile. An example of this ist devel/hs-echo/patches/patch-echo_cabal in our ports tree. The haskell eco system is extremely hostile to people who try to provide operating system distribution packages -- they think everyone just uses cabal-install. That's the reason I try to keep the number of hs-ports as low as possible (but to still provide some more or less useful tools like darcs or xmonad). Ciao, Kili
Re: lang/ghc 8.6.4
Hi, Thanks a lot for your work on this. I just built some of ghc 8.6.4 on a machine running -current using your patches. Unfortunately, devel/hs-async doesn't build with this version of ghc and base (4.12): Configuring async-2.2.1... [...] Setup: Encountered missing dependencies: base >=4.3 && <4.12, hashable >=1.1.1.0 && <1.3, stm >=2.2 && <2.5 Looking into this a bit, hackage says that async 2.2.1 supports base (>=4.3 && <4.13) (https://hackage.haskell.org/package/async), but this just seems to be a mistake in hackage. At present async supports base 4.12 only in git (and there's a fairly old issue request for a new release https://github.com/simonmar/async/issues/89). Best, Daniel
Re: lang/ghc 8.6.4
Hi, On Sun, May 26, 2019 at 11:23:55PM -0700, Greg Steuck wrote: > I've updated a couple dozen more ports after having slacked for 2 months: > https://github.com/blackgnezdo/ports/commits/ghc_864_may26 Thanks (and, well, I'm slacking even more than you). I really hope to get a try of it, but first I want to experiment a little bit with replacing all the @exec/@unexec plist entries for registering and unregistering the hs packages (in ghc *and* the hs-ports) by @define-tag/@tag. @espie gave me some hints; the idea is: - after building the port, in the fake stage, create the package description and install it straight into lib/ghc/package.conf.d (with the proper file name) and include that into the plist, - use (via @define-tag / @tag to run ghc-pkg recache *once* after installation / deletion or updates. Don't ve afraid -- if I successfully test this with ghc-8.2 and two or three hs-ports, I'll just add all the necessary changes to your work (and send you diffs for it). Ciao, Kili
Re: lang/ghc 8.6.4
Mass import averted. It's easy enough to patch up the old version of hs-dbus. hs-dbus.patch.gz Description: application/gzip
lang/ghc 8.6.4
I've updated a couple dozen more ports after having slacked for 2 months: https://github.com/blackgnezdo/ports/commits/ghc_864_may26 I'm attaching a jumbo patch against ports-current. I confess to not following the proper protocol and building stuff on 6.5. I'm also probably making tons of other rookie mistakes which I'd appreciate to have pointed out. The status of the effort is: x11/hs-dbus won't go in easy. The old version is old enough that patching it to compile is probably a fool's errand. The new version has a large set of dependencies which aren't currently imported and will take a bit of effort to get in. Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0 ghc-8.6.4-may26.patch.gz Description: application/gzip
Re: lang/ghc
On Thu, Feb 28, 2019 at 08:43:49PM +0100, Matthias Kilian wrote: > Hi, > > On Thu, Feb 28, 2019 at 04:54:51PM +0100, Marc Espie wrote: > > On Tue, Feb 26, 2019 at 10:21:07PM +0100, Matthias Kilian wrote: > > > Some notes: make update-plist seems to remove lib/ghc/unregister.sh > > > from pkg/PLIST, I've no idea, why. > > > > ghc is about the only port left with major @exec/@unexec in the plist. > > > > it would be great if those scripts could be abstracted somewhat so that > > the registration/unregistration is run just once at the end of pkg_add, > > like is done for all other things that moved to @tag/@define-tag. > > I can try to do this, to make it able to nuke @exec/@unexec. But I > don't think it'll gain anything with @tag/@define-tag, because all the > register.sh scripts (in lang/ghc and all the hs-parts) are different. > > On the other hand, it may be possible to almost completely get rid > of the register/unregister scripts -- every haskell package now > "registered" by a single file in $PREFIX/lib/ghc/package.conf.d, > which I could just include in the packages and then run ghc-pkg > recache (which would then be done with @tag/@define-tag). This looks like a MUCH simpler approach, might even be faster.
