AMSupportURLConnectionDelegate and AMSSupportURLSession both multiply defined

try a simple, documented step first

In Terminal:

sudo xcode-select -r

explanation

The command resets xcode to the default path (see documentation excerpt below). This command

• resolved the issue for me and
• avoided the risk of introducing random, undocumented ideas from strangers.

These advantages make it worth trying first, especially since documented approaches typically won't interfere with future version upgrades. Experimental workarounds may need to be undone first.

source: https://stackoverflow.com/questions/65089767/class-amsupporturlconnectiondelegate-is-implemented-in-both

It seems more than a little peculiar that the error system seems to depend on having an on-disk version of the dynamic library to report on if it is expected that on-disk copies are unusual -- and that is exactly what is in the error message here.

I don't know what to tell you. You just have to get used to the system and learn to be able to tell which error messages are significant and which can be ignored. If there was any golden rule, I would certainly tell you, but I don't know of one. I'm just familiar with this error message because I've seen it for so many years. I have never seen it even once in my own code. It is always Apple's code, so I ignore it. Apple's addiction to pointless logging does impact my own code. Apple regularly changes the system so it that apps spit out massive amounts of pointless log messages. A couple of years ago it would log every single mouse movement. Right now, since the 12.1 update, all my code is spitting out messages like this:

2022-01-12 22:41:39.509606-0500 MapStyler[25657:1589388] [] [0x135892400] CVDisplayLinkSetPaused [TRUE]

2022-01-12 22:41:39.509718-0500 MapStyler[25657:1589388] [] [0x135892400] CVDisplayLinkSetPaused [FALSE]

2022-01-12 22:41:39.518125-0500 MapStyler[25657:1589388] [] [0x135892400] CVDisplayLinkSetPaused [TRUE]

2022-01-12 22:41:39.543422-0500 MapStyler[25657:1589388] [] [0x135892400] CVDisplayLinkSetPaused [FALSE]

Repeated tens of thousands of times. This is what the filter control in the Xcode console output is useful for. Make sure to add your own common and unique prefix so you can easily filter your NSLog() or printf() debugging statements.

The MacOSX operating system is certainly quite complicated -- we are in absolute agreement there. It is exactly the fragility that comes with complexity that I am attempting to manage.

That's not your job to manage.

Do you know the name of this library definition cache? Or the tools to manage it?

If you are still interested at this point, that quote about should give you enough to go on. This is the operating system. You don't manage it. When Apple puts it all into a read-only, cryptographically-sealed AFPS snapshot, that is their way of telling you that you aren't going to be managing it.

It seems that what is required to solve this problem is simply a cache flush, however without knowing the name of the technology managing the cache, flushing it is quite difficult.

Just ignore it. I'm not making a joke here. You seem fixated on one of the most minor and long-running of Apple's log messages. Where does this end? Clearly, you have absolutely no idea of how bad it really is. I suggest you stop looking. Here in these forums, I've seen more than one person literally lose touch with reality from looking at the never-ending stream of scary log messages in the Console app.

You seem to be and advanced user (running opendiff) and posting in the developer forums, so I'm indulging a bit. I've even had to split up my reply due to the 5000 character limit. This is just the way it is now.

I am getting this message when running "xcodebuild" after upgrading XCode from 13.1 to 13.2 or 13.2.1. Re-installing XCode 13.1 resolves the issue for me. I do not have Homebrew or MacPorts installed. The "xcodebuild" command does execute correctly after the error. But it causes a CI/CD build to fail, due to the error emitted.

PrOstack wrote:

try a simple, documented step first

In Terminal:

sudo xcode-select -r

explanation

The command resets xcode to the default path (see documentation•  excerpt below). This command

resolved the issue for me and

• avoided the risk of introducing random, undocumented ideas from strangers.

These advantages make it worth trying first, especially since documented approaches typically won't interfere with future version upgrades. Experimental workarounds may need to be undone first.

source: https://stackoverflow.com/questions/65089767/class-amsupporturlconnectiondelegate-is-implemented-in-both

But you missed this important validation on that post:

it works for me... although, welcome to the new era of "software engineering". Google for the error, type in something without really understanding it. "Boom, Bam!" and it is done... all without knowing what really is happening. My coworkers do "programming" this way too, npm install XYZ and "Boom, Bam!" it is done – 

nonopolarity

I couldn't agree more. I wonder how many people are going to try to install Flutter to try to fix it. 😄

Hi - I had this same error on M1. I found the Terminal app in the applications folder -> click 'get info' -> and check 'Open using Rosetta'. This fixed the issue for me.

Yes, thanks andrecrimb_w. Simply installing Rosetta from a Terminal shell:

systemupdate --install-rosetta

resolved the issue for me as well.

Thank you for your answer andrecrimb_w .

This worked for me. I had same issue with these two "log noise", but resolve by duplicate the terminal and checked "Open using Rosetta" for terminal, solution as you provided in the last link.

andrewhw00 wrote:

This is a common source of fragility when dynamic libraries are used, and typically one wants to be able to rigorously ensure that the correct version of the symbol is being presented.

