Backport of #12975 fix
>
> ---
> ...patch-compiler_GHC_CmmToAsm_X86_CodeGen_hs | 49 +++
> 1 file changed, 49 insertions(+)
> create mode 100644
> lang/ghc/patches/patch-compiler_GHC_CmmToAsm_X86_CodeGen_hs
>
> diff --git a/lang/ghc/patches/pat
001
From: Greg Steuck
Date: Tue, 9 Jul 2024 00:40:48 -0700
Subject: [PATCH] Backport of #12975 fix
---
...patch-compiler_GHC_CmmToAsm_X86_CodeGen_hs | 49 +++
1 file changed, 49 insertions(+)
create mode 100644 lang/ghc/patches/patch-compiler_GHC_CmmToAsm_X86_CodeGen_hs
diff --
>From a7223783b7b5ad3fd8ea4d2cb2883e8dac1b071e Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Mon, 8 Jul 2024 09:59:20 -0700
Subject: [PATCH 1/3] Update to to ghc 9.6.6
---
lang/ghc/Makefile| 8 +++-----
lang/ghc/distinfo
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.
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
p
---
> 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/Make
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
in
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 o
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
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
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
&
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
t; 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/g
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
&
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 n
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
===
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
stion 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:).
> Al
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 th
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 @
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
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/l
ade 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
+++
me 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/g
er 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.
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/g
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-fr
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_
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 i
s 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
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
. 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
al
h.
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
> +++ Ma
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 err
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
--
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;
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
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,
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
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
>
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
as 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
gt; 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
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.1
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.
>
> O
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
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 desidera
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
+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
> > 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/f21cb097f2
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.
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 t
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&m=160858285410366&w=2
> A quick search in the archives will show the justification and the
> history of the effort.
>
> The current state of the work
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
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 wort
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:
>
> * Current
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://githu
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 rep
> > 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
> "caba
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/pu
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 a
> > 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 beli
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
>
> 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_DE
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
> http
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-
> 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-0b3828545e6cf6ec417
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
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/
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"
> "
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;archi
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 grea
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 i38
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
256 (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_p
e?
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 >
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 (llv
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
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
> 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 patc
-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
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-
e, 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
--- Mak
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
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
===
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 =
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
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 2
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
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
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/
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
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 c
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
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
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
ts
> 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 pro
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 asyn
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 && <
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 fir
1 - 100 of 223 matches
Mail list logo
