Projects setting "-dynamic" don't play well with the extension

[LeventErkok]

I've a project that I have to compile as a dynamically loaded library, i.e., with GHC's -dynamic flag.

Unfortunately, this doesn't do well with VSCode. I see the following printed in the "PROBLEMS" tab:

Program error: 
    Cannot load -dynamic objects when GHC is built the normal way
    To fix this, either:
      (1) Use -fexternal-interpreter, or
      (2) Build the program twice: once the normal way, and then
          with -dynamic using -osuf to set a different object file suffix.

Is there a known workaround for this problem?

[jneira]

I don't use -dynamic, but just in case, have you tried the first option? you could add as ghc-options in the .cabal file

[LeventErkok]

@jneira This seems to solve the issue. Thanks!

[jneira]

Reopened cause -fexternal-interpreter is not supported by hls

[jneira]

@LeventErkok sorry, the first optionn suggested by the compiler is not supported yet by hls.
Could you link to the repo, to try reproduce the problem? It would help to eventually fix it.
The entire log output of the extension could be helpful too (output pane, choose Haskell (projectName)):

[LeventErkok]

@jneira Unfortunately the original repo is not publically available; but I suspect any project that compiles with -dynamic flag would exhibit this behavior?

[berberman]

Ah, after switching from stack to cabal, I encountered this issue. My project url is https://github.com/berberman/arch-hs. I am using archlinux operating system, in order to use haskell packages provided by system, which are built dynamically, cabal should be configured with:
~/.cabal/config:

library-vanilla: False
shared: True
executable-dynamic: True
program-default-options
  ghc-options: -dynamic

Debug log

(haskell-language-server)Ghcide setup tester in /home/berberman/Desktop/arch-hs.
Report bugs at https://github.com/haskell/haskell-language-server/issues

Tool versions found on the $PATH
cabal:		3.2.0.0
stack:		Not found
ghc:		8.10.2


Step 1/4: Finding files to test in /home/berberman/Desktop/arch-hs
Found 23 files

Step 2/4: Looking for hie.yaml files that control setup
Found 1 cradle

Step 3/4: Initializing the IDE