Apple has the operating system locked-down pretty good. You don't have to worry about any fragility. It's all the same code.

This is why the error message is being reported in the first place, in order to make users aware of this potential fragility.

These messages are for 3rd party developers, not users. The fact that Apple normally ignores, in its own code, all of the things that it preaches about and logs about 3rd party code is a different issue.

In the current situation, it appears that the two conflicting implementations are similar enough that the program(s) "work" but having this situation being reported by a vendor supplied system tool makes me think that it is quite likely that other tools using the system libraries are having the same issue, but as they are not being invoked from the command line that the error state is not being seen.

Oh, absolutely.

Whether this is "common" I cannot comment on, but certainly this is not "normal" in systems design.

This is Apple, not systems design. This particular message has been a regular occurrence in Apple system software for years. I don't even remember when I first started seeing it. Maybe a decade ago?

Dynamic libraries only exist in the operating system cache. They don't normally have a stand-alone dylib. But the macOS operating system is easily the most complex operating system ever made, so there are lots of things that fall through the cracks and show up in places like this.

This first sentence in this statement is certainly not true. There are dozens of dynamic libraries in the filesystem in MacOSX as well as every other operating environment commonly in use.

I was specifically referring to those system dylibs that you couldn't find. There are hundreds, if not thousands of dynamic libraries in the operating system. Many of them do exist as stand-alone files inside various system frameworks. But you were talking about files in /usr/lib, which is more of a special area these days.

Until I saw this error, I was unaware that it was possible in MacOSX that a library could exist without "a stand-alone dylib" as you put it. Are there docs on this cache?

See the Big Sur release notes. Here is the section you want:

New in macOS Big Sur 11.0.1, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to dlopen() the path, which will correctly check for the library in the cache. (62986286)

I was having this issue with the git command, and I somehow got it to resolve. Honestly, doesn't make sense to me why, but here is what I did on the command-line....

ran the `xcode-select -r` command. this didn't seem to actually resolve anything

navigated into both the folder locations being output by the warning. I went in directory by directory. Eventually the file locations showed not to exist (with the `ls -a` command). Maybe this resolved in the cache that these were non-existent?

ran the `xcode-select -p` command. all this does is print the path...

Then literally ran `git --version` and the warning output has ceased. Makes no sense to me. I'm on M1 MacBook Pro. Don't really know why but those warnings were so annoying, so I thought I'd share this even though I don't understand...

andrewhw00 wrote:

When running various tools, such as "opendiff" I receive the following error:

objc[6599]: Class AMSupportURLConnectionDelegate is implemented in both /usr/lib/libauthinstall.dylib (0x1e30deb90) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x108f7c2c8). One of the two will be used. Which one is undefined.

objc[6599]: Class AMSupportURLSession is implemented in both /usr/lib/libauthinstall.dylib (0x1e30debe0) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x108f7c318). One of the two will be used. Which one is undefined.

This is normal and very common.

This appears to be related to the problems reported here: https://discussions.apple.com/thread/252824300

(Apple won't let me update that thread and is forcing me to make a new one -- what's up with that, Apple?)

That thread is six months old. If there is no activity, threads are automatically locked.

This is probably caused by something installing a conflicting library -- in the above thread, various people are using homebrew, I am using MacPorts -- but the issue is the same.

No. It's normal.

What makes this VERY peculiar is that there is actually no file on my system with the name /usr/lib/libauthinstall.dylib so I cannot determine where this conflict is coming from.

Dynamic libraries only exist in the operating system cache. They don't normally have a stand-alone dylib. But the macOS operating system is easily the most complex operating system ever made, so there are lots of things that fall through the cracks and show up in places like this.

Contact the app support folks for OpenDiff, then contact Apple. Product Feedback - Apple

If this is log chatter and not messages overtly and directly shown to app users via stdio or stderr or such, it is—as mentioned above—longstanding misbehavior from within macOS.

Ah, okay. So you got an opendiff and FileMerge answer directly from Apple… and you didn‘t like that answer.

On a local test Mac running Big Sur 11.6.2 and Xcode 13.2.1 with bash and brew, no stderr/stdout messages with opendiff and FileMerge.

As potential alternatives to wading into PATH and otherwise testing and troubleshooting this on your local system (which is where this is all headed), I’ve been using Kaleidoscope (not cheap), and there are other options:

… https://eclecticlight.co/2018/04/14/comparing-files-filemerge-opendiff-and-bbedit/

I have not seen these “ambiguous API” messages outside of log chatter. Where it’s… expected.

This isn’t the “ask your questions on the developers forums” that were the intended destination.

They’re here: https://developer.apple.com/forums/

And it seems you’ve been presented with feedback from Apple Support (and getting redirected), and also now feedback from Apple Developer Support. Both have declined to troubleshoot the installation here, and understandably.

Find somebody to duplicate this on Monterey.

Or wipe the install, reload Xcode and the command line tools, and try to duplicate the issue there. With a clean install of macOS Monterey and the development tools, Apple might be more interested.