HLS wrapper is dynamically linked in 1.6.0 release

[sonowz]

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?

[sonowz]

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]

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

[nartamonov]

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]

@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]

• 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 versionwas 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]

@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]

• 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]

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]

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

[hasufell]

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