Dynamic linking problems? #1160
Comments
jneira
added
type: bug
|
Is The Maybe you can work around it by manually adding You could also try your own dynamic build of haskell-language-server-8.8.3. |
|
Oh man. I upgraded to HLS 0.8.0 (using @adamse And where would I build the dynamic build of HLS-8.8.3? |
|
you can build it from source, maybe that alone could work |
|
Ok, so... that's managed to fix this, and I'm not sure what the cause was but building HLS-0.8.0 from source seems to have worked. |
|
Woops, seems like I screwed up... I think I've tried the source-built HLS in a different branch. The branch that I had trouble with still has the same |
|
I suspected it had something to do with the (but the above times five (x 5) with the |
|
Bit more fiddlin' around. Doesn't seem to be the version difference. It's something in our code (because it's really just this one branch, when given the same |
|
Have you tried building a dynamically linked |
@mpickering If you could tell me how, I'd appreciate it. Would that work with just |
|
@Vlix I'm not sure if this is of any help, I had the same kind of problem and I had to do the following to get it working:
diff --git a/haskell-language-server.cabal b/haskell-language-server.cabal
index dcc4a6c..1e6a2c9 100644
--- a/haskell-language-server.cabal
+++ b/haskell-language-server.cabal
@@ -70,7 +70,7 @@ library
, shake
, unordered-containers
- ghc-options: -Wall -Wredundant-constraints -Wno-name-shadowing
+ ghc-options: -Wall -Wredundant-constraints -Wno-name-shadowing -dynamic
if flag(pedantic)
ghc-options: -Werror
@@ -273,7 +273,7 @@ executable haskell-language-server
other-modules: Plugins
ghc-options:
- -threaded -Wall -Wno-name-shadowing -Wredundant-constraints
+ -threaded -Wall -Wno-name-shadowing -Wredundant-constraints -dynamic
-- allow user RTS overrides
-rtsopts
-- disable idle GC
@@ -320,7 +320,7 @@ executable haskell-language-server-wrapper
other-modules: Paths_haskell_language_server
autogen-modules: Paths_haskell_language_server
ghc-options:
- -threaded -Wall -Wno-name-shadowing -Wredundant-constraints
+ -threaded -Wall -Wno-name-shadowing -Wredundant-constraints -dynamic
-- allow user RTS overrides
-rtsopts
-- disable idle GC
Hopefully this helps 🤞 |
|
Ok, I don't want to celebrate prematurely again, but building it with the |
|
BONUS BUG When I make a block comment like this: import Tracing.NewRelic as NewRelic (
{- DatastoreSegment(..)
, DatastoreSegmentProduct(Postgres)
, -} Segment
, Transaction
)The output of HLS will print the following: In an active session, this won't be much of a problem, AFAICT, but when loading VSCode with this block comment, HLS seems to restart 5 times and then quit. |
|
FYI, that bug comes from the Eval plugin parser. |
|
FWIW, this problem comes from an issue with GHC's built-in linker. When you link the executable dynamically then GHC uses the system linker which is more robust. Usually you don't see this problem as GHC itself is usually distributed dynamically linked. |
|
There are several issues similar to this one, this should be mentioned in the troubleshooting section of readme with the suggestion made by @pepeiborra here:
|
|
Is there a section somewhere with like an FAQ, or Troubleshooting for known workarounds? So that someone who has a problem can go there and see what might be the problem and if it already has a fix, before adding an issue; and maybe link to the main issue for that workaround so people can chime in that they've hit that problem too? |
Sure! https://github.com/haskell/haskell-language-server#troubleshooting, pr's welcome! 🙂 |
|
My GHC version is However, when I execute Anyone know what might be going on here? |
|
I am afraid that ghc version install targets depends on the existence of a stack-ghcVersion.yaml |
|
Ah, got it. I'm using a nix-shell based on https://github.com/input-output-hk/plutus/blob/master/shell.nix and to my understanding the GHC version used by that project is 8.10.4 (though I'm still learning all about nix and haskell so my understanding might be totally off). |
|
oh, I see, another option could be check out 1.4.0 tag which still has the required stack.yaml |
|
thanks for the tip! I'll give that a shot! Though I just stumbled on docs in the Plutus community which suggest that the |
|
We have a specific section in troubleshooting about dynamic linking now and several ways to build hls from source dinamically including ghcup. So i am gonna clos this one, thanks for the report |
Not sure if this is an HLS issue, but building with stack itself works fine, so somewhere something is off.
The main problem seems to be somehow related to how we've built the
tracing-newrelicpackage. I've added the LSP logs to show what's happening.A few things to keep in mind:
/home/user/project/scripts/files/libnewrelic.ais soft linked from/lib/libnewrelic.alibnewrelic.afromscripts/files, I get the following error:stack buildorstack ghciworks finehls --debugsnippet below, there are way more, but most only have the messageProgram Error:I don't get why it doesn't work. If anyone could help me out, that'd be great!
A snippet from [haskell-language-server --debug]
LSP logs:
The text was updated successfully, but these errors were encountered: