Static binary downloaded from release not working, lacking libhttp_parser

[gabrielmagno]

I've downloaded the static binary of version v0.7.0 ( https://github.com/ogham/exa/releases/download/v0.7.0/exa-linux-x86_64-0.7.0.zip )

I try to run the binary exa-linux-x86_64, and get the error:
./exa-linux-x86_64: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory

If I build exa myself with make, in the same system, the binary I've compiled works fine.

[Chronial]

A sudo apt install libhttp-parser2.1 fixed it for me on ubuntu17, but I don't see why this tool would depend on a http parser.

[Chronial]

A sudo apt install libhttp-parser2.1 fixed it for me on ubuntu17, but I don't see why this tool would depend on a http parser.

[steveklabnik]

A sudo apt install libhttp-parser2.1 fixed it for me on ubuntu17, but I don't see why this tool would depend on a http parser.

I believe it's because libgit2 binds to curl.

[steveklabnik]

A sudo apt install libhttp-parser2.1 fixed it for me on ubuntu17, but I don't see why this tool would depend on a http parser.

I believe it's because libgit2 binds to curl.

[ogham]

@steveklabnik You're right.

Sorry everyone, I'm not sure how this snuck in. There was a recent PR (#174) to turn off the Git networking features, which I thought would cover this too.

[ogham]

@steveklabnik You're right.

Sorry everyone, I'm not sure how this snuck in. There was a recent PR (#174) to turn off the Git networking features, which I thought would cover this too.

[jeremyjh]

On Arch we have http-parser 2.7.1. Having this installed does not seem to help me.

[] ~/Downloads exa
exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory
[] ~/Downloads ls /usr/lib/libhttp_parser.so*
/usr/lib/libhttp_parser.so  /usr/lib/libhttp_parser.so.2.7.1

ldd /usr/local/bin/exa
        linux-vdso.so.1 (0x00007ffd20fad000)
        libhttp_parser.so.2.1 => not found
        libz.so.1 => /usr/lib/libz.so.1 (0x00007fc5fc7fc000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fc5fc5f8000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007fc5fc3f0000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fc5fc1d2000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fc5fbfbb000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fc5fbc15000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc5fca13000)

[jeremyjh]

On Arch we have http-parser 2.7.1. Having this installed does not seem to help me.

[] ~/Downloads exa
exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory
[] ~/Downloads ls /usr/lib/libhttp_parser.so*
/usr/lib/libhttp_parser.so  /usr/lib/libhttp_parser.so.2.7.1

ldd /usr/local/bin/exa
        linux-vdso.so.1 (0x00007ffd20fad000)
        libhttp_parser.so.2.1 => not found
        libz.so.1 => /usr/lib/libz.so.1 (0x00007fc5fc7fc000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fc5fc5f8000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007fc5fc3f0000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fc5fc1d2000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fc5fbfbb000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fc5fbc15000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc5fca13000)

[phxql]

Fix for Fedora 26:

# dnf install http-parser-devel
# ln -s /usr/lib64/libhttp_parser.so /usr/lib64/libhttp_parser.so.2.1

[phxql]

Fix for Fedora 26:

# dnf install http-parser-devel
# ln -s /usr/lib64/libhttp_parser.so /usr/lib64/libhttp_parser.so.2.1

[concatime]

@phxql, Fedora 26 too, but not exactly the best answer.
Why?

• Since exa is intended to be self-contained, I'm not supposed to install other dependencies ;
• And if you don't install http-parser-devel, it seems that there is no libhttp_parser.so ;

 $ exa
exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory
 $ sudo ldconfig -v | grep libhttp*
	libhttp_parser_strict.so.2 -> libhttp_parser_strict.so.2.7.1
	libhttp_parser.so.2 -> libhttp_parser.so.2.7.1
 $ ls -la /lib64/libhttp_parser.so*
	/lib64/libhttp_parser.so.2 -> libhttp_parser.so.2.7.1
	/lib64/libhttp_parser.so.2.7.1

So, after little bit of searching, I was able to fool exa work by running only one command:

sudo ln -s libhttp_parser.so.2 /lib64/libhttp_parser.so.2.1

[concatime]

@phxql, Fedora 26 too, but not exactly the best answer.
Why?

• Since exa is intended to be self-contained, I'm not supposed to install other dependencies ;
• And if you don't install http-parser-devel, it seems that there is no libhttp_parser.so ;

 $ exa
exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory
 $ sudo ldconfig -v | grep libhttp*
	libhttp_parser_strict.so.2 -> libhttp_parser_strict.so.2.7.1
	libhttp_parser.so.2 -> libhttp_parser.so.2.7.1
 $ ls -la /lib64/libhttp_parser.so*
	/lib64/libhttp_parser.so.2 -> libhttp_parser.so.2.7.1
	/lib64/libhttp_parser.so.2.7.1

So, after little bit of searching, I was able to fool exa work by running only one command:

sudo ln -s libhttp_parser.so.2 /lib64/libhttp_parser.so.2.1

