GNOME Bugzilla – Bug 591436
Add -avoid-version to LDFLAGS
Last modified: 2017-05-05 20:58:21 UTC
As I've read bug #591414, I was wondering why we needed 0 versions on the .so files. We don't use it in plugins, we don't use it for the test components, but for the libraries, although they are shipped in a directory that's versioned with the base_number. This patch adds -avoid-version to the libraries evolution builds.
Created attachment 140423 [details] [review] Adds -avoid-version to Makefile.am's
You're probably right, but let's hold off on this until after 2.29.1. There's quite a few libraries that need not be installed in the first place (e.g. the a11y and importer libraries). I plan to discontinue the versioned directories for 3.0, and the libraries are going to shift around a bit when the kill-bonobo branch lands.
As a downstream packager, I'm concerned about the public status (and interface stability, if public) of these libs...I don't know the release plans, so I'll just state my thoughts while the topic of renaming and relocating shared libs is fresh. I see lots of headers are installed, so I assume they are for public libs, so the libs need to be interface-versioned *somehow*. Obviously easiest for others if they follow normal libtool -version-info and try to maintain backward-compatibility (okay add public symbols but not remove or change prototypes or struct declarations of existing public ones) to make upgrades not break things for users. Second best is to declare that there should be no expectation of stability between different base_versions, and so keep them named/segregated by release version. In that case, don't need -version-info (and can use -no-version or maybe -release) because the directory name serves the same public purpose. By changing directory name, the SONAME (or rpath...different platforms do those different) changes, so it's clear that the interface is different in an upgrade because it's not the same lib pathname. Finally, if a shared lib is private (used among components of the evolution package itself but not linked by public shared libs), then name is irrelevant because it's invisible outside of evo itself.
Matt, is it ready to go now?
Yeah, I think so. These libraries have no stability or backward-compatibility guarantees, and I don't even want to attempt the losing battle that libtool versioning would surely be. Daniel makes a good point about the versioned directories being the only means of identifying the interface version, so I'll back off my wanting to kill it for $(libdir) and $(includedir). But I'm still going after $(datadir). Need to verify this isn't going to cause linking issues in extension packages (exchange, mapi, rss, etc.) before commiting.
(In reply to comment #5) > Need to verify this isn't going to cause linking issues in extension packages > (exchange, mapi, rss, etc.) before commiting. H.Habighorst, could you take care of it and commit after Monday release? (There is no enough time for testing it before the release, I'm afraid.)
Comment on attachment 140423 [details] [review] Adds -avoid-version to Makefile.am's Matt, I hope I got your comment properly, as the patch can be used as is, without any change.
Created attachment 151085 [details] [review] Updated patch against current master This is an updated patch - as the old patch was 4 month old, it didn't apply. I didn't found any *.so.0(.0.0) files afterwards, guess I've catched all the occurrences. The patch shouldn't produce build errors in other software - we had no version set and the versioning applies afaik only to the shared object files...
Created attachment 151086 [details] [review] Updated the patch again [changes to em-filter-i18n.h?!] This is an updated patch again, in the other patch were changes to em-filter-i18n.h... I didn't change it - maybe a candidate for .gitignore?!
ping - can this patch get a review? Matt / Milan?
Works for me, I'm committing it.
Created commit 1600064 in evo master (3.3.90+)
Just a small comment on this. Isn't it bad practice to remove the version from the shared lib when other things may link to it? (e.g. evolution-rss wants to link against: eutil, eshell, email-engine, email-utils, evolution-utils...). Side note, I will have to locally revert this patch in our ports tree to build the OpenBSD package since we can only link against versioned libs (dlopen'ing is fine of course, it's just linking that fails).
We don't version Evolution libraries because we offer absolutely no API/ABI stability guarantees from one release to the next, so I'd rather they not have misleading names like libfoo-0.0.0.so. We only version Evolution-Data-Server libraries. But patch around it if you must.
Sure I understand the intent. That say if external software need to link to these libs, wouldn't it be better to crank the so number each time there is a new release? Anyway, that's not a big deal... I will keep patching locally as there is no other choice anyway. Thanks.
At present the versioned install directory kinda fills that role... so 3.2 libs go in $(libdir)/evolution/3.2, 3.4 libs in $(libdir)/evolution/3.4, and so on. Still, not a bad idea if it could be fully automated, which seems doable.
Debian is currently reverting this commit too [1][2]. [1] http://anonscm.debian.org/viewvc/pkg-evolution/unstable/evolution/debian/patches/10_revert_libevolution_avoid-version.patch?revision=2158&view=markup [2] http://patch-tracker.debian.org/patch/series/view/evolution/3.4.4-1/10_revert_libevolution_avoid-version.patch
Re-adding a comment to that BZ since evolution is now installing un-versioned solibs under an un-versionned directory...
Evolution really never supported installing two different versions being installed at the same time at the same prefix. Consider 'evolution' in the 'bin' folder, the utilities in /usr/libexec/ or the D-Bus services.
(In reply to Milan Crha from comment #19) > Evolution really never supported installing two different versions being > installed at the same time at the same prefix. Consider 'evolution' in the > 'bin' folder, the utilities in /usr/libexec/ or the D-Bus services. Hi Milan. Thanks for your answer. Sure my goal was never to install two different versions of evolution at the same time. In fact, my "problem" is that we have tools on OpenBSD that declare automatic dependencies on libraries but there's a strict rule for that to work: libraries must be versioned. For e.x. evolution-rss will detect automatically and tell you that it depends on evolution -- that will not work with unversioned solibs. That's not a huge issue, merely a convenience for *us*. Currently I am just doing what Debian does as well and locally patch evolution in our ports tree to remove -avoid-version. I just though it would cost nothing to ask whether it would be possible to do that by default since I am not aware of any other GNOME project that does that (except for gnome-builder which I also opened a BZ for). That's all :-)
Just found this. FWIW epiphany does this too now, because versioning private internal libraries is pointless.