Add Qt Major Version in lib soname

[sfalken]

As currently setup, whether you build stellarsolver against Qt5 or Qt6, the SONAME of libstellarsolver is remaining the same:

📦 mustang /usr/lib64 % objdump -p libstellarsolver.so.2.6 | grep SONAME
  SONAME               libstellarsolver.so.2

this makes the Qt5 and Qt6 versions of stellarsolver be incompatible with each other, and not co-installable, which is a problem for downstream packaging of the project.

Can we get the Qt Major Version added to the library SONAME?

[rlancaste]

This is a very good idea, sorry I did not get back to you sooner. Does this work or is something else needed? Please let me know and I can include it with several other changes and make a new 2.7 release that would include this feature.

[sfalken]

Yep, that would work just fine.

[rlancaste]

Ok do you know if this will cause problems with find library functions in cmake and other systems based on version numbers? Since they are supposed to find versions greater than certain numbers, would libstellarsolver.qt6.2.7 or libstellarsolver.qt5.2.7 cause issues with these functions?

[rlancaste]

Would it also work to make the name libstellarsolver6.2.7 and libstellarsolver5.2.7 instead of libstellarsolver.qt6.2.7 and libstellarsolver.qt5.2.7? Jasem suggested this and said it would be more like KF6's method of differentiating between qt versions.

[rlancaste]

I just want to check first to make sure it would still work for your purposes.

[sfalken]

Yeah, doing it like KDE Frameworks does it, would work quite nicely.

[TallFurryMan]

My comment here is slightly hijacking this issue, I apologise.

However, given the associated commit, to me we have here a breaking change wthout a major version change.

In my opinion, and I admit I don't have a general overview of best practices in terms of Qt/KF dependencies, you should not change the linkname, so that binaries dyn-linking to your library can still use libstellarsolver.so. That linkname will then point to libstellarsolver5.so.2 or libstellarsolver6.so.2, which will in turn link to the minor-versioned library. With the change in 372d95e, the linkname change and the two packages are incompatible, that is a binary that was running before suddenly fails to preload.

If you want/need to support both flavors on the same system, there is probably more work to do at the installation phase, but that is probably not your concern here. Or perhaps if it is, that would be for a v3.

[rlancaste]

Thanks for the comment Eric. I am open to whatever method works best. I am not an expert on Linux dependency naming schemes or finding library methods. So, whatever changes support it working best on Linux, I will do that.

[rlancaste]

Just an update @sfalken, Eric and I discussed this for awhile and the final decision is that I will leave the qt5 version as libstellarsolver as it currently is in the last release (we are not doing libstellarsolver5.so.2), but for the qt6 version, I will add the number 6 like this: libstellarsolver6.so.2. This way, anything that currently links with libstellarsolver and qt5 will not break, but anyone wanting to use qt6 will need to find libstellarsolver6. I already committed the change. Please make sure this still works for you.

[sfalken]

Just an update @sfalken, Eric and I discussed this for awhile and the final decision is that I will leave the qt5 version as libstellarsolver as it currently is in the last release (we are not doing libstellarsolver5.so.2), but for the qt6 version, I will add the number 6 like this: libstellarsolver6.so.2. This way, anything that currently links with libstellarsolver and qt5 will not break, but anyone wanting to use qt6 will need to find libstellarsolver6. I already committed the change. Please make sure this still works for you.

Yep, works just fine for me, the mechanism itself doesn't matter that much, whatever makes sense for your codebase, I can adjust to however you've decided to do it in the downstream packaging, as long as both libraries are co-installable.

[rlancaste]

Excellent! Yes I think that's what we finally decided. We tried a couple of different things and discussed it for a few days. I think this plan works well. I do still need to look over everything and make sure we are good for a new release, but it should be in the next couple of days.

[rlancaste]

I did make the release a few days ago. Please let me know if everything works on your end for this change

[krop]

I did make the release a few days ago. Please let me know if everything works on your end for this change

Slightly related: the CMake config folders have the same name for both Qt 5 and 6 builds in the 2.7 release (also applies to the includes install dir and pkgconfig file). That still makes coinstallation impossible for distributions.

Note that it's not necessarily an issue. kstars is the only known user right now and it was ported to Qt 6.