Hi Chris,
> Op 26 aug. 2020, om 22:54 heeft Chris Hanson <cmhanson%eschatologist.net@localhost> het volgende geschreven:
>
> [...]
>
>> 2. Look for .tdb in the SDK instead of installed .dylibs in /usr/lib.
>
> This is the route I would take if you absolutely need to know whether a library is present.
>
> To find the macOS SDK provided by the selected Xcode, you can use xcrun and pass its identifier:
>
> $ xcrun --toolchain default --sdk macosx --show-sdk-path
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
When I went to add this to mk/Darwin.mk, I noticed it was already
there, including some logic to make sure it's the right SDK version.
-_OPSYS_LIB_DIRS?= /usr/lib
+_OPSYS_LIB_DIRS?= ${OSX_SDK_PATH}/usr/lib
This path will be checked for lib${_lib_}.* in mk/buidlink3/find-libs.mk
which matches the .tbd files and it all works.
Thanks for your excellent elaboration on the target aspects and
code signing - I'm familiar with them but it's a good refresher.
As for code signing, the ad hoc signing seems to suffice for now
if I read the documentation correctly*. I agree signing with Apple
developer certificates would be a good feature.
> [...]
Attached a simple patch fixing the issue for review. Barring comments
I'll commit it later this week.
Sijmen
Attachment:
Darwin.mk.patch
Description: Binary data