macOS: IOKit framework location corrected. #120

Merged
0xDP merged 1 commit from master into master 2019-12-07 10:54:08 -06:00
0xDP commented 2019-11-17 12:32:47 -06:00 (Migrated from github.com)
The referenced location of IOKit framework is wrong. See https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/OSX_Technology_Overview/SystemFrameworks/SystemFrameworks.html for details.
Youw commented 2019-11-17 14:20:46 -06:00 (Migrated from github.com)

thanks for your PR

seems reasonable, but we have to take into account the fact that this has been working for years, and I don't recall any issues related to it

best case scenario, if we could test it on all versions of macOS starting with 10.6 and check how exactly does this work (before/after the change), not to accidentally cause some regressions
Any volunteers?
After second though, no need - since we link against IOKit.framework this path is not relevant - dlopen would simply return a reference to already loaded library (by name)

I can check only latest macOS 10.15 (Catalina):
It works as expected before AND after this patch - IOKit.framework gets loaded just fine
I almost sure, this is because libhidapi.dylib is linked against IOKit.statically for some reason:

$ otool -L mac/.libs/libhidapi.0.dylib 
mac/.libs/libhidapi.0.dylib:
	/usr/local/lib/libhidapi.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1673.126.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)

Secondly, I'm not sure we want to support macOS 10.5 and older (for the same reason we dropped support of Linux 2.x(something) earlier, and simpler would be just to link against IOKit.framework statically, and don't do this dynamic load at all

thanks for your PR seems reasonable, but we have to take into account the fact that this has been working for years, and I don't recall any issues related to it ~best case scenario, if we could test it on all versions of macOS starting with 10.6 and check how exactly does this work (before/after the change), not to accidentally cause some regressions~ ~Any volunteers?~ After second though, no need - since we link against `IOKit.framework` this path is not relevant - dlopen would simply return a reference to already loaded library (by name) I can check only latest macOS 10.15 (Catalina): It works as expected before AND after this patch - `IOKit.framework` gets loaded just fine I almost sure, this is because libhidapi.dylib is linked against IOKit.statically for some reason: ```sh $ otool -L mac/.libs/libhidapi.0.dylib mac/.libs/libhidapi.0.dylib: /usr/local/lib/libhidapi.0.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1673.126.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0) ``` --- Secondly, I'm not sure we want to support macOS 10.5 and older (for the same reason we dropped support of Linux 2.x(something) earlier, and simpler would be just to link against `IOKit.framework` statically, and don't do this dynamic load at all
Youw (Migrated from github.com) approved these changes 2019-12-07 10:53:44 -06:00
Youw (Migrated from github.com) left a comment

a second thought:
#121 will go for next release
let's have this one

a second thought: #121 will go for next release let's have this one
Youw commented 2019-12-07 10:56:21 -06:00 (Migrated from github.com)

Fixes #119

Fixes #119
cyberstudio10 commented 2020-01-19 20:27:38 -06:00 (Migrated from github.com)

This fix actually fixed my problem in Mojave and Catalina. My app worked until put in a sandbox and signed with Hardened Runtime with the com.apple.security.device.usb entitlement. hid_enumerate put empty strings in the path field and I was not able to open anything. This was fixed when the path to dlopen was corrected. Just here to say thank you for this fix and to confirm that this fix has real world significance even though things seem to have been working for many many years.

This fix actually fixed my problem in Mojave and Catalina. My app worked until put in a sandbox and signed with Hardened Runtime with the com.apple.security.device.usb entitlement. hid_enumerate put empty strings in the path field and I was not able to open anything. This was fixed when the path to dlopen was corrected. Just here to say thank you for this fix and to confirm that this fix has real world significance even though things seem to have been working for many many years.
Sign in to join this conversation.
No reviewers
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-libusb/hidapi!120
No description provided.