I found this in the change log of Qt 5.4.2:

- On x86 and x86-64 systems with ELF binaries (especially Linux), due to
  a new optimization in GCC 5.x in combination with a recent version of
  GNU binutils, compiling Qt applications with -fPIE is no longer
  enough with GCC 5.x. Applications now need to be compiled with
  the -fPIC option if Qt's option "reduce relocations" is active. For
  backward compatibility only, Qt accepts the use of -fPIE for GCC 4.x
  versions.
  Note that Clang is known to generate incompatible code even with -fPIC if
  the -flto option is active.

So I think that the problem here is that ArchLinux either does not build Qt6 with -fPIC or it does and others don't and that our check for wether or not to add -fPIC is not really working as it should. When compiling executables we should also add -fPIE instead of -fPIC.

I found this related to that: https://sourceware.org/bugzilla/show_bug.cgi?id=28875

Compiles for me, too with Qt 6.5.2 from tumbleweed.

The official build for Arch Linux doesn't seem to run into this problem. The Qt6 build is configured with

./configure \
  --prefix=/usr \
  --disable-fd-passing \
  --disable-static \
  --disable-gpgsm-test \
  --enable-languages=cpp,qt6

See https://archlinux.org/packages/core/x86_64/gpgme/

This is now mostly done. These 3 patches make it work:

Nevermind we clarified in chat that we would instead deprecate this API.

Kleopatra doesn't rely on the defaults in the library and other users shouldn't either. I would kill defaultkeygenerationjob. And it's use in newkeyapprovaldialog should be fixed, e.g. by using QuickJob::startCreate().

The MSI Package though is a 64 bit MSI Package. For 32 Bit Windows we would need to ship a different MSI Package. (Which we actually have build support for because I thought that was neccessary even in 2020)

No, everything in Gpg4win is 32 bit, except for gpgol, gpgex and gpgme, libgpg-error and libassuan. Which are addionally installed under bin_64. But for the whole KDE stack it should easily be switchable. The KDE Windows project regularly builds them as 64bit applications. Basically we would then need to invert the logic and use the 64 bit compiler as the main compiler and the 32 bit compiler as the _ex compiler for gpgol and gpgme.

Kleopatra is a 64 bit application, right? For GnuPG we are working on 64 bit support for Windows. This is planned for 2.6. problems are how to represent sockets, file descriptors, streams and so on. Regarding the time interface, we should have everything ready in the GPGME<->GnuPG interface. In GPGME we need to check that we don't use int instead of time_t, though. When that has been done/fixed we could use a 64 bit gpgme and kleopatra along with the 32 but gnupg. Might be easier for approval reasons.

Mh, since there are no 32bit Versions of Windows sold for quite some years now maybe we should consider just going full 64bit with everything to solve this? Or is this a stupid suggestion?

It turned out that we need to fix this for use by Kleopatra on Windows.

Fixed. Removing Gentoo tag because it's not Gentoo-specific.

I'll swap us over to out of source build for this as well. I've been doing it gradually for the gpg suite. Thanks.

The following patch fixes this (for me):

diff --git a/lang/qt/tests/Makefile.am b/lang/qt/tests/Makefile.am
index 32ad6466..aedd3264 100644
--- a/lang/qt/tests/Makefile.am
+++ b/lang/qt/tests/Makefile.am
@@ -51,10 +51,10 @@ LDADD = ../../cpp/src/libgpgmepp.la ../src/libqgpgme.la \
         ../../../src/libgpgme.la @GPGME_QT5_LIBS@ @GPG_ERROR_LIBS@ \
         @GPGME_QT5TEST_LIBS@ @LDADD_FOR_TESTS_KLUDGE@ -lstdc++

This happens because you build in the source directory and therefore the wrong debug.h is found. While this should work in general we strongly suggest to use a separate build directory.

Done. Will be tested with T5903: Kleopatra: Add refresh button in certificatedetails .

Minor correction of the interface changes:

qt: toLogString                            NEW.

Yes, gpgtar emits a SUCCESS status. gpgme should probably check for this.

