haskell-language-server icon indicating copy to clipboard operation
haskell-language-server copied to clipboard

HLS report error but project is built just find

Open k355l3r-5yndr0m3 opened this issue 3 years ago • 1 comments

Archlinux: 5.18.16-arch1-1 GHC 9.2.2 (installed using ghcup) Neovim + nvim-lspconfig

I'm working on a pet project that requires linking to intel mkl. I uses cabal and I don't think I configure anything wrong because it compiles successfully. But opening any files and hls will report an error at the top of the file saying. Unexpected usage error user specified .o/.so/.DLL could not be loaded (/opt/intel/mkl/lib/intel64/libmkl_intel_lp64.so: undefined symbol: mkl_blas_dgemm) Whilst trying to load: (dynamic) /opt/intel/mkl/lib/intel64/libmkl_intel_lp64.so Additional directories searched: /opt/intel/mkl/lib/intel64 /opt/intel/oneapi/compiler/2022.1.0/linux/compiler/lib/intel64_lin Is there anyway to make this go away or at least ignore it.

k355l3r-5yndr0m3 avatar Aug 14 '22 06:08 k355l3r-5yndr0m3

Could you share the project or at least the cabal file/dependencies of the project you are using? Does it have a legitimate dependency on /opt/intel/mkl/lib/intel64/libmkl_intel_lp64.so?

wz1000 avatar Sep 07 '22 11:09 wz1000

Pretty sure I've encountered the same problem.

Unexpected usage error
user specified .o/.so/.DLL could not be loaded (libiothub_client_mqtt_transport.so: cannot open shared object file: No such file or directory)
Whilst trying to load:  (dynamic) iothub_client_mqtt_transport
Additional directories searched: (none)

Project builds fine. The strange thing is that I get this error only on some source files on the project - and I haven't recognized any pattern for now which files succeed and which files fail. The cabal file has for sure the dependency to iothub_client_mqtt_transport:

  extra-libraries:
      iothub_client_mqtt_transport
      iothub_client
      parson

However the during normal build things are statically linked (and not even for every library a dynamic variant exists). The base problem - to my assumption - is that HLS even tries to dynamically load the modules - however for type checking this doesn't seem to be necessary. While understanding that not all functionality of HLS (e.g. evaluation of code snippets) could work in this scenario, it's definitely problematic that HLS more or less completely denies its service.

I hope that helps you to better assess the problem and I also hope it's ok that I share my experience in this issue. Please let me know if I could provide further details.

alaendle avatar Oct 18 '22 09:10 alaendle

Loading of code for TH has changed somewhat, so I'm going to tentatively close this as stale unless it's reproducible.

michaelpj avatar Mar 22 '23 12:03 michaelpj