HLS wrapper is dynamically linked in 1.6.0 release #2650

sonowz · 2022-01-29T06:27:56Z

How to reproduce

$ ldd haskell-language-server-wrapper-Linux
        linux-vdso.so.1 (0x00007ffd73dcd000)
        libpthread.so.0 => /nix/store/gk42f59363p82rg2wv2mfy71jn5w4q4c-glibc-2.32-48/lib/libpthread.so.0 (0x00007fca15b71000)
        libz.so.1 => not found
        libtinfo.so.5 => not found
        librt.so.1 => /nix/store/gk42f59363p82rg2wv2mfy71jn5w4q4c-glibc-2.32-48/lib/librt.so.1 (0x00007fca15b66000)
        libutil.so.1 => /nix/store/gk42f59363p82rg2wv2mfy71jn5w4q4c-glibc-2.32-48/lib/libutil.so.1 (0x00007fca15b61000)
        libdl.so.2 => /nix/store/gk42f59363p82rg2wv2mfy71jn5w4q4c-glibc-2.32-48/lib/libdl.so.2 (0x00007fca15b5c000)
        libgmp.so.10 => not found
        libc.so.6 => /nix/store/gk42f59363p82rg2wv2mfy71jn5w4q4c-glibc-2.32-48/lib/libc.so.6 (0x00007fca15999000)
        libm.so.6 => /nix/store/gk42f59363p82rg2wv2mfy71jn5w4q4c-glibc-2.32-48/lib/libm.so.6 (0x00007fca15856000)
        /lib64/ld-linux-x86-64.so.2 => /nix/store/gk42f59363p82rg2wv2mfy71jn5w4q4c-glibc-2.32-48/lib64/ld-linux-x86-64.so.2 (0x00007fca15b94000)

Expected behavior

$ ldd haskell-language-server-wrapper-1.5.1-linux
        not a dynamic executable

Description

In 1.6.0, HLS wrapper is a dynamically linked binary, while 1.5.1 wrapper being statically linked binary. Is this intended?

The text was updated successfully, but these errors were encountered:

sonowz · 2022-01-29T06:30:17Z

NixOS-specific notes

This is causing errors in NixOS environment, where basically dynamic linking is not supported:

$ ./haskell-language-server-wrapper-Linux
./haskell-language-server-wrapper-Linux: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

HLS binary itself, as opposed to wrapper, works well in NixOS.

Also, it is worth noting for NixOS users who try to manually link libtinfo.so.5: this seems somewhat painful work in current NixOS, due to this nixpkgs issue.

mystilleef · 2022-01-29T12:34:09Z

Yeap, same problem on Fedora Linux 35. The workaround as noted above is to not use the wrapper.

nartamonov · 2022-01-29T12:40:22Z

The same problem when running in docker container of Debian 10.11:

Couldn't figure out what GHC version the project is using: /home/vscode/.vscode-server/data/User/globalStorage/haskell.haskell/haskell-language-server-wrapper-1.6.0.0-linux --project-ghc-version exited with exit code 127: /home/vscode/.vscode-server/data/User/globalStorage/haskell.haskell/haskell-language-server-wrapper-1.6.0.0-linux: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory

vscode ➜ ~/…/User/globalStorage/haskell.haskell $ cat /etc/debian_version 
10.11
vscode ➜ ~/…/User/globalStorage/haskell.haskell $ ldd haskell-language-server-wrapper-1.6.0.0-linux 
        linux-vdso.so.1 (0x00007ffe069f1000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f36201ac000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f361ff8e000)
        libtinfo.so.5 => not found
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f361ff84000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f361ff7f000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f361ff7a000)
        libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f361fef5000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f361fd34000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f361fbb1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f36201d4000)

Seems like Debian 10 have more recent version of libtinfo6 only:

vscode ➜ ~/…/User/globalStorage/haskell.haskell $ sudo apt list --installed | grep libtinfo
libtinfo-dev/oldstable,now 6.1+20181013-2+deb10u2 amd64 [installed]
libtinfo6/oldstable,now 6.1+20181013-2+deb10u2 amd64 [installed,automatic]

Manually installing package libtinfo5 fixes the problem:

vscode ➜ ~/…/User/globalStorage/haskell.haskell $ sudo apt install libtinfo5
vscode ➜ ~/…/User/globalStorage/haskell.haskell $ ldd haskell-language-server-wrapper-1.6.0.0-linux
        linux-vdso.so.1 (0x00007fff3e5e4000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f441bc74000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f441ba56000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f441ba2a000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f441ba20000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f441ba1b000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f441ba16000)
        libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f441b991000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f441b7d0000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f441b64d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f441bc9c000)

The last version of ncurses 5.11 was released in 2011, so I think it considered as outdated. 6.0 is available since 2015.