Step 4/4: Type checking the files
[INFO] Consulting the cradle for "/home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/PP.hs"
[INFO] Using interface files cache dir: /home/berberman/.cache/ghcide/arch-hs-0.1.1.0-inplace-7b099eca9e9123d3060cfbd5af4acd31f1806eb4
[INFO] Making new HscEnv[arch-hs-0.1.1.0-inplace]
[INFO] Consulting the cradle for "/home/berberman/Desktop/arch-hs/submit/Main.hs"
[INFO] Using interface files cache dir: /home/berberman/.cache/ghcide/main-1ecf6ad58acb9f3ae89df3f594e1df41056c81c9
[INFO] Using interface files cache dir: /home/berberman/.cache/ghcide/arch-hs-0.1.1.0-inplace-6b21ddf7b4477a5e231ed764b7be2fefef30f68c
[INFO] Making new HscEnv[main,arch-hs-0.1.1.0-inplace]
[INFO] Consulting the cradle for "/home/berberman/Desktop/arch-hs/app/Args.hs"
[INFO] Using interface files cache dir: /home/berberman/.cache/ghcide/main-301352d3afd9354bfd7bbc85f8d04e2e35331a28
[INFO] Using interface files cache dir: /home/berberman/.cache/ghcide/main-301352d3afd9354bfd7bbc85f8d04e2e35331a28
[INFO] Using interface files cache dir: /home/berberman/.cache/ghcide/arch-hs-0.1.1.0-inplace-28d8f587481a57fe444e1dee7a96fed3e40fce15
[INFO] Making new HscEnv[main,main,arch-hs-0.1.1.0-inplace]
[INFO] Consulting the cradle for "/home/berberman/Desktop/arch-hs/diff/Diff.hs"
[INFO] Using interface files cache dir: /home/berberman/.cache/ghcide/main-14cfa45c2f601a261c3224dcb3e2e17a71f4baa9
[INFO] Using interface files cache dir: /home/berberman/.cache/ghcide/main-14cfa45c2f601a261c3224dcb3e2e17a71f4baa9
[INFO] Using interface files cache dir: /home/berberman/.cache/ghcide/main-14cfa45c2f601a261c3224dcb3e2e17a71f4baa9
[INFO] Using interface files cache dir: /home/berberman/.cache/ghcide/arch-hs-0.1.1.0-inplace-ae2ef6eaefc14bc76c4f94ee1e5f71bd7e8072f9
[INFO] Making new HscEnv[main,main,main,arch-hs-0.1.1.0-inplace]
[INFO] Consulting the cradle for "/home/berberman/Desktop/arch-hs/Setup.hs"
File:     /home/berberman/Desktop/arch-hs/Setup.hs
Hidden:   no
Range:    1:0-2:0
Source:   cradle
Severity: DsError
Message: 
  �[0;91mMulti Cradle: No prefixes matched
  pwd: /home/berberman/Desktop/arch-hs
  filepath: /home/berberman/Desktop/arch-hs/Setup.hs
  prefixes:
  ("./app",Cabal {component = Just "arch-hs:exe:arch-hs"})
  ("./diff",Cabal {component = Just "arch-hs:exe:arch-hs-diff"})
  ("./submit",Cabal {component = Just "arch-hs:exe:arch-hs-submit"})
  ("./src",Cabal {component = Just "arch-hs"})�[0m
File:     /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/PkgBuild.hs
Hidden:   no
Range:    1:0-2:0
Source:   typecheck
Severity: DsError
Message: 
  �[0;91mProgram error: /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/PkgBuild.hs:154:3: fatal:
  Cannot load -dynamic objects when GHC is built the normal way
  To fix this, either:
  (1) Use -fexternal-interpreter, or
  (2) Build the program twice: once the normal way, and then
  with -dynamic using -osuf to set a different object file suffix.�[0m
File:     /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/Types.hs
Hidden:   no
Range:    1:0-2:0
Source:   typecheck
Severity: DsError
Message: 
  �[0;91mProgram error: /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/Types.hs:1:1: fatal:
  Cannot load -dynamic objects when GHC is built the normal way
  To fix this, either:
  (1) Use -fexternal-interpreter, or
  (2) Build the program twice: once the normal way, and then
  with -dynamic using -osuf to set a different object file suffix.�[0m
Files that failed:
[INFO] finish: User TypeCheck (took 2.13s) * /home/berberman/Desktop/arch-hs/Setup.hs

 * /home/berberman/Desktop/arch-hs/app/Args.hs
 * /home/berberman/Desktop/arch-hs/app/Main.hs
 * /home/berberman/Desktop/arch-hs/diff/Diff.hs
 * /home/berberman/Desktop/arch-hs/diff/Main.hs
 * /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/Aur.hs
 * /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/Community.hs
 * /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/Core.hs
 * /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/Exception.hs
 * /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/Hackage.hs
 * /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/Local.hs
 * /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/Name.hs
 * /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/OptionReader.hs
 * /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/PP.hs
 * /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/PkgBuild.hs
 * /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/Types.hs
 * /home/berberman/Desktop/arch-hs/src/Distribution/ArchHs/Utils.hs
 * /home/berberman/Desktop/arch-hs/submit/Main.hs
 * /home/berberman/Desktop/arch-hs/submit/Submit.hs

Completed (4 files worked, 19 files failed)

[pepeiborra]

I believe the reason dynamic doesn't work with ghcide is explained in this note:

What happens if we build a static executable and link in the GHC package? Can we use the interpreter? Currently the answer is yes, and we fall back to using the RTS linker in this case. (The converse also applies if static linking is the default).

If your codebase uses TH, ghcide will need to generate and load object files for all the imported modules of a module with TH. For this it needs to load the objects for all the packages that your project depends on. But these are shared objects, i.e. created by -dynamic, and the RTS linker is unable to load shared "-dynamic" objects so it fails.

My understanding is very limited though, so I might be wrong. /cc @adamse

Note that HLS is a static executable to simplify automated deployment via the VSCode extension. If you build your own HLS binary it wouldn't be a static executable by default and the above might not apply.

[adamse]

I think @pepeiborra's comment is correct and I think the proposed solution of building your own (dynamically linked) HLS should work.