[Jachimo]

Seeing the same thing right now on Debian 8 (Jessie).

Installing libhttp-parser-dev fixed it as a workaround, but it would be nice if this could be included so that the binary was really self-contained.

[Jachimo]

Seeing the same thing right now on Debian 8 (Jessie).

Installing libhttp-parser-dev fixed it as a workaround, but it would be nice if this could be included so that the binary was really self-contained.

[brunophilipe]

There's no such package in the standard CentOS yum configuration.

I tried installing the RPM from here but it installs the wrong version, so I simply linked the wrong version to the right one (I know...) with ln /usr/lib64/libhttp_parser.so.2 /usr/lib64/libhttp_parser.so.2.1 but that didn't help because then it failed for not having glibc version 2.18, and only version 2.17 is available from the CentOS repository.

So I gave up for now 😄 I think this is not exactly a "self-contained" binary.

[brunophilipe]

There's no such package in the standard CentOS yum configuration.

I tried installing the RPM from here but it installs the wrong version, so I simply linked the wrong version to the right one (I know...) with ln /usr/lib64/libhttp_parser.so.2 /usr/lib64/libhttp_parser.so.2.1 but that didn't help because then it failed for not having glibc version 2.18, and only version 2.17 is available from the CentOS repository.

So I gave up for now 😄 I think this is not exactly a "self-contained" binary.

[ogham]

So those commit messages tell an awkward story of a fix that a) works but b) I'm not 100% happy with. Basically I've forked git2-rs into a version that has the libhttp_parser dependency manually removed, and exa's development VM uses that version rather than the crates version, and it all seems to work.

So by the time I build the binaries for v0.8.0, this shouldn't be an issue anymore.

[ogham]

So those commit messages tell an awkward story of a fix that a) works but b) I'm not 100% happy with. Basically I've forked git2-rs into a version that has the libhttp_parser dependency manually removed, and exa's development VM uses that version rather than the crates version, and it all seems to work.

So by the time I build the binaries for v0.8.0, this shouldn't be an issue anymore.

[ogham]

says he's not going to close the issue yet

accidentally closes issue

[ogham]

says he's not going to close the issue yet

accidentally closes issue

[deathtrip]

issue is still present (again) in version 947-git

[deathtrip]

issue is still present (again) in version 947-git

[ogham]

@deathtrip Unfortunately I can't fix it for everyone, just builds that come from the Vagrant VM.

[ogham]

@deathtrip Unfortunately I can't fix it for everyone, just builds that come from the Vagrant VM.

[flip111]

Same problem for CentOS Linux release 7.3.1611

[flip111]

Same problem for CentOS Linux release 7.3.1611

[deathtrip]

i might add that i have this problem when i compile it from source (via AUR), not when using the downloaded binary

[deathtrip]

i might add that i have this problem when i compile it from source (via AUR), not when using the downloaded binary

[juleskers]

Is there a time-plan for when the next release will happen?
The release zipfile for linux (exa-linux-x86_64-0.7.0.zip) is still broken as of just now.

I'm on a work computer, where I do not have admin/sudo rights, so I can't use the workarounds.
unpacking the downloaded binary in ~/bin is my only option here.

[juleskers]

Is there a time-plan for when the next release will happen?
The release zipfile for linux (exa-linux-x86_64-0.7.0.zip) is still broken as of just now.

I'm on a work computer, where I do not have admin/sudo rights, so I can't use the workarounds.
unpacking the downloaded binary in ~/bin is my only option here.

[lmlsna]

The provided linux-x86 binary is not statically compiled. It is dynamically linked to the following libraries:

• linux-vdso.so.1
• libhttp_parser.so.2.1
• libz.so.1
• libdl.so.2
• librt.so.1
• libpthread.so.0
• libgcc_s.so.1
• libc.so.6
• /lib64/ld-linux-x86-64.so.2

Almost all modern Linux systems will have these packages already installed, with the exception of libhttp-parser 2.1. This package is a dependency for the rust compiler itself, so by installing the packages required to build the code, you also download the missing dependency, and that's probably where the confusion is coming from.

You can fix this by just installing the missing libraries:

• On Debian/Ubuntu, you can install using apt-get install libhttp-parser-dev
• On CentOS/Fedora, you can install using yum install http-parser

I would also either statically compiling the release binaries, or making the required dependencies more clear in the documentation. Both of those should prevent this issue from coming up again.

[lmlsna]

The provided linux-x86 binary is not statically compiled. It is dynamically linked to the following libraries:

• linux-vdso.so.1
• libhttp_parser.so.2.1
• libz.so.1
• libdl.so.2
• librt.so.1
• libpthread.so.0
• libgcc_s.so.1
• libc.so.6
• /lib64/ld-linux-x86-64.so.2

Almost all modern Linux systems will have these packages already installed, with the exception of libhttp-parser 2.1. This package is a dependency for the rust compiler itself, so by installing the packages required to build the code, you also download the missing dependency, and that's probably where the confusion is coming from.

