Why can it make sense to link a library against itself? - macos

Question

Checking the first two lines of the output of otool -L /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO shows that the library is apparently linked against itself. Is there a reason for that? Why does that even make sense?
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO:
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 600.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0)
/System/Library/PrivateFrameworks/AppleVPA.framework/Versions/A/AppleVPA (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1252.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1255.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 728.4.0)
/System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)

Answer 1

The first line of the output from otool -L is just the path of the file it's operating on, as passed on the command line.
The second line (the first indented one) is not a dependency. It's showing the install name of the library. In other words, it's showing the value of the LC_ID_DYLIB load command, not any of the LC_LOAD[_WEAK]_DYLIB commands.
From the otool man page (which isn't in Apple's online reference library for some reason):
-L Display the names and version numbers of the shared libraries
that the object file uses, as well as the shared library ID if
the file is a shared library.
Note: "as well as the shared library ID if the file is a shared library".