port diagnose output on M1 MacBook Pro

Tue Apr 5 00:32:15 UTC 2022

On Mon, Apr 4, 2022 at 5:26 PM Ryan Schmidt <ryandesign at macports.org> wrote:

> On Apr 4, 2022, at 14:25, Dave Allured - NOAA Affiliate wrote:
> > On Sun, Apr 3, 2022 at 4:23 PM Ryan Schmidt wrote:
> >> On Apr 1, 2022, at 13:09, Artemio González López wrote:
> >>
> >> > 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:
> >> >
> >> > 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.
> >> > 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.
> >> > 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.
> >> > 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.
> >> > 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.
> >> > 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.
> >> > 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.
> >> > 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.
> >> > 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.
> >> > 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.
> >> > 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.
> >> > 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.
> >> > 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
> >> > 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
> >> >
> >> > Is any of this a problem?
> >>
> >> 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.
> >
> >  "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.
> >
> > 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.
> >
> > 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.
>
> 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.

 "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.

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.

Perhaps if this is reported to Apple, as you say, they might immediately
recognize the specific problem and advise us, saving further effort.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20220404/26d3da20/attachment.htm>