Thank you for your report.

The use of putc_unlocked has long been removed. So we should also remove the declaration. Normally this does not harm but in your case you may want to pass CFLAGS="-DHAVE_PUTC_UNLOCKED" to make or remove the above declaration.

Verified the fix.

Pushed the change to master. Please test.
rCbb0895bbb7c6: m4: Fix acinclude.m4 for underscore detection in the symbol.

Thank you for the report.

Thanks for the detailed analysis; we will check to tomorrow why this was changed.

Here is a fix for the issue which preserves the removal of cut:

See: MacPorts Ticket 70267 and MacPorts PR #24601

While the above patch worked for MacOS 10.8 and above, MacPorts CI shows a second error for older MacOS versions:

It looks like various flavors of BSD (including macOS just declare environ when needed): environ -- user environment Note: this is a very old MacOS X man page, however the current version is from 2003, and has the same Synopsis.

This diff for 1.11.0 fixes the problem for me:

The following logic from 1.11.0 acinclude.m4 cannot possibly work to detect _ at the beginning of symbol names:

The toolchain is clang / llvm and the apple ld, native build, not cross compiling.

Meanwhile version 1.32.2 builds. Greatest change is Python 3.12 instead of 3.11…

Sorry, I meant they do *not* arrive at the web interface, they are not visible to me.

It seems my eMails to gnupg-devel@gnupg.org do reach the list …

On Mac OS X 10.5.8, PPC Leopard, it built with the patch, gpg-agent works.

Trying to reach Ralph Seichter via the eMail address he is using failed – Osterferien?

Thank you for your quick testing.

I've reported the success to MacPorts. My test was performed on only one platform, Mac OS X 10.4.11 or "Tiger". Since there exists a problem with building recent version of GPGME testing on Mac OS X 10.5.8 or "Leopard" will have to wait a few days…

With the unified patch all works fine (again), even the test target succeeds!

Performing the patch manually the "port" (package) built and installed. Starting then gpg-agent worked too, killing it (with gpgconf) worked as well.

The patches looks too large to merge (than actually needed), and not enough/clean like not having detection of the system.

strcasecmp is pretty standard on Unix. However, in GnuPG we test for it and mostly use our own ascii_strcasecmp to avoid fun with locales. Ralph Seichter is providing macOS builds for GnuPG (https://sourceforge.net/p/gpgosx/docu/Download/) . Maybe it is worth to contact him via the gnugp-devel mailing list and ask him whether he has experience with your toochain.

By adding "-Wl,-t" to the arguments g++ reported:

Libtool invocation has "--tag=CXX --mode=link /opt/local/bin/g++-mp-7 -std=c++11 -pipe -Os -std=c++17 -D_GLIBCXX_USE_CXX11_ABI=0", but g++ then has no -lstdc++ – in C -lc is automatically used because there all C library functions can be taken from… (same for mathematical functions and -lm)

It seems libtool fails to add the standard C and C++ libraries to the link command line. On Linux I have "[...] -lstdc++ -lm -lc [...]" in the libtool link command line. Looks like a bug in the tooling (macports or libtool).

The solution seems to be a newer libccid version. If that is the case we may want to include the fix also in our own ccid driver.

Got this from my card vendor. Sonoma had a buggy CCID driver; compile one yourself and the bug's gone: https://forums.developer.apple.com/forums/thread/732091?answerId=768462022#768462022

For reference, here is a link to the gpgme homebrew formula:
https://github.com/Homebrew/homebrew-core/blob/master/Formula/g/gpgme.rb

Just to clarify, PIP wasn't used to install the .egg package. The package was built and installed via Homebrew. The error message occurs when using basic PIP commands such as pip list or pip freeze. PIP is picking up the gpgme egg from the shortcut included in the site-packages directory.

We don't use or suggest the use of PIP or other insecure software distribution systems.

Well, this bug is fixed by using a decent libgpg-error or configure it correctly.

Funny error description from macOS. Looks that there is no device - your PC/SC test programs confirms this. Thus I don't think this is a bug in scdaemon.