Opened 3 months ago

Closed 3 months ago

Last modified 3 months ago

#62278 closed defect (fixed)

libgcrypt @1.9.1_0 broken on SnowLeopard

Reported by: grumpybozo (Bill Cole) Owned by: Schamschula (Marius Schamschula)
Priority: Normal Milestone:
Component: ports Version: 2.6.4
Keywords: haspatch Cc:
Port: libgcrypt

Description

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.

Attachments (1)

libgcrypt-random-rndlinux.patch (423 bytes) - added by grumpybozo (Bill Cole) 3 months ago.
Patch to fix libgcrypt 1.9.0 on older systems.

Download all attachments as: .zip

Change History (8)

Changed 3 months ago by grumpybozo (Bill Cole)

Patch to fix libgcrypt 1.9.0 on older systems.

comment:1 Changed 3 months ago by ryandesign (Ryan Schmidt)

Cc: Schamschula removed
Owner: set to Schamschula
Status: newassigned
Summary: libgcrypt 1.9.1_0 broken on SnowLeopardlibgcrypt @1.9.1_0 broken on SnowLeopard

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.

comment:2 Changed 3 months ago by 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.

comment:3 Changed 3 months ago by 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..

comment:4 Changed 3 months ago by 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.

comment:5 in reply to:  4 ; Changed 3 months ago by 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. :)

comment:6 Changed 3 months ago by Schamschula (Marius Schamschula)

Resolution: fixed
Status: assignedclosed

comment:7 in reply to:  5 Changed 3 months ago by 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.

Note: See TracTickets for help on using tickets.