Linking with http_parser.so breaks the binaries from one Linux Distribution to another

[Joacchim]

Hello,

My team and me have been using http_parser to provide a minimalistic HTTP Server feature in one of our C++ services, and it's been serving us well so far.

Alas, we're usually working and testing on Ubuntu machines, while our deployment servers are Debians. This is usually not an issue for most libraries, since these two distributions usually share most packages. For instance, we were able to run binaries compiled on one Distribution within the other, which was extremely useful for testing various kind of tooling (including deployment tooling).

After the addition of http_parser into our libraries, we've encountered the issue where the dynamic linker was not able to find the right version of the library:

• Ubuntu 18.04 provided libhttp_parser.so.2.7.1
• Debian 8 provided libhttp_parser.so.2.8.0

For most libraries, this was not an issue, despite versions differing in a similar manner.

After digging into it, we had ldd show us the actual issue: The binary was linked with the major.minor.patch version of the library, whereas most libraries are linked against their major version only, according to SEMVER.

Looking into it here, we found what we believe to be the origin of this situation in this repository:
the SONAME specification in https://github.com/nodejs/http-parser/blob/master/Makefile#L38 specifies the version down to the minor version (it previously specified the version down to the patch version).

Ideally, and if the project follows SEMVER, the SONAME should only contain the major version, lightening the linking burden in situations such as ours.

I would understand that this specific usage seems a bit far-fetched, and as such I humbly request your understanding when considering this issue which in my opinion concerns packaging practices.

[bnoordhuis]

The way http-parser currently sets the soname is a a historical artifact and, in hindsight, something of a mistake. I'd change it except I'm afraid it might end up breaking existing usage.

Admittedly, I'm not exactly sure what but if working on high-profile OSS projects has taught me anything, it's that any change that's not 100% understood always ends up breaking something sooner or later. :-)