#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)
Change History (8)
Changed 4 years ago by grumpybozo (Bill Cole)
Attachment: | libgcrypt-random-rndlinux.patch added |
---|
comment:1 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | Schamschula removed |
---|---|
Owner: | set to Schamschula |
Status: | new → assigned |
Summary: | libgcrypt 1.9.1_0 broken on SnowLeopard → libgcrypt @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 4 years 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 4 years 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:
- On Snow Leopard, the current prebuilt MacPorts package of libgcrypt, when used via the current prebuilt MacPorts package of gnupg2, is broken.
- 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 follow-up: 5 Changed 4 years 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.
But - that's just me. And I haven't actually tried it yet.
comment:5 follow-up: 7 Changed 4 years 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.
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 4 years ago by Schamschula (Marius Schamschula)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:7 Changed 4 years 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.
Patch to fix libgcrypt 1.9.0 on older systems.