My apologies, I have only just discovered that my reply to this had gone only to Werner and not to the mailing list.
Probably the single most important "this needs addressing" aspect of my report was the part about Python 3 integration. As currently shipped it _cannot_ work, in a way completely unrelated to the newness or oldness of my machine and OS. To reïterate: GPGME invokes "setup.py" directly, which is now so heavily deprecated that it straight up doesn't work under Python 3.10. Also, something about the process that steps through the various Pythons it locates (in order to correctly compile the bindings against each one) is not working, such that it creates a directory structure for each Python (in which to build the libraries), but only actually uses the first one. Interestingly, copying the files thus compiled into the other directories in order to pretend it worked correctly does allow installation to proceed, and even seems to execute correctly with the wrong Python... I wouldn't want to trust that for anything critical, though. I suspect there are important differences between extensions built for Python 2.7 vs. 3.10 or you wouldn't have bothered going to all that trouble in the first place. > On Nov 6, 2024, at 2:21 AM, Werner Koch <[email protected]> wrote: > > Thanks for the detailed writeup. My pleasure! I only hope it is useful in some way. > On Tue, 5 Nov 2024 20:20, Gordon Steemson said: > > I do not known whether Apple'ss gcc 4.2 is the part of XCode or if this > is an alternative toolchain. It was the compiler used by Xcode before Clang was developed, and is contemporary with the system. > Regarding universal binaries we have this > in the README of GnuPG *1.4*: > > Building Universal Binaries on Apple OS X [snip] Yes, I know, that's part of why I was using that compiler instead of building a newer one first. That part works fine. Actually, the fact that part works fine is worthy of effusive praise! Many projects out there seem to insist on recording the bit width of various integer types as constants during their ./configure step, which causes chaos in a universal binary because during such a build, longs and pointers are each both 32 and 64 bits wide at the same time (as controlled by conditional compilation on __LP64__). GnuPG does not suffer from this problem, which saves *SO* much trouble it's not even funny. >> support software (such as cURL, >> OpenSSH, and ld), I had to write the following patch: > > GnuPG does not use OpenSSL or cURL. Which version of GnuPG are you > trying to build? Some bit rot for old macOS versions may of course > happened. Yes, I know it doesn't, at least not directly. I was building the latest release from the website. I honestly don't recall what it was that a newer cURL helped with – it may have been something else I was doing at the same time, for all I can tell without it in front of me (I am on my lunch break at work). That said, it definitely does use OpenSSH (not OpenSSL) during one of the "make check" tests, though as you point out not in the actual program itself. (It gave me a good surprise when that popped up; apparently whatever it was doing needed a more recent OpenSSH than the version current in 2005. For obvious reasons that was not a thing I consider worthy of a bug report, merely a passing observation.) > Maybe someone of the otehr macOS folks can shed some light on the > reported problems. That would be good. Does anyone out there want to weigh in on this? Gordon Steemson _______________________________________________ Gnupg-devel mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-devel
