Incorrect libraries name/soname

[kaliber]

Third party libraries in haiku have incorrect sonames.

1. zlib

• there is: libz.so.1
• should be: libz.so.1 (OK)

2. jpeg

• there is: libjpeg.so.8.0
• should be: libjpeg.so.8

3. png

• there is: libpng.so.1.2
• should be: libpng.so.0 or even libpng12.so.0

4. icu

• there is: libicu-*.so.4.2
• should be: libicu*.so.42

[kaliber]

Replying to kaliber:

Third party libraries in haiku have incorrect sonames.

1. zlib
- there is: libz.so.1
- should be: libz.so.1 (OK)
2. jpeg
- there is: libjpeg.so.8.0
- should be: libjpeg.so.8
3. png
- there is: libpng.so.1.2
- should be: libpng.so.0 or even libpng12.so.0
4. icu
- there is: libicu-*.so.4.2
- should be: libicu*.so.42

[zooey]

Replying to kaliber:

Third party libraries in haiku have incorrect sonames.

It really depends on what you mean by incorrect - as it seems, you have compared the sonames from haiku with the ones on Linux. But the BSDs for instance have a different soname scheme (incrementing the numeric suffic for every release).

The soname scheme currently used in haiku simply uses the libraries name + ABI version for the soname.

1. zlib
- there is: libz.so.1
- should be: libz.so.1 (OK)
2. jpeg
- there is: libjpeg.so.8.0
- should be: libjpeg.so.8

It is hard to tell from their past releases, but is libjpeg 8.1 really going to be ABI compatible with 8.0? Please tell if you've found a point of reference for that. Of course we could still name it libjpeg.so.8 and then name the next release libjpeg.so.8.1 if it is not compatible. But I personally find it pretty cumbersome to try and track ABI compatibility for libs that do not care to document their ABI compatibility policy.

3. png

• there is: libpng.so.1.2
• should be: libpng.so.0 or even libpng12.so.0

But both libpng.so.0 and libpng12.so.0 even violate the usual soname scheme on Linux, as their suffix doesn't state anything about ABI version (or what do you make of '.0'?). I don't know why the authors of libpng chose to include the release as part of the name instead of appending the ABI version as suffix. On haiku, I'd prefer all libraries to follow the same soname (and naming) scheme.

4. icu

• there is: libicu-*.so.4.2
• should be: libicu*.so.42

}}}

Yeah, it could be, but why not let the soname match the ABI version of the library?

[kaliber]

Replying to zooey:

It really depends on what you mean by incorrect - as it seems, you have compared the sonames from haiku with the ones on Linux. But the BSDs for instance have a different soname scheme (incrementing the numeric suffic for every release).

Soname is defined by the a package and it's OS independent. I'm talking about open source software available on various operating systems. It looks like FreeBSD (ports) uses the same rules, for example ​http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9-current/All/icu-4.3.3.tbz, ​http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9-current/All/ncurses-5.7.tbz. For some reason libjpeg has different soname in FreeBSD.

The soname scheme currently used in haiku simply uses the libraries name + ABI version for the soname.

Many 3rdparty software use libtool. The major version number is changed only if ABI has changed. ​http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html

It is hard to tell from their past releases, but is libjpeg 8.1 really going to be ABI compatible with 8.0? Please tell if you've found a point of reference for that. Of course we could still name it libjpeg.so.8 and then name the next release libjpeg.so.8.1 if it is not compatible. But I personally find it pretty cumbersome to try and track ABI compatibility for libs that do not care to document their ABI compatibility policy.

In my opinion 8.1 will be binary compatible with 8.0, but there is no guarantee. We should trust to package maintainers and believe that they change major version if they break binary compatibility.

4. icu

• there is: libicu-*.so.4.2
• should be: libicu*.so.42

}}}

Yeah, it could be, but why not let the soname match the ABI version of the library?

Soname should match the ABI version instead of software version.

Summarizing. I prefer to use original soname provided by a package maintainers instead of introducing own.

[Luposian]

I am currently trying to run a few games on Haiku (gcc2hybrid) hrev45711. Upon downloading OpenSound, Lua, and sdllibs via Terminal w/ installoptionalpackage, I am left with a request to locate libjpeg.so.8.0, which I can't find anywhere (the only version in the /lib folder is libjpeg.so.8.4.0, yet the game was written for/ported to Haiku in 2012.

Can someone tell me how to get this game (and others) running using the current libjpeg and/or where I can locate libjpeg.so.8.0? Or are most of the games (requiring this version of libjpeg) on Haikuware now broken because of this situation?

[umccullough]

Replying to Luposian:

I am currently trying to run a few games on Haiku (gcc2hybrid) hrev45711.

Your issue has nothing to do with this ticket - you really should consider opening a new ticket (actually, you should consider contacting the original game developer/porter and asking them to link to a non-version-specific version of libjpeg if possible, or include the proper version of the library with their app if it requires an older version).

[bonefish]

Replying to umccullough:

Your issue has nothing to do with this ticket

Actually it kind of does. When korli outsourced libjpeg in hrev44588, the library's soname changed from "libjpeg.so.8.0" to "libjpeg.so.8". Since he also updated to version 8.4.0 which consequently doesn't come with a "libjpeg.so.8.0" symlink anymore, all software built against the previous libjpeg is now broken. We should probably just add the symlink to the current optional package.

