Sure. Thanks for testing. The problem with new versions is that ppl don't like to test release candidates and thus we need do real releases and wait for the outfall. ;-)

Breakage appears to happen in configure.ac. When building with clang without LTO following check gives "no":

Maybe it helps:
Here is another log from a user with a similar looking problem, same symptoms:

Fixed by jukvilli’s patch.
__outer

That works, thanks. So does that become part of the next release?
__outer

Both are affected. I updated to reflect that I tested the newer version

Thanks for the reports. IIRC, we had similar reports in the past either here or on a ML.

• For build problems on Raspberry PI see T5251 for a patch
• If you run into "selftest" error see T5254 for a patch (which should be applied in any case)

FWIW, after the release I had some time and after some trouble with my Pi4B I ran into the same problem.

So is this about 1.8.7 or 1.9.0 (as shown in the Version field)?

In fact, Thunderbird does not use gpgme-json, but loads the gpgme shared library at runtime. The interesting thing is that Thunderbird works fine if gpgOSX is used.

Yes, clang + LTO is broken. Maybe there is issue in clang bug tracker for this already?

Maybe this patch helps:

Similar to T5252, likely requiring the concept of some kind of "fixed reference date".

Looking at the backlog of pinentry-related issues, I don’t think that would warrant delaying further the release of pinentry-1.1.1, especially given that the last release was 3 years ago already. Remaining issues (most of them being stalled anyway) or feature requests can be postponed for a future pinentry-1.2.0.

Confirmed working after applying your patch!

The fix will be part of the upcoming pinentry-1.1.1.

Thanks for you report.

@gniibe I assume this issue has been fixed by the same fix as for T4585 and can be closed as well. Feel free to re-open if I am wrong.

Reading the bugzilla report it seems that TB is loading gpgme at runtime. In particular the hints on using externally build stuff (Homebrew) is worrying. Someone(tm) needs to check how gpgme is used by TB and that it is properly initialized. GPGME is actually not designed to be loaded at runtime but should be used as standard shared object or static library.

Thanks for the reply. Not sure about GPGME/gpgme-json. Anyway, it still ends up in gpgme code, isn't it?
I used to modify gpgme sources to receive more information about the issue.
Looks like the next step would be to modify gpg-conf and see what's going on there, or leave it to the Thunderbird developers.

Dependency hell - ask your favorite distribution

Sure that TB uses GPGME - they claimed they won't use it due to license incompatibility (LGPL). I assumed they use gpgme-json via naticve messaging. Regarding the error - I have no idea.

Can you point me to a more elaborate list of the general concerns? (Central directories offer some sort of stable history, namespace and API service towards identifying modules, just like the venerable https://www.ctan.org/ . The solutions built on such services, like programming environment specific "package" and dependency managers that download and install thousands of packages automatically (like yarn) may be debatable, but I am not aware of much general concern against the services itself.)

Thanks for the feedback

Ok, I found the message and tried some opening and clicking around w/o any crashes. But back then I also couldn't reproduce it. Please close the issue. I'll ask for reopening if I ever come across it once more. Thanks for your good work!