jneira · 2022-01-29T13:47:55Z

@sonowz @mystilleef @nartamonov sad to see the wrapper (and only the wrapper 🤔) is causing problems to you
could you confirm if the hls-wrapper you are checking is the downloaded here: https://github.com/haskell/haskell-language-server/releases/download/1.6.0.0/haskell-language-server-wrapper-Linux.gz?

At a first quick look i've checked the size of the first wrapper is 27 mb and in 1.5.1/1.5.0 was only 8 mb, so a clear signal they were not built the same way.

I am revising all the config files to trace where could be the difference

jneira · 2022-01-29T13:58:54Z

From the ci build supposed to produce the wrapper in 1.5.1 (https://github.com/haskell/haskell-language-server/runs/4347661710?check_suite_focus=true):

cabal build exe:hls-wrapper -O2 $LINUX_CABAL_ARGS
  shell: /bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    LINUX_CABAL_ARGS: --enable-executable-static --ghc-options=-split-sections
    GHC_VERSION: 8.10.7
Build profile: -w ghc-8.10.7 -O2

and the we can see lot of linker warningslike:

/home/runner/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/process-1.6.13.2/libHSprocess-1.6.13.2.a(fork_exec.o):fork_exec.c:function do_spawn_fork: warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

From the build which generated hls-wrapper in the 1.6.0.0 release (https://github.com/haskell/haskell-language-server/runs/4979993520?check_suite_focus=true):

  cabal build exe:hls-wrapper -O2 $LINUX_CABAL_ARGS
  shell: /bin/sh -e {0}
  env:
    CABAL_PKGS_DIR: ~/.cabal/packages
    INDEX_STATE: 2022-01-24T21-03-03Z
    CABAL_ARGS: --enable-executable-static --ghc-options=-split-sections

And no linker warnings

So same os ubuntu-18.04, ~~same cabal version~~was cabal-3.4.1.0 and now cabal-3.6.2.0, same cabal args (notably --enable-executable-static), i have to revise other config files which could affected the build

nartamonov · 2022-01-29T14:02:12Z

@jneira I've checked the wrapper by your link. It also has the dynamic dependency on libtinfo.so.5:

vscode ➜ ~/tmp $ wget https://github.com/haskell/haskell-language-server/releases/download/1.6.0.0/haskell-language-server-wrapper-Linux.gz

haskell-language-server-wrapper-Linux.gz        100%[======================================================================================================>]  27.12M  2.97MB/s    in 9.2s    

2022-01-29 13:52:53 (2.95 MB/s) - ‘haskell-language-server-wrapper-Linux.gz’ saved [28432491/28432491]

vscode ➜ ~/tmp $ gzip -d haskell-language-server-wrapper-Linux.gz 
vscode ➜ ~/tmp $ chmod +x haskell-language-server-wrapper-Linux 
vscode ➜ ~/tmp $ ldd haskell-language-server-wrapper-Linux 
        linux-vdso.so.1 (0x00007ffcdc8f3000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4203740000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4203522000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f42034f6000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f42034ec000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f42034e7000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f42034e2000)
        libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f420345d000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f420329c000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4203119000)
        /lib64/ld-linux-x86-64.so.2  #(0x00007f4203768000)

jneira · 2022-01-29T14:17:30Z

github virtual envs (dont see what could have affected):
- 1.5.1: https://github.com/actions/virtual-environments/blob/ubuntu18/20211122.1/images/linux/Ubuntu1804-README.md
- 1.6.0.0: https://github.com/actions/virtual-environments/blob/ubuntu18/20220123.1/images/linux/Ubuntu1804-Readme.md
cabal.project (afaics they ae identical):
- 1.5.1: https://github.com/haskell/haskell-language-server/blob/1.5.1/cabal.project
- 1.6.0.0: https://github.com/haskell/haskell-language-server/blob/1.6.0.0/cabal.project
workflow files
- 1.5.1: https://github.com/haskell/haskell-language-server/actions/runs/1513707786/workflow
- 1.6.0.0: https://github.com/haskell/haskell-language-server/actions/runs/1760987798/workflow
  - this one uses a new github action: https://github.com/haskell/haskell-language-server/blob/1.6.0.0/.github/actions/setup-build/action.yml
- afaics a possible change could affect the build is the build now reuses the cache of other workflows and in 1.5.1 the build was done from a clean cabal cache. Dont know how exactly could it affect the linking 🤔
- other change has been moving cabal from 3.4.1.0 to 3.6.1.0

jneira · 2022-01-29T14:25:10Z

We had some errors with libtinfo.so.5 building the wrapper which will be relevant: https://github.com/haskell/haskell-language-server/runs/4979082407?check_suite_focus=true but it was fixed in a second attempt (already linked)
@hasufell took a look here: haskell/ghcup-metadata#18

jneira · 2022-01-29T15:46:45Z

@pepeiborra has found the culprit: #2615 (comment)
will make a new release with the fix asap 🤦‍♂️

hasufell · 2022-01-29T18:08:25Z

The last version of ncurses 5.11 was released in 2011, so I think it considered as outdated. 6.0 is available since 2015.

Version 5 is still widely used and available in all major distros, including debian.

Yeap, same problem on Fedora Linux 35. The workaround as noted above is to not use the wrapper.

dnf install ncurses-compat-libs

jneira · 2022-01-29T19:02:41Z

I've tried #2647 and it produced this hls-wrapper: https://github.com/jneira/haskell-language-server/suites/5108226219/artifacts/153040660, which is statically linked as expected

jneira · 2022-01-29T21:39:49Z

The 1.6.1.0 release has started: https://github.com/haskell/haskell-language-server/releases/tag/1.6.1.0

github build: https://github.com/haskell/haskell-language-server/actions/runs/1766869807
hackage build: https://github.com/haskell/haskell-language-server/actions/runs/1766875857
gitlab build: https://gitlab.haskell.org/haskell/haskell-language-server/-/pipelines/46730

jneira · 2022-01-30T10:57:28Z

I ve just released 1.6.1.0 with a statically linked wrapper
@hasufell will do the needed steps for the ghcup release asap

jneira · 2022-01-30T11:31:26Z

Versions released to hackage:
- https://hackage.haskell.org/package/haskell-language-server-1.6.1.0
- https://hackage.haskell.org/package/hls-tactics-plugin-1.6.1.0

jneira · 2022-01-30T19:03:26Z

And 1.6.1.0 is also in ghcup after merging haskell/ghcup-metadata#20

Thanks all reporters for the quick feedback and sorry for the inconveniences

sonowz added status: needs triage type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc.. labels Jan 29, 2022

jneira added old_type: distribution and removed status: needs triage labels Jan 29, 2022

jneira mentioned this issue Jan 29, 2022

Post 1.6.0.0 fixes and prepare 1.6.1.0 bug fix release #2647

Merged

jneira added the can-workaround label Jan 29, 2022

mergify bot closed this as completed in #2647 Jan 29, 2022

Anton-Latukha mentioned this issue Jan 29, 2022

wrapper requires libtinfo.so.5, which is not present on Arch Linux-based distros #2657

Closed

jneira reopened this Jan 30, 2022

jneira closed this as completed Jan 30, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

HLS wrapper is dynamically linked in 1.6.0 release #2650

HLS wrapper is dynamically linked in 1.6.0 release #2650

sonowz commented Jan 29, 2022

sonowz commented Jan 29, 2022 •

edited

Loading

mystilleef commented Jan 29, 2022

nartamonov commented Jan 29, 2022 •

edited

Loading

jneira commented Jan 29, 2022 •

edited

Loading

jneira commented Jan 29, 2022 •

edited

Loading

nartamonov commented Jan 29, 2022

jneira commented Jan 29, 2022 •

edited

Loading

jneira commented Jan 29, 2022 •

edited

Loading

jneira commented Jan 29, 2022

hasufell commented Jan 29, 2022

jneira commented Jan 29, 2022 •

edited

Loading

jneira commented Jan 29, 2022

jneira commented Jan 30, 2022

jneira commented Jan 30, 2022

jneira commented Jan 30, 2022

HLS wrapper is dynamically linked in 1.6.0 release #2650

HLS wrapper is dynamically linked in 1.6.0 release #2650

Comments

sonowz commented Jan 29, 2022

How to reproduce

Expected behavior

Description

sonowz commented Jan 29, 2022 • edited Loading

NixOS-specific notes

mystilleef commented Jan 29, 2022

nartamonov commented Jan 29, 2022 • edited Loading

jneira commented Jan 29, 2022 • edited Loading

jneira commented Jan 29, 2022 • edited Loading

nartamonov commented Jan 29, 2022

jneira commented Jan 29, 2022 • edited Loading

jneira commented Jan 29, 2022 • edited Loading

jneira commented Jan 29, 2022

hasufell commented Jan 29, 2022

jneira commented Jan 29, 2022 • edited Loading

jneira commented Jan 29, 2022

jneira commented Jan 30, 2022

jneira commented Jan 30, 2022

jneira commented Jan 30, 2022

sonowz commented Jan 29, 2022 •

edited

Loading

nartamonov commented Jan 29, 2022 •

edited

Loading

jneira commented Jan 29, 2022 •

edited

Loading

jneira commented Jan 29, 2022 •

edited

Loading

jneira commented Jan 29, 2022 •

edited

Loading

jneira commented Jan 29, 2022 •

edited

Loading

jneira commented Jan 29, 2022 •

edited

Loading