"... causes overflow in R_X86_... relocation"

Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

"... causes overflow in R_X86_... relocation"

Volker Wysk
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: "... causes overflow in R_X86_... relocation"

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 believe this might be caused by Qtah being built without -fPIC.

On Sat, Oct 17, 2020 at 2:42 PM Volker Wysk <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: "... causes overflow in R_X86_... relocation"

Volker Wysk
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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

signature.asc (849 bytes) Download Attachment