We now require a way to get the actual image of a process. For macOS the BSD method is used and we obviously need to find another way for macOS.

No, the error is harmless. I guess it shouldn't be printed (except when debugging).

unix_rootdir() is guarded with

#ifndef HAVE_W32_SYSTEM /* Unix */

It would make sense to also exclude macOS.

OTOH, this is now also used when running tests which means tests couldn't be run on macOS.

The point of unix_rootdir() is to find out whether a gpgconf.ctl file exists next to the gpgconf executable. I guess we need an alternative implementation for macOS for this. Would be great if someone more familiar with macOS could provide a patch.

On macOS _NSGetExecutablePath could be used, but iiuc this requires linking against dyld. For other OSes we would also need more code. I doubt that this makes a lot of sense these days; but we should come up with a solution, even if that means we need an envvar to specify the location of that open gpgconf.ctl file.

Urgs, I already implemented this:

if ((name = getenv ("GNUPG_BUILD_ROOT")) && *name == '/')
    {
      /* Try a fallback for systems w/o a supported /proc
       * file system.  */
      xfree  (buffer);
      buffer = xstrconcat (name, "/bin/gpgconf", NULL);
      log_info ("trying fallback '%s'\n", buffer);
    }

I second this. This is problematic on (Free)BSD too, where /proc is usually optional and might not be mounted at all. I concur that this should be silenced if not running in debug mode.

Can't we use $(bindir) at configure time to figure the path? Or perhaps I don't understand the difference with the gnupg_bindir function in the same file :/

gnupg_bindir() uses unix_rootdir() falling back to the builtin configure time path if unix_rootdir() returns NULL. So, there is no difference.

$(bindir) at configure time may be completely different from the actual location of the binary at runtime, e.g. in case of AppImages where the actual location of the binary inside the AppImage is some path below a temporary mount point.

Thanks for the clarification. So it's just a matter of not emitting the warning I guess?

It seems like this warning does break some usages of gnupg on macOS.
We found one when packaging this in Homebrew: https://github.com/tadfisher/pass-otp/issues/147