Linux: Why 3 shared libraries per component?

[Nexus]

Why are there three librares with the extensions .so, .so.2 and .so.2.0 (of which two are symbolic links) generated on Linux? I know these specify the library version, but why both .2 and .2.0?

I also have the "problem" that the linker seems to require sfml-xy.so, but the dynamic loader needs sfml-xy.so.2. That happens when I specify the flag -lsfml-xy at g++.

[Laurent]

This is the standard way of handling libraries and their versions on Linux.

Version numbers are hierarchical: toto.x can refer to any toto.x.y, toto.x.y can in turn refer to any toto.x.y.z. So there's always a symbolic link from a version to its current child version at each level:
- toto -> toto 2
- toto 2 -> toto 2.4
- toto 2.4 -> toto 2.4.8
- etc.

This way you can link to whatever level you need, depending on your requirements (binary or API compatibility).

SFML only defines two version numbers because it's a simple library which still evolves quickly.

I don't know if it's clear :lol:

I also have the "problem" that the linker seems to require sfml-xy.so, but the dynamic loader needs sfml-xy.so.2. That happens when I specify the flag -lsfml-xy at g++.

And why is it a problem?

[Nexus]

Okay, thanks for the explanation, it's clear now. It is a not a problem, only a "problem" :p

I thought it would make more sense if linker and loader referred to the same library by default. And I'm not sure if I do something wrong, but I never mention the SFML library filenames explicitly, just always "sfml-system" etc.

At the moment, I need to ship the SFML binaries with Airport because the user is likely to have a different revision or none at all. And it would be simpler if I could just have one directory "Runtime" with 4 SFML components that can be used during build and during execution (not at least because I could just install this directory in CMake). It's no big issue, I currently have a regex workaround, but I wondered where the need for different libraries arises.

[Nexus]

Does somebody know why linker and loader require different libraries? Would that be difficult to change? But it's not urgent at all

[Laurent]

The linker requires libsfml-xyz.so because you specify "-lsfml-xyz" in your linker options, and the loader requires libsfml-xyz.so.2.0 because this is the actual binary, libsfml-xyz.so is just an alias.

If you want to force the linker to link to libsfml-xyz.so.2.0 directly, you can specify "libsfml-xyz.so.2.0" in your linker options instead of "-lsfml-xyz".

[Nexus]

Ah, thanks for the explanation!