Home > OS >  Why terminfo breaks my build on lack of versioned symbols in libtinfo.so?
Why terminfo breaks my build on lack of versioned symbols in libtinfo.so?

Time:08-19

terminfo-0.4.1.4 breaks a build of hls not finding a specific version of some symbols from libtinfo.so, one of them being tigetnum.

There is also this warning, which I see when building other programs:

/lib64/libtinfo.so.5: no version information available (required by terminfo-0.4.1.4/libHSterminfo-0.4.1.4-ghc8.10.7.so)

The following is an error that breaks building of haskell-language-server:

terminfo-0.4.1.4/libHSterminfo-0.4.1.4-ghc8.10.7.so: error: undefined reference to 'tigetnum', version 'NCURSES_TINFO_5.0.19991023'

This is using versioned symbols feature of gcc stack, where you can have symbols with different versions in the same ELF file. However, my copy of libtinfo.so does not have versioned symbols and I don't see anything in terminfo code on github that would indicate it is requiring versioned symbols: that said I am not sure what I should be looking for, just grepped the srcs for the version.

objdump -x invoked on libHSterminfo-0.4.1.4-ghc8.10.7.so:

Version definitions:
1 0x01 0x057dc17f libHSterminfo-0.4.1.4-ghc8.10.7.so

Version References:
  required from libtinfo.so.5:
    0x02a6c513 0x00 02 NCURSES_TINFO_5.0.19991023
  required from libc.so.6:
    0x09691a75 0x00 03 GLIBC_2.2.5

CodePudding user response:

Unfortunately, I believe this may be a Stack issue where it downloads the wrong versions of GHC on CentOS/RHEL7 systems (i.e., downloading the Debian 9 version instead of the CentOS 7 version).

In order to work around this problem, you will first need to manually clean out your .stack directory to remove the offending binary packages. The bad GHC version (tarfile and directory) will need to be removed from .stack/programs/x86_64-linux. I also found I needed to clean out .stack/snapshots to avoid additional linkage errors, and I can't point you to exactly which files under there were the offenders. It's honestly safest to wipe your entire .stack directory and start from scratch.

Anyway, I was able to build haskell-language-server in a CentOS 7 container as follows:

  1. Ensure ncurses-devel and zlib-devel packages are installed.

  2. Remove the entire .stack directory.

  3. Run stack update to recreate a skeleton .stack directory.

  4. Edit .stack/config.yaml to add the following clause:

     setup-info:
       ghc:
         linux64:
           8.10.7:
             url: "https://downloads.haskell.org/~ghc/8.10.7/ghc-8.10.7-x86_64-centos7-linux.tar.xz"
    

    Obviously, this is per-version configuration, so if you build with other GHC versions, you'll need to add additional subclauses.

  5. Download and check out tag 1.7.0.0 of the HLS source:

    git clone -b 1.7.0.0 https://github.com/haskell/haskell-language-server
    
  6. Build.

    $ cd haskell-language-server
    $ stack build
    [ . . . lots of output . . .]
    haskell-language-server           > Registering library for haskell-language-server-1.7.0.0..
    Completed 247 action(s).
    

Again, it's crucial that no stale binaries from .stack or the project-local .stack-work sneak into your build. So removing .stack entirely and also building from a fresh Git clone of HLS will be safest.

Until this Stack bug is fixed, you'll have to remain vigilant in adding additional clauses to config.yaml to avoid accidentally downloading a Debian build of some older or newer GHC version and wrecking your .stack cache.

  • Related