You can fix this by just installing the missing libraries:

• On Debian/Ubuntu, you can install using apt-get install libhttp-parser-dev
• On CentOS/Fedora, you can install using yum install http-parser

I would also either statically compiling the release binaries, or making the required dependencies more clear in the documentation. Both of those should prevent this issue from coming up again.

[hoodie]

@lmlsna as @ogham already stated, the next release will no longer depend on libhttp-parser, so ppl ought to be able to use exa without installing it.

[hoodie]

@lmlsna as @ogham already stated, the next release will no longer depend on libhttp-parser, so ppl ought to be able to use exa without installing it.

[lmlsna]

Well that was 2 months ago, and 6 identical issues have been opened for the same problem since then (#194 #203 #210 #230 #255 #285).

None of the released binaries have ever been statically compiled, and contain links to several, occasionally uncommon libraries , so they are very much not "self contained" (see #158).

My only point is that is is confusing to offer binaries that require libraries to be installed and not document which libraries those are. If you are releasing one binary that you expect to run on every linux distribution, it really should be statically compiled, otherwise people are always going to complain here about missing libraries.

I am happy to make a change to the README or write a script to statically compile the binary releases, whichever @ogham prefers.

[lmlsna]

Well that was 2 months ago, and 6 identical issues have been opened for the same problem since then (#194 #203 #210 #230 #255 #285).

None of the released binaries have ever been statically compiled, and contain links to several, occasionally uncommon libraries , so they are very much not "self contained" (see #158).

My only point is that is is confusing to offer binaries that require libraries to be installed and not document which libraries those are. If you are releasing one binary that you expect to run on every linux distribution, it really should be statically compiled, otherwise people are always going to complain here about missing libraries.

I am happy to make a change to the README or write a script to statically compile the binary releases, whichever @ogham prefers.

[ogham]

There's a new release out, and I've added a dependency-free VM to the Vagrantfile so I can actually test that problems like these don't happen again.

Point is, though, I know I really shouldn't have left this unresolved for this long, especially when the binary contradicted the home page. I'm still trying to get a handle on making regular releases. I can get in the zone to write code and fix bugs no problem, but I've never really been able to do the same for publishing releases or managing the community — something that's become more and more of a problem as exa's userbase grows.

I hope that with enough practice (and enough deployment automation!), there won't ever be a problem like this again.

[ogham]

There's a new release out, and I've added a dependency-free VM to the Vagrantfile so I can actually test that problems like these don't happen again.

Point is, though, I know I really shouldn't have left this unresolved for this long, especially when the binary contradicted the home page. I'm still trying to get a handle on making regular releases. I can get in the zone to write code and fix bugs no problem, but I've never really been able to do the same for publishing releases or managing the community — something that's become more and more of a problem as exa's userbase grows.

I hope that with enough practice (and enough deployment automation!), there won't ever be a problem like this again.

[lmlsna]

You are actively developing a cool thing, that people like, for free. The fact you're releasing binaries at all is awesome.

[lmlsna]

You are actively developing a cool thing, that people like, for free. The fact you're releasing binaries at all is awesome.

[ogham]

@lmlsna Thank you. And likewise, you offered to help when you saw something wrong. I appreciate that.

[ogham]

@lmlsna Thank you. And likewise, you offered to help when you saw something wrong. I appreciate that.

[flip111]

Problem persist for CentOS Linux release 7.3.1611 just cloned the repo again from commit 0eb7966 rustc version is at rustc 1.20.0 (f3d6973f4 2017-08-27)

[flip111]

Problem persist for CentOS Linux release 7.3.1611 just cloned the repo again from commit 0eb7966 rustc version is at rustc 1.20.0 (f3d6973f4 2017-08-27)

[kballard]

@flip111 It looks like the "fix" for this (3405db1) just fixed the binary releases. Building from source still ends up depending on libhttp_parser.

@ogham Did you ever file an upstream ticket on alexcrichton/git2-rs about libhttp_parser? If so, I can't find it.

[kballard]

@flip111 It looks like the "fix" for this (3405db1) just fixed the binary releases. Building from source still ends up depending on libhttp_parser.

@ogham Did you ever file an upstream ticket on alexcrichton/git2-rs about libhttp_parser? If so, I can't find it.

[plul]

I am getting this error on Arch for the first time. I have installed the http-parser package, but there is a version mismatch:

The error tells me 2.7.1 is missing, as Arch has http-parser version 2.8.0-1 in the community repo.

[plul]

I am getting this error on Arch for the first time. I have installed the http-parser package, but there is a version mismatch:

The error tells me 2.7.1 is missing, as Arch has http-parser version 2.8.0-1 in the community repo.

[plul]

I managed to fix my problem after I realized that the binary is now in the Arch Community repo. So I uninstalled exa-git that I had gotten from the AUR, and installed exa from the Community repo.

[plul]

I managed to fix my problem after I realized that the binary is now in the Arch Community repo. So I uninstalled exa-git that I had gotten from the AUR, and installed exa from the Community repo.