Hi Ilias,
On Thu, 2024-06-13 at 20:50 +0200, John Paul Adrian Glaubitz wrote:
> > Do we still have to build an unregisterised compiler for powerpc
> > or can we switch back to NCG (https://bugs.debian.org/1060196)?
>
> I have not verified that yet. Please let's stay unregisterised for now
> and h
Hey Adrian,
On Thu, Jun 13, 2024 at 10:09AM, John Paul Adrian Glaubitz wrote:
> Hi Jeff,
>
> On Thu, 2024-06-13 at 03:50 -0400, Jeffrey Walton wrote:
> > > Now we just need to figure out how to actually set the default linker back
> > > to bfd as it was actually explicitly supposed to happen acco
Hi Ilias,
On Thu, 2024-06-13 at 21:22 +0300, Ilias Tsitsimpis wrote:
> Great job!
Thanks!
> I completely missed the fact this needs to be passes to the bindist's
> configure script as well.
It took me forever to figure this out ;-).
> You need to edit debian/rules here
> https://sources.debian
Hi Jeff,
On Thu, 2024-06-13 at 03:50 -0400, Jeffrey Walton wrote:
> > Now we just need to figure out how to actually set the default linker back
> > to bfd as it was actually explicitly supposed to happen according to
> > debian/rules.
> >
> > This will most likely also unbreak GHC on m68k.
>
>
On Thu, Jun 13, 2024 at 3:41 AM John Paul Adrian Glaubitz
wrote:
>
> I finally figured out what the problem is.
>
> After realizing that the two-stage build of GHC works without problems,
> I realized it can be a configuration issue only and, indeed, it is.
>
> Looking at /usr/lib/ghc/lib/settings
Hi,
I finally figured out what the problem is.
After realizing that the two-stage build of GHC works without problems,
I realized it can be a configuration issue only and, indeed, it is.
Looking at /usr/lib/ghc/lib/settings, the default linker is set to gold:
"C compiler link flags", "
On Wed, 2023-10-11 at 18:02 +0300, Ilias Tsitsimpis wrote:
> A small update here. I didn't manage to use the LLVM backend on i386,
> seems to be broken [1].
I am trying to figure out now what it takes to build GHC using the LLVM
backed on 32-bit PowerPC but it currently doesn't seem to be supporte
Hi Adrian,
On Sun, Oct 15, 2023 at 09:01PM, John Paul Adrian Glaubitz wrote:
> Unfortunately, we're running into another familiar problem which is a missing
> -latomic
> when building hadrian using the bootstrap.py script which does not take any
> build flags,
> the build of the »shake« package
Hello!
I have built a patched version 9.0.1 of GHC for powerpc with a forged 9.0.3
version
number and uploaded it to unreleased so that we have a working bootstrap
compiler
to build 9.4.7 for powerpc once the bug has been fixed.
Unfortunately, we're running into another familiar problem which i
On Wed, 2023-10-11 at 18:29 +0300, Ilias Tsitsimpis wrote:
> I think our best bet here is to bootstap GHC on these architectures,
> that's why I have introduced the 'pkg.ghc.nohadrian' build profile. Let
> me know if I can help, or if there is a better way to do it that I am
> missing.
OK, good to
On Wed, Oct 11, 2023 at 05:12PM, John Paul Adrian Glaubitz wrote:
> I think you created a little hen and egg problem here by incorporating both
> the switch to the Hadrian build system as well as the 32-bit unregisterised
> and sparc64 build fixes into the same upload.
>
> Might a good idea to upl
Hi Ilias!
On Wed, 2023-10-11 at 18:02 +0300, Ilias Tsitsimpis wrote:
> A small update here. I didn't manage to use the LLVM backend on i386,
> seems to be broken [1].
>
> Instead, I believe I have managed to fix unregisterised GHC on 32-bit,
> by backporting these two patches [2] [3]. Can you try
Hi Adrian,
On Wed, Oct 04, 2023 at 11:59AM, John Paul Adrian Glaubitz wrote:
> > 2. An unregisterised GHC 9.0.2 is *also* broken on powerpc, producing
> > code that overflows integers. We are also seeing unregisterised GHC
> > 9.4.6 on i386 being broken, since the tests for haskell-quickcheck fai
On 09 oct. 2023 09:32, John Paul Adrian Glaubitz
wrote:
[...]
> I think the interesting part would be the disassembly of
> base_GHCziFloat_floatToDigits_closure ()
> where the actual crash happened. Your disassembly seems to show parts
> of the segfault handler.
,
| 10a19f20 :
| 10a19f20:
Hi Christian!
On Mon, 2023-10-09 at 09:25 +0200, Christian Marillat wrote:
> > On Mon, 2023-10-09 at 08:57 +0200, Christian Marillat wrote:
> > > > Could you provide the disassembled code for the affected code section?
>
> Is this enough ?
>
> ,
> > Dump of assembler code for function __GI_k
On 09 oct. 2023 08:59, John Paul Adrian Glaubitz
wrote:
> Hi Christian!
Hi Adrian,
> On Mon, 2023-10-09 at 08:57 +0200, Christian Marillat wrote:
>> > Could you provide the disassembled code for the affected code section?
Is this enough ?
,
| Dump of assembler code for function __GI_kill
Hi Christian!
On Mon, 2023-10-09 at 08:57 +0200, Christian Marillat wrote:
> > Could you provide the disassembled code for the affected code section?
>
> I don't remember but now I can install ghc (>= 9.4) only 9.0.2 is
> available.
The bug affects GHC 9.0.2 as the change was backported. GHC 9.4
On 05 oct. 2023 22:34, John Paul Adrian Glaubitz
wrote:
> Hi Christian!
Hi Adrian,
[...]
> Could you provide the disassembled code for the affected code section?
I don't remember but now I can install ghc (>= 9.4) only 9.0.2 is
available.
Is it important ?
Christian
__
Hi Christian!
> ,
> | Reading symbols from
> /home/marillat/haskell-random-1.2.1.1/debian/hlibrary.setup...
> | (No debugging symbols found in
> /home/marillat/haskell-random-1.2.1.1/debian/hlibrary.setup)
> | [New LWP 9082]
> | [Thread debugging using libthread_db enabled]
> | Using host li
Hi Ilias!
On Wed, 2023-10-04 at 12:26 +0200, John Paul Adrian Glaubitz wrote:
> Looking at the ghc package in openSUSE, I found this patch [1] which disables
> unboxed arrays
> in order to fix the build on big-endian systems. And, indeed, disabling
> unboxed arrays in
> libraries/containers/cont
Hi!
On Wed, 2023-10-04 at 11:59 +0200, John Paul Adrian Glaubitz wrote:
> FWIW, I have not been able to build GHC from git on 32-bit PowerPC even for
> 8.10.7. I assume,
> I will need to add some of Debian's patches on top of vanilla GHC in order to
> get the build
> to succeed.
>
> Trying to b
Hi Ilias!
On Wed, 2023-09-20 at 14:54 +0300, Ilias Tsitsimpis wrote:
> Thanks for working on this, comments inline.
Thanks for the useful hints!
> On Wed, Sep 20, 2023 at 12:15PM, John Paul Adrian Glaubitz wrote:
> > I have been bisecting this issue but in order to be successful, I need a
> > s
Hi Adrian,
Thanks for working on this, comments inline.
On Wed, Sep 20, 2023 at 12:15PM, John Paul Adrian Glaubitz wrote:
> I have been bisecting this issue but in order to be successful, I need a
> simple
> reproducer which isn't trivial since I cannot just reuse the build directory
> of
> an
Hello!
I have been bisecting this issue but in order to be successful, I need a simple
reproducer which isn't trivial since I cannot just reuse the build directory of
an unsuccessful build due to the changing Haskell libraries for different GHC
versions.
Ideally, we should have a single command l
Hi!
Note that this issue also prevents us from building the latest version of the
GHC compiler [1]. I have tried to cross-compile GHC 9.4.6 to work around this
issue and also tried building an unregisterised compiler. Both without success.
I have forwarded the issue upstream [2]. I think the only
25 matches
Mail list logo
