Friends
In !14410, specifically on Fedora, I get this build failure
<https://gitlab.haskell.org/ghc/ghc/-/jobs/2225860>. Some kind of crash in
some invocation of Haddock to make the docs for ghc-internal.
Question: how can I reproduce this failure on my own machine? It builds
fine
Hi Simon,
I suspect you need to click on the arrow right next to the line numbers in the
log to unfold the complete log starting “Test via Hadrian"
— Apoorv
On Jun 30, 2025, at 11:47 AM, Simon Peyton Jones
wrote:
Friends
My build !14410 has started consistently failing to show me testsuite
Friends
My build !14410 has started consistently failing to show me testsuite
output etc. The tail of the log is s very long sequence of Haddock
warnings.
Something has changed and I don't think it's my MR!
Does anyone have any idea what is happening?
Thanks
Simon
_
never mind. i see that's it's been discussed and there's a ticket
https://gitlab.haskell.org/ghc/ghc/-/issues/21633 and a related MR
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8332.
On Tue, May 24, 2022 at 5:34 PM Shayne Fletcher <
shayne.fletcher...@gmail.com> wrote:
> i've found for th
i've found for the last couple of weeks, the 9.4 branch fails to build with
the following error. is this known? a fix in the works?
```
libraries/bytestring/Data/ByteString/Internal.hs:292:23: error:
• Couldn't match type ‘m’ with ‘TH.Q’
‘m’ is a rigid type variable bound by
the t
Hi Viktor,
- I believe the "test spaces" part is important and would need to be fixed,
if spaces break this is not desirable.
- For the Relocations part, I'm happy to offer guidance and help for anyone
who wants to take a stab at it, right
now I'm not in a position where I could take this on my
On Mon, Mar 15, 2021 at 06:44:20AM -0400, Viktor Dukhovni wrote:
> ..., the FreeBSD "validate --legacy"
> successfully builds GHC. [ The tests seem to all be failing, perhaps
> the test driver scripts are not portable to FreeBSD, but previously
> the compiler was not building. ]
FWIW, the tests
On Mon, Mar 15, 2021 at 09:46:35AM +0100, Sylvain Henry wrote:
> >
> > Thank you! Don’t forget to comment it – especially because it is fake.
>
> Done in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5265
Speaking of build failures with the legacy make system, I see
Thank you! Don’t forget to comment it – especially because it is fake.
Done in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5265
Make build system doesn't respect package dependencies, only module
dependencies (afaik)
Does Hadrian suffer from this malady too? Are the fake imports ne
es Hadrian suffer from this malady too? Are the fake imports needed? Or can
we sweep them away when we sweep away make?
Simon
From: ghc-devs On Behalf Of Sylvain Henry
Sent: 15 March 2021 08:30
To: ghc-devs@haskell.org
Subject: Re: Build failure -- missing dependency? Help!
Hi Simon,
The issue
Hi Simon,
The issue is that:
1. Make build system doesn't respect package dependencies, only module
dependencies (afaik)
2. The build system isn't aware that most modules implicitly depend on
GHC.Num.Integer/Natural (to desugar Integer/Natural literals)
That's why we have several fake imports
> On Mar 14, 2021, at 6:53 PM, Simon Peyton Jones via ghc-devs
> wrote:
>
> I’m getting this (with ‘sh validate –legacy’). Oddly
>
> • It does not happen on HEAD
> • It does happen on wip/T19495, a tiny patch with one innocuous change
> to GHC.Tc.Gen.HsType
> I can’t see how my
I'm getting this (with 'sh validate -legacy'). Oddly
* It does not happen on HEAD
* It does happen on wip/T19495, a tiny patch with one innocuous change to
GHC.Tc.Gen.HsType
I can't see how my patch could possible cause "missing files" in ghc-bignum!
I'm guessing that there is a missing
Hi,
They are stats failures. Not good enough, which means you have a regression
in memory usage. Look at the full test log
https://phabricator.haskell.org/harbormaster/build/48354/1/?l=100
They also failed on windows, but currently harbormaster doesn't fail when
tests fail for windows. Clicking t
Roland Senn writes:
> Hi all,
>
Hi Roland,
it looks like the failing tests are performance tests. These
unfortunately do spuriously fail occasionally. Given the nature of your
patch it seems extremely unlikely that the failure is your fault. Feel
free to ignore it and I will sort it out when I g
Hi all,
Phabricator informed me, that the builds on Harbourmaster for my
changes failed.
Looking at the log at https://phabricator.haskell.org/B21368 I can see,
that the builds on Linux and Windows succeeded, however the tests on
OS/X failed.
Looking at the failed tests at https://phabricator.h
Ningning Xie writes:
> Hi everyone,
>
> I pulled from the head this morning and would like to rebase my local
> changes on it. Even before I do rebase, I got a build error. Everything is
> fine last time I built (almost one week ago). Then I tried to glone a new
> repo and the build gives me the
Hi everyone,
I pulled from the head this morning and would like to rebase my local
changes on it. Even before I do rebase, I got a build error. Everything is
fine last time I built (almost one week ago). Then I tried to glone a new
repo and the build gives me the same error message.
After a littl
I've just landed a commit of Ben's [1] which should fix this issue.
Ryan S.
-
[1] Specifically,
http://git.haskell.org/ghc.git/commit/54acfbbf64f5fcb108836412e9be0cfabf0d7801
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-
Hi Simon et al.
On Tue, Apr 3, 2018 at 5:37 PM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:
> It seems to be caused by some missing Makefile dependency
>
>
>
> It may be significant that the dependency is a module in libraries/base
> GHC/IO.hs-boot depending on one GHC.Integer
Thanks everyone. I didn't expect just continuing "make" would work, but it
does, so that's a workaround for now. I'll look forward to the real fix, of
course.
John
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/lis
Leo
Cc: ghc-devs
Subject: Re: 8.5 build failure
I've hit this, too, in the last few days. It seems to be caused by some missing
Makefile dependency. My solution has been to `make -j1` for a bit, then cut it
off, then `make -j` again. I'm glad to know it's not just me.
:)
On
I think there was a commit recently that requires you to reconfigure.
>
> I have just committed 4de585a which lifts the MAX_PATH restrictions for
Haskell programs
> compiled with GHC 8.6 for Windows users.
>
> However when you update, you *MUST* run configure again. This counts for
ALL platforms o
Does the error go away if you restart the build without cleaning? I had the
same error on my nightly builder, but it worked when I restarted the build.
Ömer
2018-04-03 18:06 GMT+03:00 John Leo :
> Hi everyone,
>
> I pulled from head this morning and rebased my current work on it, and am
> getting
I've hit this, too, in the last few days. It seems to be caused by some missing
Makefile dependency. My solution has been to `make -j1` for a bit, then cut it
off, then `make -j` again. I'm glad to know it's not just me.
:)
> On Apr 3, 2018, at 11:06 AM, John Leo wrote:
>
> Hi everyone,
>
>
so is every one else ☹. No one has a clue what’s going on. Ben &co are
investigating.
Simon
From: ghc-devs On Behalf Of John Leo
Sent: 03 April 2018 16:06
To: ghc-devs
Subject: 8.5 build failure
Hi everyone,
I pulled from head this morning and rebased my current work on it, an
One thing I should note is that I believe since the last time I'd built I
updated Mac OS to 10.13.4, if that is relevant. Note that stage 1 built
fine; the failure occurs about 22 minutes into a build that typically takes
30 minute on my machine.
John
On Tue, Apr 3, 2018 at 8:06 AM, John Leo wro
Hi everyone,
I pulled from head this morning and rebased my current work on it, and am
getting a build error I've never seen before. I don't think it's due to any
of my own changes, and everything built fine last time I tried just a
couple days ago . I'd pulled both code and submodules. I did make
evs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> | Wolfgang Jeltsch
> | Sent: 11 June 2015 16:20
> | To: ghc-devs@haskell.org
> | Subject: Re: GHC build failure
> |
> | Hi again,
> |
> | it still fails with the same error message.
> |
> | All the best,
&
: ghc-devs@haskell.org
| Subject: Re: GHC build failure
|
| Hi again,
|
| it still fails with the same error message.
|
| All the best,
| Wolfgang
|
| Am Donnerstag, den 11.06.2015, 18:17 +0300 schrieb Wolfgang Jeltsch:
| > Hi,
| >
| > I did not care about the submodules; so this
Hi again,
it still fails with the same error message.
All the best,
Wolfgang
Am Donnerstag, den 11.06.2015, 18:17 +0300 schrieb Wolfgang Jeltsch:
> Hi,
>
> I did not care about the submodules; so this could be the reason of the
> failure. That said, running
>
> git submodule update --init
Hi,
I did not care about the submodules; so this could be the reason of the
failure. That said, running
git submodule update --init
now only showed a message regarding utils/haddock, which causes me some
doubts that it will really fix the issue with deepseq. Let’s see.
All the best,
Wolfgan
Am Donnerstag, den 11.06.2015, 16:50 +0200 schrieb Herbert Valerio
Riedel:
> On 2015-06-11 at 16:37:47 +0200, Wolfgang Jeltsch wrote:
> > I just updated my GHC HEAD copy via git pull and tried to rebuild GHC
> > with BuildFlavour set to devel2. I got the following error message:
> >
> > ghc/Int
On 2015-06-11 at 16:37:47 +0200, Wolfgang Jeltsch wrote:
> I just updated my GHC HEAD copy via git pull and tried to rebuild GHC
> with BuildFlavour set to devel2. I got the following error message:
>
> ghc/InteractiveUI.hs:68:8: error:
> Could not find module ‘Control.DeepSeq’
>
Maybe you forgot `git submodule init` or `git submodule update`? See this
page for a simple trick to never forget again:
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#UsingaGitalias
If that didn't work, do a `make maintainer-clean` and try again.
On Thu, Jun 11, 2015 at
Hi,
I just updated my GHC HEAD copy via git pull and tried to rebuild GHC
with BuildFlavour set to devel2. I got the following error message:
ghc/InteractiveUI.hs:68:8: error:
Could not find module ‘Control.DeepSeq’
It is a member of the hidden package
‘deepseq-1.4.1.1
Hi Dominic,
On 23 January 2015 at 03:14, Dominick Samperi wrote:
> The best way to move beyond the somewhat dated version of the Haskell
> Platform that is distributed with Fedora 21 is to install the version
> available at http://www.haskell.org/platform instead of the version
> installed by yum
The best way to move beyond the somewhat dated version of the Haskell
Platform that is distributed with Fedora 21 is to install the version
available at http://www.haskell.org/platform instead of the version
installed by yum. This fixes all of the shared library issues that
arise when installing pa
Hello hvr,
I compiled from the source for ghc-7.8.4 by first creating mk/build.mk
from the supplied template build.mk.sample with BuildFlavour = quick,
then the usual: ./configure --prefix=/bin/ghc-7.8.4;
make install...
Perhaps there is a different build configuration where all necessary
shared
Dominick Samperi wrote:
> It turns out that the undefined reference to libHSprimitive-0.5.4.0.so
> when installing pandoc is not related to the use of CentOS or Debian
> binaries. I get the same undefined reference when I try to use
> ghc-7.8.4 compiled from source under Fedora 21. Here is the out
On 2015-01-17 at 09:22:05 +0100, Dominick Samperi wrote:
> It turns out that the undefined reference to libHSprimitive-0.5.4.0.so
> when installing pandoc is not related to the use of CentOS or Debian
> binaries. I get the same undefined reference when I try to use
> ghc-7.8.4 compiled from source
It turns out that the undefined reference to libHSprimitive-0.5.4.0.so
when installing pandoc is not related to the use of CentOS or Debian
binaries. I get the same undefined reference when I try to use
ghc-7.8.4 compiled from source under Fedora 21. Here is the output of
'locate libHSprimitive':
I also have ghc-7.8.4 builds available in
https://copr.fedoraproject.org/coprs/petersen/ghc-7.8.4/
if that helps, though they replace the Fedora ghc packages.
Jens
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo
Hi Roman,
Thank you for suggesting that I take another look at compiling from
source under Fedora 21. This is indeed quite straightforward
(configure --prefix=..., make, make install). The reason it failed
earlier is that I had the latest build (from HEAD) in my path:
ghc=7.11.20150111. Bootstrapp
On 12/01/15 04:00, Dominick Samperi wrote:
> Hi Roman.
>
> As I said in my comments I tried the binary distribution provided for
> CentOS65 Linux but ran into problems. I also tried the distribution provided
> for Debian Linux; this installed, but there were problems.
>
> Fedora is the most "cutt
Thank you Edward.
I managed to build from HEAD under Fedora 21 (after 'cabal install containers').
The errors I reported may be related to the way I tried to clone a particular
branch:
git clone -b ghc-7.8 git://github.com/ghc/ghc.git
It is not clear how to checkout/build/package a particular v
Do you know you can simply install the ghc binary distribution without
having to compile anything?
https://www.haskell.org/ghc/download_ghc_7_8_4
On 11/01/15 08:07, Dominick Samperi wrote:
> Hello,
>
> I'm trying to build ghc-7.8 branch under Fedora 21 and I get the
> failure diagnostics appended
What you cabal installed should be irrelevant, since containers is never
built by the boot compiler. In your full log, is 'deepseq' registered
before the build process attempts to register 'containers'? Is
there a deepseq file in inplace/lib/package.conf.d?
Edward
Excerpts from Dominick Samperi
Here is a little more context...if I use the centos65 binary and try
to install pandoc, it fails on
the install of the vector package, because the shared library
libHSprimitive-0.5.4.0.so is not found (the package primitive-0.5.4.0 contains
libHSprimitive-0.5.4.0.a, no .so file?).
Here is the diag
Hello,
I'm trying to build ghc-7.8 branch under Fedora 21 and I get the
failure diagnostics appended below. The problem seems to be that the
build process cannot satisfy deepseq >=1.2 && <1.4, but I explicitly
installed deepseq-1.3.0.2, and this did not help (same error?).
Under Fedora 21 Haskell
Sounds like #8744 (https://ghc.haskell.org/trac/ghc/ticket/8744).
The fix for this has already been merged into the 7.8 branch, but of course, it
won't appear in any 7.8RC1 distribution. If you update to the tip of the 7.8
branch, you should hopefully be OK.
Richard
On Feb 18, 2014, at 11:08 A
Possibly I did something wrong (certainly when I tried to build something
very close to RC1 at Austin's request it worked fine), but now I am getting
In file included from rts/sm/Evac.c:21:0:
rts/sm/GCTDecl.h:71:0:
error: thread-local storage not supported for this target
(Host compiler: gh
Hi,
I have created a ticket about "Dynamic linking and libffi":
http://hackage.haskell.org/trac/ghc/ticket/7806
--Kazu
>> OK, I've just pushed another attempt; can you let me know whether HEAD
>> now works for you, please?
>
> Thanks.
>
>> That's expected. All the Haskell .so's should
> I tried to install the vanilla binary tarball that the builder client
> created this morning [1] (i386), but I got the following errors at
> install:
I think this kind of errors should not be occurred anyway.
>> Note that I set "sudo -w vfs.timestamp_precision=1" on FreeBSD
>> according to:
>>
On Mon, Mar 25, 2013 at 3:42 AM, Kazu Yamamoto wrote:
> Summary: building GHC head succeeds both on FreeBSD and Mac. But
> installing GHC head fails both on FreeBSD and Mac. This is probably
> because no installed scripts define (DY)LD_LIBRARY_PATH.
I tried to install the vanilla binary tarball t
> What is the version of your devel/libffi port?
3.0.9.
> Could not adding
> --with-system-libffi and related flags to the configuration phase fix
> the problem?
Yes. When I added --with-system-libffi
--with-ffi-includes=/usr/local/include
--with-ffi-libraries=/usr/local/lib, this problem does n
On Sun, Mar 24, 2013 at 10:26 PM, Ian Lynagh wrote:
> The .a lines probably mean you are missing
>
> commit 8575d01b4205b4545c54f9f1ba1d993a87bac72c
> Author: Ian Lynagh
> Date: Sun Mar 24 17:29:30 2013 +
>
> Fix the names of the libffi archives
Yes, I saw your commit later
On Sun, Mar 24, 2013 at 10:08:14PM +0100, Páli Gábor János wrote:
>
> However, if I do not use --with-system-libffi, but libffi.so.6 is
> present on the system, the following happens at gmake binary-dist
> (just for your information):
>
> $ gmake binary-dist
> [snip]
> tar: ghc-7.7.20130324/rts/d
On Sun, Mar 24, 2013 at 3:51 PM, Páli Gábor János wrote:
> On Sun, Mar 24, 2013 at 12:50 PM, Kazu Yamamoto wrote:
>> % ghci
>> Shared object "libffi.so.6" not found, required by
>> "libHSrts_thr-ghc7.7.20130323.so"
>
> What is the version of your devel/libffi port? Could not adding
> --with-sys
On Sun, Mar 24, 2013 at 08:50:56PM +0900, Kazu Yamamoto wrote:
>
> Build finished on FreeBSD and "ghc-stage2" works:
>
> However, "gmake install" failed:
>
>
> Installing library in /ghc-head/lib/ghc-7.7.20130323/haskell2010-1.1.1.0
> "/ghc-head/lib/ghc-7.7.20130323/bin/ghc-pkg" --force --g
On Sun, Mar 24, 2013 at 12:50 PM, Kazu Yamamoto wrote:
> % ghci
> Shared object "libffi.so.6" not found, required by
> "libHSrts_thr-ghc7.7.20130323.so"
What is the version of your devel/libffi port? Could not adding
--with-system-libffi and related flags to the configuration phase fix
the prob
> OK, I've just pushed another attempt; can you let me know whether HEAD
> now works for you, please?
Thanks.
> That's expected. All the Haskell .so's should also be not found.
> That's why inplace/bin/ghc-stage2 sets LD_LIBRARY_PATH.
I understand.
Build finished on FreeBSD and "ghc-stage2" wor
On Thu, Mar 21, 2013 at 09:08:46AM +0900, Kazu Yamamoto wrote:
> >> In my case:
> >>
> >>libffi.so.6 => not found (0)
>
> This fix does not solve the problem and "validate" still has the same
> problem.
OK, I've just pushed another attempt; can you let me know whether HEAD
now works for you,
>> In my case:
>>
>> libffi.so.6 => not found (0)
>
> Ah, I'm optimistic that
>
> commit 51bf3653775ba734f7ca3de99234aba722a0c72c
> Author: Ian Lynagh
> Date: Wed Mar 20 19:25:27 2013 +
>
> Fix build with non-Linux ELF OSes
>
> will fix this.
This fix does not solv
On Wed, Mar 20, 2013 at 04:42:55PM +0900, Kazu Yamamoto wrote:
> > $ ldd "/home/ian/ghc/git/ghc/bindisttest/install
> > dir/lib/ghc-7.7.20130319/bin/ghc-pkg" | grep ffi
> > libffi.so.6 => /home/ian/ghc/git/ghc/bindisttest/install
> > dir/lib/ghc-7.7.20130319/bin/../rts-1.0/libffi.so.6
> $ ldd "/home/ian/ghc/git/ghc/bindisttest/install
> dir/lib/ghc-7.7.20130319/bin/ghc-pkg" | grep ffi
> libffi.so.6 => /home/ian/ghc/git/ghc/bindisttest/install
> dir/lib/ghc-7.7.20130319/bin/../rts-1.0/libffi.so.6 (0x7fd2faf6e000)
In my case:
libffi.so.6 => not found (0
On Tue, Mar 19, 2013 at 12:02:37PM +0900, Kazu Yamamoto wrote:
>
> Thank you. Building now works. But "validate" fails.
>
> "/usr/home/kazu/work/ghc/bindisttest/install
> dir/lib/ghc-7.7.20130319/bin/ghc-pkg" --force --global-package-db
> "/usr/home/kazu/work/ghc/bindisttest/install
> dir/
>> It is LD_LIBRARY_PATH. I modified to set LD_LIBRARY_PATH in FreeBSD
>> and confirmed that it works!
>
> Thanks. I've pushed a patch for this.
Thank you. Building now works. But "validate" fails.
"/usr/home/kazu/work/ghc/bindisttest/install
dir/lib/ghc-7.7.20130319/bin/ghc-pkg" --force --gl
On Mon, Mar 18, 2013 at 11:01:23AM +0900, Kazu Yamamoto wrote:
>
> > What's the right thing to do on the BSDs?
>
> It is LD_LIBRARY_PATH. I modified to set LD_LIBRARY_PATH in FreeBSD
> and confirmed that it works!
Thanks. I've pushed a patch for this.
Thanks
Ian
_
Hello,
>> "cp" -p utils/hsc2hs/dist/build/tmp/hsc2hs inplace/lib/bin/hsc2hs
>> utils/hsc2hs/ghc.mk:15: *** Do not know how to prependLibraryPath on
>> freebsd. Stop.
>> gmake: *** [all] Error 2
>
> It's trying to do the equivalent of setting LD_LIBRARY_PATH or
> DYLD_LIBRARY_PATH (see rules/lib
Hi Kazu,
On Sun, Mar 17, 2013 at 10:04:30PM +0900, Kazu Yamamoto wrote:
>
> GHC head cannot be build on FreeBSD 9.1:
>
>
> libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No
> such file or directory
> compiler/ghc.mk:426: compiler/stage1/build/.depend-v.haskell: N
Hi,
GHC head cannot be build on FreeBSD 9.1:
libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No
such file or directory
compiler/ghc.mk:426: compiler/stage1/build/.depend-v.haskell: No such file or
directory
"cp" -p utils/hsc2hs/dist/build/tmp/hsc2hs inplace/lib/bin
72 matches
Mail list logo
