- User Since
- Mar 27 2017, 4:48 PM (99 w, 4 d)
Jan 11 2017
It seems like indeed it should have been resolved. I have also resolved the issue
by moving the old headers from KDEPIMLibs 4 to a private location, and KF5
projects have apparently been updated to work with gpgme++ installed in
Jan 2 2017
The patch works. There's 1 more issue that's been standing for a bit longer already,
and that you might want to tackle at the same time: there's no argp.h header on Mac.
On Linux it is only a problem with the headers (e.g. the -dev) Package as the
That's actually an orthogonal issue, and one that's probably easier to rectify as any
changes only become apparent when dependent software is being built.
libraries have different soversions
This is also the case on Mac, but the link library doesn't have a soversion. It's
called libqgpgme.so or libqgpgme.dylib .
There is of course the option to rename just that symlink. A bit of a hack, but one
that's relevant only during the link step, when dependent software is being rebuilt.
How does MacPorts handle this in general? IMO this is not a (q)gpgme(++)
specific problem as you will have this problem with each ABI break.
MacPorts does many things like they're done on more traditional *n*x desktops, i.e.
install libraries in a central, shared location (--prefix=/opt/local by default).
There is nothing specific it does to handle ABI breaks; they can hold up an upgrade,
or a patch is applied at some level, or a conflict is registered. Sadly there is no
central way to create -dev packages, which doesn't help here.
E.g. when we
break the ABI in QGpgME libqt5qgpgme.dylib may be incompatible and we would need
a new name.
That I don't see. The problem here isn't so much the ABI break compared to the
version shipped by kdepimlibs4, but the fact that an incompatible Qt version is used.
So no, a SOVERSION=8 upgrade doesn't impose a library name change. Cf. Poppler and
its Qt backends; they're called libpoppler-qt4 and libpoppler-qt5 .
An alternative would be to do like QCA: install the library wherever Qt's own
libraries are installed. That automatically resolves the conflict with the old
version included with kdepimlibs4, and might be less disruptive for existing
It's not only the build system but the code using QGpgME / GpgME++ will be more
complex as they would need to have feature checks for both the QGpgME version
What I had in mind was a build system that refuses to do a mismatching build of QpgME
X.Y.Z against GpgME++ that's not X.Y.Z . If you don't do runtime checks there's no
guarantee anyway beyond what the dynamic linker can give, I think. Distributions can
build QpgME and only bundle the QpgME bits, and then install that against any GpgME
install. I've done that for a bit with QpgME 1.7.x against QpgME++ 1.8.0, and didn't
run into any issues.
You could probably even argue that people would be less likely to try this kind of
things if the build system gave off a big hint that they really shouldn't be doing
that. It's not like it's particularly difficult to install only QpgME, after all.
Dec 21 2016
It will probably a bit more complex to maintain the buildsystem because you'd
want to exclude builds against mismatching qgpgme versions, but when done that
should be all, no?
It's just a bit a pity that you have to build all of the cpp bindings again if
you just want to build the Qt bindings.
Something else that would be nice is a possibility to build (and install) just
QGpgME, against an already installed gpgme. Would that be hard to achieve?