vaultenv: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by vaultenv)

[mesaugat]

I just installed the newest version 0.8.0.

Why does this need GLIBC_2.27 which was released 2018-02-01 - 6 months back? Can we support lower versions of GLIBC. 😞

0.7.1 was working fine. Can we rebuild vaultenv that requires a lower version of GLIBC?

[duijf]

Thanks for the report. Did you build from source or use the binary on the releases page?

It might just be because I compiled the version on the releases page on a Ubuntu 18.04 machine.

Otherwise, you might need to downgrade to an older Stackage snapshot. (Which includes a newer version of the Haskell compiler). That would mean reverting the changes to this file

[mesaugat]

@duijf I used the binary on the releases page.

[duijf]

Could you try this:

Install stack from here

$ git clone https://github.com/channable/channabuild.git
$ cd channabuild

# This will take a bunch of CPU, network and time as it downloads a Haskell compiler
# and a bunch of dependencies
$ stack build
$ stack exec vaultenv

If that works, you have a binary which works with your glibc version. You can find that at $(stack path --local-install-root)/bin/vaultenv

[mesaugat]

I think you meant git clone https://github.com/channable/vaultenv.git? I think channabuild is a private repository.

Yes, I get this. I think supporting older LTS versions with older version of glibc doesn't do any harm? You can reach to a large number of users.

Thank you, I'll see what I can do.

[duijf]

I think you meant git clone https://github.com/channable/vaultenv.git? I think channabuild is a private repository.

Whoops yes sorry. I was answering a question about that to a colleague and derped 😅

Yes, I get this. I think supporting older LTS versions with older version of glibc doesn't do any harm? You can reach to a large number of users.

Agreed. Currently, we don't have much in the way of release automation. However, that's something to consider for the future. Not everyone is interested in compiling Haskell projects from source and the binaries would be really useful.

For now I've updated the release notes to note that there may be linking issues.

[duijf]

Thanks for looking into this by the way :)

This is also something that would be solved by providing fully static executables, which we have a ticket for here: #43

[ruuda]

glibc version does not depend on the Stackage snapshot or GHC version, it depends on the glibc in the build environment.

[duijf]

glibc version does not depend on the Stackage snapshot or GHC version, it depends on the glibc in the build environment.

Thanks :)

I'm building a version on Ubuntu 16.04, which should help @mesaugat out for now

[duijf]

@mesaugat I've uploaded a new binary to the 0.8.0 release. Forgive the weird filenames, it seems GitHub has a bug, because I can't get the filenames to actually work.

[mesaugat]

Thanks for the help. @duijf

Awesome work with vaultenv 🥇 - I think this can be closed now.

[duijf]

Thanks for the kind words :)

[mesaugat]

@duijf You named the binaries incorrectly. The bionic one is xenial and the xenial one is bionic.

[duijf]

Thanks for letting me know. I'm pretty sure I did this right and this is a problem with the GH release file upload widget.

I'll try to fix this, but no promises. I've also created #53 to avoid us having to deal with this in the future..

[duijf]

Okay I fixed the naming by removing all periods from the filenames. Should be good now

[sumanmukherjee03]

Hi @duijf this bug is also happening on the vaultenv 0.9.0 binary. Do you want me to file a new issue for that?

[duijf]

We need to get an automated process for this, as me trying to take care of this manually is not sustainable. I'll open a ticket