Done. This can be tested with the run-import test runner (which I did).

Closing. For now, all that's needed has been added to GpgME. Additional changes in Kleopatra are tracked in T5903: Kleopatra: Add refresh button in certificatedetails . If further changes in GpgME are needed, then a new task will be opened.

Should be fixed.

The error was changed to "Bad data" which should be more appropriate.

I would change the error to GPG_ERR_BAD_DATA .

I had a look at this. gpg emits the following status messages:

[GNUPG:] UNEXPECTED 0<LF>
[GNUPG:] FAILURE decrypt 38<LF>

@ikloecker I think your logs contain only false positives, I do not know that we use any defines created by config.h. Maybe for gpgme_off_t but even so when I moved gpgme++ and qgpgme from kdepimlibs into the GPGME repo I did not add any defines to configure for that.

One complication comes from the fact that gpgmepp and qgpgme include the global config.h that is generated by configure. This needs to be replaced. I'll attach two files where I grepped for usage of the config.h's #defines (generated on Linux) in lang/cpp and lang/qt. The files probably contain false positives.

I was able to find the Craft blueprint with the CMake build system in my Win VM and pushed it to invent: https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/5e9aae4d006f69657d3612c2fe398c9e5ae69ac0, feel free to use it for inspiration or base for future work, or ignore it completely :). It's probably far from a production-ready CMake script, some years ago I just really really *really* wanted to build KMail on Windows (don't ask why) so I did some unspeakable evils to make it happen. This is one of the better things that came out of it...

as this task is for a technical restructuring task, which is obviously done and works, closing this ticket.

On the command line:

gpgtar -v --status-fd 2 -er Ted -s -o tt.tar.gpg tiefer_test

leaves a .tar.gpg file behind, too, if

• you kill it with CTRL-C
• if you call it without -s and stop the gpgtar.exe process in the task manager
• if you call it with -s and give the correct password

I'm wondering why I don't see something like

org.kde.pim.kleopatra: slotResult Removing output file ... after error or cancel

in the debug output. It should be output whenever the signing and/or encryption job ended with a non-zero error code and the output file exists. (See commit on 22 June).

On Windows the process is stopped but you end up with a too small archive.
If you cancel immediately (presumably as long as the file still has size 0) it is removed, though.

I ran the test AES.OCB encrypt only, no compression test with the same GnuPG 2.4 version on Linux.

This works.

When the output parameter is given it might even clean up a temporary file on error, but it might also not so we should make sure on a higher level that we check for that and remove it when gpgtar crashes or something like that.

Due to the double fork in gpgme we won't get the exit code which gpgtar emits. Possible actions in a signal handler are also limited; in particular we can't use stdio or estream. The only option to print a status line would we by using write directly. However, this might mess with the libassuan buffering. Thus, it is not a good idea to pkill gpgtar. Same is true for gpg and gpgsm.

ready for testing

Done. Can be tested and closed with T5478: Kleopatra: Performance problems decrypting and encrypting large Archives.

I tested this with OpenPGP and 2.4.3-beta19 on Windows. Worked nicely.

And of course we also need to adjust GPGME

I'm reopening this. Its probably not a regression but I was sure that we had progress for large files fixed in the past.

Yeah no progress for files larger then 32 bit o.O... But this used to work 😭

On 64 bit linux this works btw. so I think it comes down to the difference between 32 bit off_t and 64 bit off_t

Yeah, its the ugly off_t again. I am just testing how this works with single files above that threshold we worked quite a bit on this back in the days https://dev.gnupg.org/T2368

Yeah, probably a Windows/MinGW 32-bit problem. GpgME::Data does

off_t size = seek(0, SEEK_END);
seek(0, SEEK_SET);
std::string sizestr = std::to_string(size);
// Ignore errors as this is optional
gpgme_data_set_flag(d->data, "size-hint", sizestr.c_str());

Probably some issue with large files / integer overflow. I am testing on Windows with 32 bit.

Mh, let me check where the size hint should come from and why it might be missing in my windows test. That is indeed strange then.