On 07/11/2025 07:53, Stephan Bergmann wrote:
On 11/6/25 23:12, Xisco Fauli wrote:
So far, my patch makes the compilation of gpgme and gpgmepp towork,
but it fails further down with
/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/
linux_clang_dbgutil_64/comphelper/source/misc/
docpasswordhelper.cxx:673:23: error: incomplete type 'GpgME::Context'
named in nested name specifier
ctx.reset( GpgME::Context::createForProtocol(GpgME::OpenPGP) );
~~~~~~~^~~~~~~~~
and many other similar problems, See [3]. At comphelper/source/misc/
docpasswordhelper.cxx:42 it does # include <context.h> but now there
are two context.h, one in ./workdir/UnpackedTarball/gpgme/src/
context.h and the other in ./workdir/UnpackedTarball/gpgmepp/src/
context.h
If I remove ./workdir/UnpackedTarball/gpgme/src/context.h manually
then it compiles.
At least with my system's gpgmepp-devel-1.24.3-6.fc43.x86_64, all those
include files that e.g. comphelper/source/misc/docpasswordhelper.cxx
#if HAVE_FEATURE_GPGME
# include <context.h>
# include <data.h>
# include <decryptionresult.h>
#endif
includes without a path prefix are actually located in /usr/include/
gpgme++, and the way that works is that our configure.ac has
AC_CHECK_HEADER(gpgme++/gpgmepp_version.h, [ GPGMEPP_CFLAGS=-
I/usr/include/gpgme++ ],
for the --with-system-gpgmepp case.
Regardless of your attempt of upgrading our internal gpgme library, I
would strongly suggest to clean that disaster up:
* Those places in our source code that include such gpgme(pp) include
files should include them with a prefix,
#if HAVE_FEATURE_GPGME
# include <gpgme++/context.h>
# include <gpgme++/data.h>
# include <gpgme++/decryptionresult.h>
#endif
etc.
* For --with-system-gpgmepp, we should change configure.ac etc. to drop
any GPGMEPP_CFLAGS (compilers will find <gpgme++/context.h> etc. at /
usr/include without any additional -I directive just fine).
* For --without-system-gpgmepp, we should change external/gpgmepp/
ExternalProject_gpgmepp.mk to make and install to some --prefix, and
then access the installed files under that prefix, rather than tapping
directly into the build tree via $(gb_UnpackedTarball_workdir)/gpgmepp/
src as we do today.
i guess that would be an option for libraries with poorly defined
internal directory layout - most have a top-level "include" directory
that contains the public headers but apparently these ones don't.
one thing to watch out for though is that if you install to a prefix,
libtool might mangle some horrible RPATH into the .so files that we'd
have to remove manually (or maybe the problem was that it removed RPATH?
i forgot); you can check that with readelf -d.
With those prerequisite sanity changes in place, your attempt of
upgrading should then probably become much smoother.
another alternative could be to re-order the include paths (via
reordering the use_externals) but of course in case both "context.h" are
needed that won't work.
