From post at volker-wysk.de  Sat Oct 17 12:42:33 2020
From: post at volker-wysk.de (Volker Wysk)
Date: Sat, 17 Oct 2020 14:42:33 +0200
Subject: "... causes overflow in R_X86_... relocation"
Message-ID: <d1d9f3846d3831f8e08fa8feddf838c534267722.camel@volker-wysk.de>

Hi.

I have a litte program named "svumb", which compiles and links without error 
or warning message. But when I start it, this happens:

build/svumb: Symbol `qtahzmqt5zm0zi7zi0zm4ATcbzzMngNWCbnemaqWUdM_GraphicsziUIziQtahziGeneratedziWidgetsziQMessageBox_setText_closure' causes overflow in R_X86_64_32 relocation
(... long list of similar messages ...)
build/svumb: Symbol `stg_INTLIKE_closure' causes overflow in R_X86_64_32 relocation
build/svumb: error while loading shared libraries: unexpected reloc type 0x0b

Do those messages make sense to anyone? What is a "R_X86_64_32 relocation"? 
What is a "reloc type"? What's happening??

Calling "sudo ldconfig" doesn't help.

The program uses the Qtah package, which is a Qt binding for Haskell. It 
might have something to do with this. It can't be linked statically, because 
then the following error occurs after starting the compiled and linked program:

.../build/svumb: error while loading shared libraries: libqtah.so.0: cannot open shared object file: No such file or directory

Compiling it dynamically had worked, but now I have the problem above.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20201017/c10ed84d/attachment.sig>

From kane at kane.cx  Sat Oct 17 13:20:14 2020
From: kane at kane.cx (David Kraeutmann)
Date: Sat, 17 Oct 2020 15:20:14 +0200
Subject: "... causes overflow in R_X86_... relocation"
In-Reply-To: <d1d9f3846d3831f8e08fa8feddf838c534267722.camel@volker-wysk.de>
References: <d1d9f3846d3831f8e08fa8feddf838c534267722.camel@volker-wysk.de>
Message-ID: <CAJ8B99wO6FWC-iTW1FtcG6kyuBbEys2+cYe1F_CBEK5PwHoXmg@mail.gmail.com>

Relocation is part of the linking process. Specifically, external
function calls must be given a real run-time address instead of some
placeholder.

R_X86_64_32 is a particular type of relocation, where the relocation
address is a 32-bit field.

I believe this might be caused by Qtah being built without -fPIC.

On Sat, Oct 17, 2020 at 2:42 PM Volker Wysk <post at volker-wysk.de> wrote:
>
> Hi.
>
> I have a litte program named "svumb", which compiles and links without error
> or warning message. But when I start it, this happens:
>
> build/svumb: Symbol `qtahzmqt5zm0zi7zi0zm4ATcbzzMngNWCbnemaqWUdM_GraphicsziUIziQtahziGeneratedziWidgetsziQMessageBox_setText_closure' causes overflow in R_X86_64_32 relocation
> (... long list of similar messages ...)
> build/svumb: Symbol `stg_INTLIKE_closure' causes overflow in R_X86_64_32 relocation
> build/svumb: error while loading shared libraries: unexpected reloc type 0x0b
>
> Do those messages make sense to anyone? What is a "R_X86_64_32 relocation"?
> What is a "reloc type"? What's happening??
>
> Calling "sudo ldconfig" doesn't help.
>
> The program uses the Qtah package, which is a Qt binding for Haskell. It
> might have something to do with this. It can't be linked statically, because
> then the following error occurs after starting the compiled and linked program:
>
> .../build/svumb: error while loading shared libraries: libqtah.so.0: cannot open shared object file: No such file or directory
>
> Compiling it dynamically had worked, but now I have the problem above.
>
> Regards,
> Volker
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

From post at volker-wysk.de  Sat Oct 17 15:49:39 2020
From: post at volker-wysk.de (Volker Wysk)
Date: Sat, 17 Oct 2020 17:49:39 +0200
Subject: "... causes overflow in R_X86_... relocation"
In-Reply-To: <CAJ8B99wO6FWC-iTW1FtcG6kyuBbEys2+cYe1F_CBEK5PwHoXmg@mail.gmail.com>
References: <d1d9f3846d3831f8e08fa8feddf838c534267722.camel@volker-wysk.de>
 <CAJ8B99wO6FWC-iTW1FtcG6kyuBbEys2+cYe1F_CBEK5PwHoXmg@mail.gmail.com>
Message-ID: <b65cd53a6abc1c5d468d15cb107ac5e9a3190279.camel@volker-wysk.de>

Am Samstag, den 17.10.2020, 15:20 +0200 schrieb David Kraeutmann:
> Relocation is part of the linking process. Specifically, external
> function calls must be given a real run-time address instead of some
> placeholder.
> 
> R_X86_64_32 is a particular type of relocation, where the relocation
> address is a 32-bit field.

I understand now.

> I believe this might be caused by Qtah being built without -fPIC.

This is managed by Cabal. I see no easy way to rebuild it with -fPIC. Cloning 
the sources from Gitlab and doing the full build would probably be overkill. 

I've mailed Bryan Gardiner, the author of Qtah with a brief description of
what is wrong. I'll do a full bug report, when requested.

Maybe I'll switch to WxHaskell.

Cheers,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20201017/aaeb330d/attachment.sig>

From david.feuer at gmail.com  Sat Oct 31 17:07:11 2020
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 31 Oct 2020 13:07:11 -0400
Subject: Language extension histories
Message-ID: <CAMgWh9tEN5R_9Rp5nAgPwi+JTzoFBg7UGBLE2=mkcWV4+A26qQ@mail.gmail.com>

I'm working on some code I want to be compatible with multiple GHC versions
and I'm trying to figure out which language extensions I can reasonably
use. I definitely need usable fancy pattern synonyms (not the bare-bones
ones in 7.8). So that should set a lower bound, but I don't remember where.
7.10? 8.0? I'd also *like* to use an injective type family, but I can work
around that pretty easily with a data family if necessary. When did
PatternSynonyms and TypeFamilyDependencies each become reasonably usable?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20201031/c239f2df/attachment.html>