<div dir="ltr"><div dir="ltr">On Mon, Apr 4, 2022 at 5:26 PM Ryan Schmidt <<a href="mailto:ryandesign@macports.org">ryandesign@macports.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Apr 4, 2022, at 14:25, Dave Allured - NOAA Affiliate wrote:<br>
> On Sun, Apr 3, 2022 at 4:23 PM Ryan Schmidt wrote:<br>
>> On Apr 1, 2022, at 13:09, Artemio González López wrote:<br>
>> <br>
>> > After executing “port diagnose” in my 2020 13” MacBook Pro running the latest version of the operating system (Monterrey 12.1.3, I believe) I got the following output:<br>
>> > <br>
>> > Warning: objc[10836]: Class AppleTypeCRetimerRestoreInfoHelper is implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5eb0) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1053484f8). One of the two will be used. Which one is undefined.<br>
>> > objc[10836]: Class AppleTypeCRetimerFirmwareAggregateRequestCreator is implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5f00) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x105348548). One of the two will be used. Which one is undefined.<br>
>> > objc[10836]: Class AppleTypeCRetimerFirmwareRequestCreator is implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5f50) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x105348598). One of the two will be used. Which one is undefined.<br>
>> > objc[10836]: Class ATCRTRestoreInfoFTABFile is implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5fa0) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1053485e8). One of the two will be used. Which one is undefined.<br>
>> > objc[10836]: Class AppleTypeCRetimerFirmwareCopier is implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5ff0) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x105348638). One of the two will be used. Which one is undefined.<br>
>> > objc[10836]: Class ATCRTRestoreInfoFTABSubfile is implemented in both /usr/lib/libauthinstall.dylib (0x1f6af6040) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x105348688). One of the two will be used. Which one is undefined.<br>
>> > objc[10837]: Class AppleTypeCRetimerRestoreInfoHelper is implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5eb0) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1085e04f8). One of the two will be used. Which one is undefined.<br>
>> > objc[10837]: Class AppleTypeCRetimerFirmwareAggregateRequestCreator is implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5f00) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1085e0548). One of the two will be used. Which one is undefined.<br>
>> > objc[10837]: Class AppleTypeCRetimerFirmwareRequestCreator is implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5f50) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1085e0598). One of the two will be used. Which one is undefined.<br>
>> > objc[10837]: Class ATCRTRestoreInfoFTABFile is implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5fa0) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1085e05e8). One of the two will be used. Which one is undefined.<br>
>> > objc[10837]: Class AppleTypeCRetimerFirmwareCopier is implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5ff0) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1085e0638). One of the two will be used. Which one is undefined.<br>
>> > objc[10837]: Class ATCRTRestoreInfoFTABSubfile is implemented in both /usr/lib/libauthinstall.dylib (0x1f6af6040) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1085e0688). One of the two will be used. Which one is undefined.<br>
>> > 2022-04-01 19:39:17.575 xcodebuild[10837:118106] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionSentinelHostApplications for extension Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in com.apple.dt.IDEWatchSupportCore<br>
>> > 2022-04-01 19:39:17.576 xcodebuild[10837:118106] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of plug-in com.apple.dt.IDEWatchSupportCore<br>
>> > <br>
>> > Is any of this a problem?<br>
>> <br>
>> I haven't heard of these messages before. You may need to report them to Apple. The files being mentioned are provided by Apple, not MacPorts.<br>
> <br>
>  "is implemented in both" -- The same symbol is present in two different libraries that are both referenced by the same program.  This represents a possible build mix-up and potential for runtime problems.  Apple decided several years ago to issue warnings for this, rather than simply accept the first found instance for the symbol.<br>
> <br>
> This is distilled from my on-line reading.  I do not have direct experience.  Many are calling this a bug.  To me it seems more like an increased level of caution.  Apple wants consistency in the use of framework libraries on any given computer.<br>
> <br>
> Speculation:  It may be possible to resolve this by carefully rebuilding certain Macports base components, maybe also certain ports.  If I had an offending system, I would first start by examining the library dependencies underneath “port diagnose” and any ports referenced.  otool -L recursively, and so on.<br>
<br>
To clarify, I've seen the "Class ... is implemented in both ... and .... One of the two will be used. Which one is undefined" message before generally, but I have not heard of these specific instances of this warning appearing with regard to MacPorts base before. As far as I know, MacPorts base does not use any of the functionality that the warnings are talking about, therefore I assume the warnings are coming from some Apple library that MacPorts is indirectly using, and that therefore the problem needs to be reported to Apple so that they can fix that Apple library.</blockquote><div><br></div><div> "coming from some Apple library that MacPorts is indirectly using" ... Agreed.  I still wonder whether somehow, base or some other executable that gets invoked during Artemio's particular "port diagnose", is built under Macports control, and therefore might be locally fixable.  I am unfamiliar with base internals, so I do not really know whether this is a reasonable theory.  I assume "port diagnose" is complicated under the hood, might fork and run other executables, and so on.  The intricacy of that bunch of messages suggests something along these lines.</div><div><br></div><div>That is why I suggested looking for dependency evidence in the executables.  That might narrow down the problem location, which would then be helpful either way, under Apple control, or Macports control.  I also wonder whether "port -v diagnose" might divulge more helpful information.</div><div><br></div><div>Perhaps if this is reported to Apple, as you say, they might immediately recognize the specific problem and advise us, saving further effort.</div></div></div>