libgcrypt @1.9.1_0 broken on SnowLeopard

[grumpybozo (Bill Cole)]

Running freshly updated gpg from gnupg2 port with freshly updated libgcrypt port:

$ gpg
dyld: Symbol not found: _getentropy
  Referenced from: /opt/local/lib/libgcrypt.20.dylib
  Expected in: flat namespace
 in /opt/local/lib/libgcrypt.20.dylib
Trace/BPT trap

Extensive discussion of the problem is at ​https://dev.gnupg.org/T5268 and it has been fixed upstream.

[grumpybozo (Bill Cole)]

Patch to fix libgcrypt 1.9.0 on older systems.

[ryandesign (Ryan Carsten Schmidt)]

I don't agree with the fix.

There's nothing special about OS X 10.11 in the context of this problem and there's no reason for it to be singled out in the code.

​getentropy appeared in macOS 10.12. That means it's in the 10.12 SDK.

If you build with e.g. the 10.12 SDK but with a deployment target set for an earlier OS version, then any symbols introduced in 10.12 will appear as weak symbols and it is the program's responsibility to check at runtime whether or not the symbol exists before using it.

That's how Apple's SDKs work. It's not specific to getentropy or 10.11 or 10.12.

It just so happens that the last version of Xcode that is compatible with OS X 10.11 is Xcode 8.2.1 and it contains only the 10.12 SDK.

This is standard operating procedure for Apple. The last version of Xcode compatible with any macOS version typically includes the next macOS version's SDK.

And of course if you're compiling on 10.11 you'll want to run the result on 10.11 so you'll have set the deployment target to 10.11. (That is in fact its default value when you are on 10.11.)

So if you are compiling on 10.11 with Xcode 8.2.1 (or any earlier 8.x) you'll be using the 10.12 SDK and getentropy will be available as a weak symbol. The same would happen if you compile on 10.12 or later but set the deployment target to 10.11 or earlier.

But if you are compiling on 10.11 with Xcode 7.x then you'll be using the 10.11 SDK and getentropy will not be available at all.

The MacPorts buildbot worker for OS X 10.11 happens to be using Xcode 8.2.1 and thus the 10.12 SDK. On most of the other buildbot workers, I've deliberately not upgraded Xcode to the latest major version specifically so that we keep an SDK version that matches the OS version in order to avoid this class of problem.

[jmroot (Joshua Root)]

On macOS < 10.14 you can avoid the issues Ryan described by not using -isysroot and letting the compiler find headers in /usr/include and the linker find libraries in /usr/lib. That should be what happens on the buildbot, and indeed in the most recent log:

checking for getentropy... no

Seems like they should be believing negative results from this check, even if further checking on positive results is needed in the case of using an SDK newer than the OS. Snow Leopard will certainly not have getentropy either in the system headers or in the SDKs though.

[grumpybozo (Bill Cole)]

I don't claim the provided patch (which I just copied from what was applied as a fix upstream) is the right fix, but it does fix the problems I see:

1. On Snow Leopard, the current prebuilt MacPorts package of libgcrypt, when used via the current prebuilt MacPorts package of gnupg2, is broken.
2. Packages built locally using mp-clang-9.0 (i.e. no -isysroot) on SnowLeopard (i.e. with the MacOSX10.6 SDK) still have the same failure..

[kencu (Ken)]

Most likely we just add legacysupport and put poor upstream out of their misery of trying to sort out 15 year old operating systems.

<​https://github.com/macports/macports-legacy-support/blob/0e85bd9f0fed7d80c85fe90e52ebf029d2a439f7/src/arc4random.c#L579>

But - that's just me. And I haven't actually tried it yet.

[grumpybozo (Bill Cole)]

Replying to kencu:

Most likely we just add legacysupport and put poor upstream out of their misery of trying to sort out 15 year old operating systems.

<​https://github.com/macports/macports-legacy-support/blob/0e85bd9f0fed7d80c85fe90e52ebf029d2a439f7/src/arc4random.c#L579>

But - that's just me. And I haven't actually tried it yet.

So, I just added this line to the Portfile:

PortGroup       legacysupport 1.1

and rebuilt libgcrypt. It works.

I love legacy-support. It's my absolute favorite port. :)

[Schamschula (Marius Schamschula)]

In 74b50424649a7c657521140fcd7f92ba79a3cec5/macports-ports (master):

libgcrypt: add legacysupport PG to support older systems

Closes: #62278
See: ​https://dev.gnupg.org/T5268https://github.com/macports/macports-ports/pull/143190

[kencu (Ken)]

Replying to grumpybozo:

I love legacy-support. It's my absolute favorite port. :)

Hey, you don't know how happy that makes me -- way back when, It was Marius and me who initially got it going.... saves a ton of hassles.