For the original issue I'd prefer to silence the error/warning with -Wno-narrowing because I think it's a non-issue. Or does changing the enum declarations to enum : unsigned int make clang happy?

For gpgme (as for the other GnuPG libraries) we use the good old mailing list based process for contributing patches. See doc/HACKING for details. In particular, we'll need a signed DCO from you.

Yes, this is with Clang. I am working on getting it to compile on Windows with clang-cl, using vcpkg, with success. I have several patches to fix the issues that clang detected, and so I wonder if I should create a Task to discuss them all?

g++: error: unrecognized command-line option '-Wc++11-narrowing'; did you mean '-Wno-narrowing'?

How did you get this error? I don't even see a warning for this when building gpgme with g++ (SUSE Linux) 12.1.1 20220812.

Thanks. QGpgME should now also compile with strict C++11. And C++14'isms shouldn't happen again unnoticed.

Also in:

Thanks for the report! Should be fixed.

Thanks for the report. I've commited a fix. (Returning the c_str here is ok as the data is not meant to be modified once "action" is called)
Please let us know if you find additional issues.

Not really. off_t is a real portability problem and this why we moved that problem out of the GPGME ABI to the application. Thus the application needs to care about mapping gpgme_off_t to whatever off_t it uses. Without that we can't provide a stable _and_ toolchain independent ABI.

Thank you for pointing this out.

Following patch fixes the issue.

Maybe the off_t mess comes from following line

The gpgme c api already had a convenience function gpgme_data_rewind to do data.seek (0, SEEK_SET); As this is by far the most common seek operation. KMymoney also only uses such seeks.

In T3996#114721, @aheinecke wrote:

Uhm, yeah I would be willing to help. But I tried to understand it and don't see the problem.

So what the error tells us is that "off_t" is defined as long in the declaration but as something else in the definition.

But how can that be? data.cpp includes the data.h header so they both should have the same definition of off_t.

The only thing I could imagine is that something which is included in the cpp but not in the header undef's off_t and defines it to something else.

Or more likely that the archive was compiled with a different definition of off_t then what is included in the headers when kmymoney is built.

Are you using the same mingw version as the buildchain which compiles the gpgme binary?

Uhm, yeah I would be willing to help. But I tried to understand it and don't see the problem.

You are not cross-compiling. This is not suggested and I don't have the environment to replicate this. Maybe @aheinecke can help.