Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fixed CORE-6368 - Increase FB_API_VER to 40.
- Loading branch information
1 parent
0b96286
commit 9aaf355
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Numbers in library names on Linux also must match API version.
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In v3 we do not have .so.3 library, it has only .so.2.
In master we have .so.2 and .so.4.0.0 (no .so.4 and no .so.3).
@AlexPeshkoff
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And this is a bug in v3 distribution.
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, Debian package maintainer here.
Soname (the 2 in libfbclient.so.2) should be changed only if the ABI is not backwards compatible. That is, the new library would break binaries (e.g. flamerobin) compiled against the old library ABI. This is usually the case when a symbol (e.g. a function entry point) is removed or its arguments had changed.
Adding new entry points doesn't warrant changing the soname.
Changing the soname requires that all packages that link with libfbclient to be recompiled and updated together. Such transitions are a major burden for binary distributions like Debian and it would be nice to avoid them if possible.
Affected packages include libreoffice, qt5, php, perl driver, opendbx driver, python driver.
Firebird used libfbclient.so.2 (soname) provided by libfbclient.so.2.0.x, 2.1.x, 2.5.x and 3.0.x (library file) without any problems for several years which was great!
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it really necessary if soft links with old numbers are provided?
The problem as I see it that new applications which require new API entries cannot be linked with libfbclient.so.2 and be sure that they shall run ok. They have to be linked with libfbclient.so.4 for that which ensure API v4 to be available for them.
Also good to read: https://semver.org
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is. Library packages are named after the soname of the library. So flamerobin (for example) compiled against libfbclient with soname libfbclient.so.2 depends on libfbclient2.deb. Changing the soname in fb3/4 would mean there is no more libfbclient2 package, breaking flamerobin.
My guess is that such applications need to check the provided API version (e.g. via #if directive).
These same applications would needlessly require rebuilding each time firebird is upgraded with changed libfbclient soname.
This actually confirms my suggestion for keeping the soname (major version) because there are no backward-incompatible API changes:
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is impossible during binary distribution.
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As said, it is enough to provide set of softlinks with API versions included into name:
libfbclient.so.4 -> libfbclient.so
libfbclient.so.3 -> libfbclient.so
libfbclient.so.2 -> libfbclient.so
libfbclient.so.1 -> libfbclient.so
Developers won't be limited by currently installed/used ibase.h and cloose required Firebird client version freely at linking time. Loader and ldd will produce meaningful output as well.
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. But if Linux loader is able to throw error "undefined symbol" why it doesn't work for missing exported/imported functions?
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
9aaf355There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.