@Luposian: You can create a symlink "libjpeg.so.8.0" in your "~/config/lib/", pointing to the installed "libjpeg.so.8".

Are there any libraries left that this ticket concerns? libjpeg, libpng, and ICU have been outsourced and use the same scheme as on other platforms.

[umccullough]

Replying to bonefish:

When korli outsourced libjpeg in hrev44588, the library's soname changed from "libjpeg.so.8.0" to "libjpeg.so.8".

Aha - it had sounded like libjpeg.so.8.0 had been changed to libjpeg.so.8.4.0 according to Luposian... but now that I look at the package contents (don't have a Haiku install handy), I do indeed see the libjpeg.so.8 symlink is present as well.

We should probably just add the symlink to the current optional package.

Should we continue to persist the "broken" symlink versioning behavior as such? Would that likely lead to more apps incorrectly being linked to the wrong filename scheme in the future?

[Luposian]

Replying to bonefish:

Replying to umccullough:

Your issue has nothing to do with this ticket

Actually it kind of does. When korli outsourced libjpeg in hrev44588, the library's soname changed from "libjpeg.so.8.0" to "libjpeg.so.8". Since he also updated to version 8.4.0 which consequently doesn't come with a "libjpeg.so.8.0" symlink anymore, all software built against the previous libjpeg is now broken. We should probably just add the symlink to the current optional package.

@Luposian: You can create a symlink "libjpeg.so.8.0" in your "~/config/lib/", pointing to the installed "libjpeg.so.8".

But libjpeg.so.8 is a symlink itself (as far as I can tell, by "Find...")... can you symlink a symlink? I thought you could only symlink an actual program.

The symlink "libjpeg.so.8" links to the file "libjpeg.so.8.4". Won't the game still recognize it's not the version of libjpeg it's looking for?

[Luposian]

Replying to umccullough:

Replying to bonefish:

When korli outsourced libjpeg in hrev44588, the library's soname changed from "libjpeg.so.8.0" to "libjpeg.so.8".

Aha - it had sounded like libjpeg.so.8.0 had been changed to libjpeg.so.8.4.0 according to Luposian... but now that I look at the package contents (don't have a Haiku install handy), I do indeed see the libjpeg.so.8 symlink is present as well.

My apologies for the confusion. Not being a developer, my assumption was that the version had been incremented (which, according to Bonefish, actually IS the case) and no games requesting that older version would ever work, since they were looking for an older version than what was now current. So, will a "libjpeg.so.8.0" symlink to the "libjpeg.so.8" symlink actually work, or must the actual libjpeg.so file be that exact (older) version? In other words, is there any possible incompatibility issue with the newer version of libjpeg.so?

[umccullough]

Replying to Luposian:

So, will a "libjpeg.so.8.0" symlink to the "libjpeg.so.8" symlink actually work, or must the actual libjpeg.so file be that exact (older) version? In other words, is there any possible incompatibility issue with the newer version of libjpeg.so?

Just symlink it to the same file as the other symlink...

I guess there's a high probability that the API/ABI hasn't actually changed since libjpeg itself hasn't really changed in the last 4 years.

[Luposian]

Ok, I just tried what you suggested, Bonefish, and the game tries to start (opens up a blank, black window) and then quits immediately. All within about 1 sec.

Is this likely caused by a version incompatibility issue or...? This could have far-reaching implications, if tons of games (relying on SDL, Lua, and EGSL) now refuse to work because they expect a version of libjpeg that is older than the current version. I'm not saying we should revert to an older version, but... a ton of games on Haikuware may no longer work and there should be a concerted effort to either find a work-around (if it's in Haiku's hands to do that), or tell people (on Haikuware) to start recompiling for the newer version... or something.

[umccullough]

Replying to Luposian:

Ok, I just tried what you suggested, Bonefish, and the game tries to start (opens up a blank, black window) and then quits immediately. All within about 1 sec.

Try running it from a Terminal instead - my guess is you're still missing some lib, or you've got an SDL compatibility problem.

[Luposian]

Tried it in Terminal and this is what I got:

~/Desktop/Astrorocks> astrorocks BMediaEventLooper: SchedulingLatency is 750 BMediaRoster::Connect connection established! BMediaRoster::GetParameterWebFor Unflattening 1832 bytes, 0x1030506, 0x1, 0x2, 0x3 BRect(l:0.0, t:0.0, r:1599.0, b:899.0) Error: Can not open image. BMediaRoster::ReleaseNode, trying to release reference counting disabled timesource, node 2, port 400, team 14772

It crashed just the same, but spewed out all this stuff. What does all this mean?

[augiedoggie]

It's trying to load libpng.so.1.4 but Haiku is currently using version 1.5. You can copy an old version of libpng onto your system or rebuild the sdl image libraries so that they work with the newer png/jpeg.

[bonefish]

Replying to umccullough:

Should we continue to persist the "broken" symlink versioning behavior as such? Would that likely lead to more apps incorrectly being linked to the wrong filename scheme in the future?

The file name is irrelevant, when the library has a soname, which it has in this case.

[zooey]

Closing, as the original issue has been fixed by outsourcing all the libraries. As a result of the outsourcing, library versioning is likely to follow the upstream naming conventions.