Unhandled ELF relocation(RelA) type 42 when using ArchLinux #762
Comments
|
I've experienced this on Debian sid too, I don't remember if it was reloc type 42 or something else but other than that. I tracked it down to a change in GNU LD tripping up the dynamic linker in GHCi, the weird thing is that the reloc type I was looking at was added quite a few years ago so it's strange the error is only popping up now. Maybe Stack is defaulting to dynamic linking whereas Cabal does static linking by default? I'm not actually sure what the defaults are though. Anyways I'd try disabling dynamic linking. |
|
I'm facing this problem as well, but with the |
|
Hmm, looks like I was wrong. I could've sworn there is a Since I can't think of any other workaround we'll have to report this upstream instead. Can you try loading an affected package in ghci and see if that break too? If that's the case reporting this is easy, if it is something ghc-mod specific though then I'll have to give it a closer look.
|
|
Hi, I'm also experiencing this problem on Arch (unhandled ELF relocation(RelA) type 42 unable to load package yaml-0.8.16). |
|
My experiments with |
|
I also just encountered this on Arch with the package persistent-sqlite-2.2 (so It's also curious that this only started happening in the last several days. A few days earlier I was able to |
|
@waldheinz If it's related to TH you can try passing |
|
I'm also experiencing this problem on a new Ubuntu 16.04 installation, for the |
|
@DanielG |
|
@DanielG Same for me, though I'm not sure if I'm testing correctly. Here is what I do: Is this enough to say that it works? |
|
Happening to me as well with |
|
I'm getting this on Arch Linux too. In my case I blew away all of my Are there any known workarounds for this? |
|
For arch linux, you can downgrade to 2016-02-21 and rebuild the cabal sandbox to get it working again. On an up to date Arch, I can reproduce it by creating a new project and sandbox, installing glib-0.13.2, and adding Removing the TemplateHaskell pragma or not installing glib makes it work correctly. One of the packages that was upgraded on 2016-02-21 was glibc, from 2.22-4 to 2.23-1, so that package may be the source of the problem. |
|
The source of this problem seems to be that gas >= 2.26 uses some new relocation types (in particular type 42, aka R_X86_64_REX_GOTPCRELX), which are not supported by ghc's linker. As a workaround, these relocation types can be disabled by invoking
It's probably necessary to reinstall all packages with this flag. Could |
|
@Sam142 Ah, that makes sense. I was just looking at the wrong component. I'm not aware of ghci being able to use the system linker is that something new or what exactly are you referring to? |
|
Never mind found the docs for that https://ghc.haskell.org/trac/ghc/wiki/DynamicGhcPrograms. |
Suggestion from: DanielG/ghc-mod#762 Addresses: IHaskell#636 I do not fully understand the implications of this change, but it fixed the problem for me (once I forced stack to rebuild `cryptonite`)
|
I'm seeing this error as well: I'm also using Is there a fix, other than using an older version of |
|
I'm facing the same problem with Using the ghc options [1] https://gist.github.com/jmaicher/6d8b0e692285e4fe4f68cade25cbf127 |
|
filed a ghc ticket here https://ghc.haskell.org/trac/ghc/ticket/12147 |
|
Is there a workaround for this? (it's unclear to me) I tried running: But it didn't help. |
|
Is there a way to reproduce this without stack? |
|
Patched in GHC with commit ghc/ghc@0d963ca Thanks for the report! |
|
What @Mistuke means is that is fixed in GHC git and will certainly be in GHC 8.0.2. The GHC developers may also consider rolling a GHC 7.10.4 release with this fix. |
|
Hmm, does anyone know if it's possible to use stack to install GHC git? (Alternatively, is there a way to tell when this patch makes it into a Stackage nightly build?) This problem is a bit of a blocker for me... |
|
@thomasjm I would suggest jumping on the ticket https://ghc.haskell.org/trac/ghc/ticket/12147 and (politely of course) requesting a 8.0.2 GHC release including this fix. If you also need ghc-7.10 fixed, I suggest asking for that as well. |
|
Can somebody please provide reproduction instructions for this bug. A possible workaround is to build |
|
I spent an hour last night trying to reproduce this but wasn't able to. |
|
Previously to reproduce this error, I ran: I haven't tested recently. |
|
@sjackman Sorry, but that is not very helpful. The reproduction instructions need to be as simple as possible. That means no docker, no brew. |
|
To be specific, the instructions need to be something simple enough to be use as a configure time test in GHC's |
|
To reproduce the issue install binutils 2.26, install GCC 5.3, install GHC 7.10.3b from source, then run |
|
I'm on Debian Testing, with: and the GHC 7.10.3b sources and I still can't reproduce it. |
|
Shucks. Thanks for trying anyway. I don't have time to look into this any further now. My workaround was to use Ubuntu 14 to compile GHC with binutils 2.24 and GCC to 4.8, and transfer the executables to my system. |
Commit c891a24 created a regression, ghc-options were no longer applied to packages in the snapshot. The "mini build plan" for missing snapshot packages did not check the configuration's "ghc-options" settings at all, so even configurations with "apply-ghc-options: everything" would not apply those options. This commit, combined with a change to config.yaml, fixes these issues: DanielG/ghc-mod#762 IHaskell/IHaskell#636 To fix those issues, (usually located in ) should contain: And for snapshots already installed, the following command will force stack to rebuild them with those options: *Not tested:* Alternatively, add the line to . This may cause undesirable behavior in forcing all ghc-options changes to rebuild the snapshot.
|
Everyone: I have found and fixed this issue, if you build Stack from my fork here: https://github.com/aaronfriel/stack you will be able to add And then you can force any packages that are causing trouble to rebuild with: Substituting $PACKAGENAME for the package causing a problem, of course :) To build and install my fork, just: |
|
Hi, Aaron. Can you clarify, is the option |
|
@sjackman: No, I was able to use a stock |
|
What's status of this? Still happening occasionally on Fedora |
|
@sigrlami: Fix is in still-unreleased ghc 8.0.2 branch. Until it's released, you can use the above |
|
I think this should be fixed upstream, so closing. |
I have repository which compiles OK both on Arch and Ubuntu using stack LTS 5. Repository Link. On Ubuntu, I can also
ghc-mod checkfiles without a problem, but on Arch I get:On Ubuntu, GHC is 7.10.3 downloaded during
stack setupand ghc-mod is compiled using it.On Arch, I tried both compiling GHC and ghc-mod, and using system packages for both. I get the same results.
Here is
ghc-mod debugfrom Arch:And
ghc-mod debugfrom Ubuntu VM:The text was updated successfully, but these errors were encountered: