-
-
Notifications
You must be signed in to change notification settings - Fork 367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Thread-local variable relocation issue on FreeBSD 12 #1482
Comments
You should try building a dynamic version of hls. I am not sure why this isn't the default given that it is the default for GHC. |
@mpickering how would you make it the default without subverting Cabal? |
I think adding |
Could we still distribute static binaries then? |
Building it dynamic solves the problem:
But at the cost of an enormous library RPATH (via
I'm willing to got with that for my own machine, but there should be some way of consolidating the dependencies into a single lib directory with multiple ".so" files. That's likely a Cabal issue, not HLS. On a separate note, I am still rather confused by the apparently non-fatal error message:
What's that all about? |
I think we won't, we could not upload it to the repo. Maybe we should add to documentation, in the install section a note about freebsd mentioning it should be build with |
The dynamic version would need a bunch of work to ensure a robust search path for the dependency. I am not sure Cabal is presently entirely up to the task. So yes, static by default, and either a note for FreeBSD users, or someone actually figures out how to handle the new relocation in |
@vdukhovni nice, could you make a pr to update the readme noting the actual requirements and caveats installing hls in freebsd? |
Can I offer you a "horse trade"? I'll commit to doing the FreeBSD README update, if you can help me figure out the more mundane issue mentioned at the bottom of: #1482 (comment) |
Thanks, got a clean run with no crashes. I owe you some FreeBSD text...
|
I guess I still owe you a writeup, but in the meantime, I believe I've addressed the issue for future GHC releases (don't know whether a backport to 9.2 or earlier is appropriate). The rts linker code could perhaps use some refactoring, but that should be a separate MR... |
This can be included in the issues related with the ghc runtime linker, they are summarized here: #2000 and #1431 |
Your environment
Output of
haskell-language-server --probe-tools
orhaskell-language-server-wrapper --probe-tools
:Which lsp-client do you use: vim
Describe your project (alternative: link to the project): Small Cabal project using PCRE (direct cause of relocation issue)
Contents of
hie.yaml
:Steps to reproduce
Just run HLS in project directory.
It first reports an error that appears to be non-fatal:
but ultimately fails with:
This is because on FreeBSD the ".a" file contains objects with symbols that require
R_X86_64_TLSGD(19)
relocation type, which is not handled by GHC's RTS linker.Expected behaviour
Load the
regex-pcre-builtin
without relocation errors. Note that in the same directory as the problem ".a" file is also a ".so" shared object for the same library, and it would not run into the same relocation issue (contains to symbols requiring unsupported relocation types):It is not obvious why HLS is loading the ".a" and not the ".so" (perhaps there's a good reason).
Include debug information
Execute in the root of your project the command
haskell-language-server --debug .
and paste the logs here:Debug output:
The text was updated successfully, but these errors were encountered: