Posts

Post not yet marked as solved
1 Replies
298 Views
With XCode 14 and below, our macOS application is building and running fine. The application depends on some third-party .dylibs and also a couple of .frameworks that we make in-house, all of which are happily in the .app bundle and working. When compiled under XCode 15, the application crashes because one of our .frameworks now tries to load these dylibs which cannot be found if run on a machine that didn't build it. Note that previously, this framework never depended on these dylibs before, but the application does. The rpaths for these dylibs are pointing to the build dependencies folder, which would only exist on a build machine. Also, the dependencies are now looking for versioned dylib filenames, while the application itself depends on the un-versioned dylib filenames. So to recap, that's 3 new problems when building with the new linker: The framework is now dependent on dylibs that normally only the application depends on The new dependency is on versioned dylibs, where the original application dependency is on un-versioned dylibs The framework's rpaths now include intermediate build folders Running otool -L on the framework binary shows a clear difference between ld_prime and ld_classic. The dependencies on the third-party dylibs are only showing up when the framework is built with the new linker. We have a couple of workarounds: Using ld_classic to build our application with the old linker Using post-build commands (install_name_tool) to change the dependencies and remove the build folders from the rpaths Though ultimately, workaround 1) could only be temporary and 2) is hacky. We'd like to understand why the linker is exhibiting this new behaviour, so we can make the proper adjustments to fix this the correct way. Any insight would be greatly appreciated. Thanks in advance. Note: this is a cross-platform product, and CMake is used to generate the .xcodeproj project file.
Posted
by Jeffrey_B.
Last updated
.
Post not yet marked as solved
0 Replies
908 Views
We have retired our old USB kext and reimplemented our new USB stack using the IOUSBHost API and the VM DeviceAccess entitlement in our product. Everything is going fine...except for this one edge case. We have a USB device that does not have a String Descriptor for the Product name. Apparently some USB devices will report an iProduct of 0 in their Device Descriptor, therefore Product String Descriptor failing. If I look at the output from system_profiler SPUSBDataType or ioreg -p IOUSB -l with the device attached, I can see that there is no Product name anywhere. I can combine the output of the two commands to narrow down the device based on its serial number. System profiler snippet: Miscellaneous Device: Product ID: 0x0990 Vendor ID: 0x046d (Logitech Inc.) Version: 0.08 Serial Number: 1345602E Speed: Up to 480 Mb/s Location ID: 0x14110000 / 21 Current Available (mA): 500 Current Required (mA): 500 Extra Operating Current (mA): 0 IOReg snippet: | +-o IOUSBHostDevice@14110000 <class AppleUSBDevice, id 0x100004897, registered, matched, active, busy 0 (4 ms), retain 20> | { | "sessionID" = 62015500304018 | "idProduct" = 2448 | "iManufacturer" = 0 | "bDeviceClass" = 239 | "bMaxPacketSize0" = 64 | "bcdDevice" = 8 | "iProduct" = 0 | "iSerialNumber" = 2 | "bNumConfigurations" = 1 | "Bus Power Available" = 250 | "USB Address" = 21 | "Built-In" = No | "locationID" = 336658432 | "bDeviceSubClass" = 2 | "bcdUSB" = 512 | "kUSBSerialNumberString" = "1345602E" | "PortNum" = 1 | "non-removable" = "no" | "AppleUSBAlternateServiceRegistryID" = 4294985877 | "bDeviceProtocol" = 1 | "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBHostFamily.kext/Contents/PlugIns/IOUSBLib.bundle"} | "IOPowerManagement" = {"DevicePowerState"=0,"CurrentPowerState"=3,"CapabilityFlags"=65536,"MaxPowerState"=4,"DriverPowerState"=3} | "kUSBCurrentConfiguration" = 1 | "Device Speed" = 2 | "idVendor" = 1133 | "IOGeneralInterest" = "IOCommand is not serializable" | "USB Serial Number" = "1345602E" | "IOClassNameOverride" = "IOUSBDevice" | } The solution I'm looking for is a fallback method to read the product name "QuickCam Pro 9000", as this is the string reported on other operating systems. I know a fallback is possible on at least Linux, using a table in /usr/share/misc/usb.ids. Is there any macOS API or command we can use to get the Product string for such devices?
Posted
by Jeffrey_B.
Last updated
.
Post not yet marked as solved
2 Replies
625 Views
Background: I am using Security.framework to verify the code signing requirements for incoming XPC connections (from listener: shouldAcceptNewConnection: in NSXPCListenerDelegate), as mentioned here: https://developer.apple.com/forums/thread/72881 Problem: It is working well (for our normal processes), but not for when the XPC connection is coming from our Audio Server Plug-in. In this case, the main problem is that the SecCodeRef I'm getting is from the coreaudiod process, which is hosting the Audio Server Plug-In. I don't want coreaudiod's code-signing information; I want my plugin's code-signing information. The current way I am getting the SecCodeRef is using the newConnection.processIdentifier, or the NSXPCConnection's audit token (if exposing the private API), but alas, those are for the hosting process and not my plugin. Question: How do you get a dynamic SecCodeRef for a plugin and not the hosting process? Possible Attempts: I have tried looking at the header file for SecCodeCopyGuestWithAttributes() and how the first argument, host, used as a starting point, as if you can nest and drill down, but I haven't gotten that to work. I could probably get a SecStaticCodeRef ,for the binary on disk, but that is not the dynamic running code.
Posted
by Jeffrey_B.
Last updated
.