Changing this to priority low until I see a second report from a different user with a similar log.
This looks more like a broken Outlook setup on this users account then a problem where we can actually help.
No, which addons are active is a user property. So maybe you can try disabling all others but GpgOL, and then basically bisect which one it is that is conflicting.
The problem is that posix_spawn is not portable enough for libgcrypt. It is really time that we move the spawn functions from gnupg to gpgrt so that we can use them also in Libgcrypt.
BTW, I'm not sure if the claim in T5009#136688 is correct.
See also: https://dev.gnupg.org/T5009#136688
See my comment in: https://dev.gnupg.org/T5024#139701
After disabling SIP, now all checks pass without having the library symlinked to /usr/local/lib. So it might be T2056: libgcrypt: make check fails "random" test on OS X 10.11 with link error after all.
Wouldn't the incompatibility cause all the users to have the same problem, rather than one not and all others to have the problem?
Attached is the file that you requested.
In general there always might be problems with incompatibilities of other addins installed on a system.
there was an issue that has been fixed in 3.1.14 which was creating problems / crashes when the home directory of a user had a unicode character in it. So maybe your one user had such a username?
Another issue that comes in to mind is that current ARM/ARM64 HW feature detection most likely wont work on MacOS. Thus HW accelerated AES&SHA&GHASH implementation wont be used.
IIUC, for the build of Homebrew, it is the issue of in: https://github.com/Homebrew/homebrew-core/commit/e7da1e2157b2e8373c3b39ea6398f51588ea537c
Please have a look at T5024: libtool problem for some platforms for 'make check' (program built with -no-install won't work without installation), if make check works after the installation of libgcrypt.
HAVE_COMPATIBLE_GCC_AMD64_PLATFORM_AS is never defined on ARM64 as it depends on "$mpi_cpu_arch" == "x86". Instead I think new check for GCC assembly ELF directives would be needed in configure.ac, similar to HAVE_GCC_ASM_CFI_DIRECTIVES check. Following check should work, but I have not yet tested it:
ARM64 has been only tested on platforms which support ELF.
Sun, Nov 29
I am quite aware of that each user has there own keys and configurations.
I added a third user to the computer, configured them the same as the first user, and was not able to sign or encrypt any emails.
When I clicked on the lock nothing happened.
Yes, I did. Identical result.
Why the hell do they that? The standard compiler on a system is called cc which may translated to whatever the system installs for it. gcc is a specific implementation with certain properties. Di you try CC=clang to override this?
And the arm64 cross-compiler:
Sorry, I forgot to mention that Apple ships a gcc-wrapper for clang. It just accepts gcc command lines parameters and translates them to clang parameters.
Here is the output of gcc --version:
You say that you build using clang but the log shows that you invoke gcc.
Sat, Nov 28
The problem is meanwhile solved. Thanks a lot
Fri, Nov 27
No more problems reported, so I assume like @aheinecke that it has been resolved in Windows.
We changed the fallback to utf-8 in 2.2 and 2.3 and thus this bug can be closed. On Windows there is still the problem with the command line. However, this is better tracked with T5038 and its related tasks.
Thu, Nov 26
Recall that each user has their own keys and configuration. This seems to be a general question on how to use GpgOL. Please use the help resources listed at gpg4win.org instead of this bug tracker.
Because the original problem of EAFNOSUPPORT has been fixed, I am going to close this bug.
It is likely that EPERM (Operation not permitted) occurs by a system call connect(2) if you have some firewall rule(s) which forbids network access.
The dirmngr use libdns resolver which directly connects name servers.
If this is the case, you can use `--standard-resolver\ to use system's standard DNS resolver instead.
On Debian, please see: /usr/share/doc/g++-mingw-w64-i686-win32/README.Debian
IIUC, the error occurred when Kleo is exiting and a destructor (in libKF5ConfigWidgets) is called with null pointer.
Version 3.1.14 released 2020-11-25
Kleopatra / GnuPG: Unicode home directories are now supported. (T5055)