exa: Static binary downloaded from release not working, lacking libhttp_parser

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.

Fix for Fedora 26:

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

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)

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

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.

Problem seems to persist on Debian testing/buster and 0.8.0 Also, the package libhttp-parser2.1 is not available anymore on this distro, so this workaround out of the options.

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.

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.

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

@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