build: pass -dead_strip_dylibs to ld on macOS #17663

This strips some unused dylibs from bitcoin-qt.

otool -L src/qt/bitcoin-qt
  /usr/lib/libSystem.B.dylib
- /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
  /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
  /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
  /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
  /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
  /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
  /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
-/System/Library/Frameworks/Security.framework/Versions/A/Security 
  /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 
  /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 
  /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 
-/System/Library/Frameworks/AGL.framework/Versions/A/AGL 
  /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
  /usr/lib/libc++.1.dylib 
  /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 
  /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText 
  /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
  /usr/lib/libobjc.A.dylib

AGL - ObjC wrapper for OpenGL. DiskArbitration - mount/unmount notifications and events. Security - low level security operations, authentication services.

From man ld:

Remove dylibs that are unreachable by the entry point or exported symbols. 
That is, suppresses the generation of load command commands for dylibs 
which supplied no symbols during the link. This option should not be 
used when linking against a dylib which is required at runtime for 
some indirect reason such as the dylib has an important initializer.

Any guess why those were included in the first place?

Concept ACK.

Concept ACK: less cruft is better

I think it's, in principle, nice to depend on fewer system libs but…

Remove dylibs that are unreachable by the entry point or exported symbols.

How risky is this option? Worded like this, it seems like quite an extensive analysis pass (checking the call tree all the way from the entry point?—does this take into account indirect/lazy dependencies through vtables, function pointers, threads, etc?).

E.g. is there a chance of false negatives? what will happen?

ACK bd44711e1bb2eee7646f2f8e2e8763d1c216bdb9. @laanwj I agree with the caution here, but I think this is a good idea. I believe Gnu ld/gold already work this way by default. I actually lost $1 to @fanquake on a bet about this at lunch yesterday, because I thought -dead_strip was already doing this.

Note that we're already using -dead_strip, which goes pretty far:

-dead_strip
            Remove functions and data that are unreachable by the entry point or exported symbols.

This just goes a step further and doesn't add the dylib entry in the binary, so we only need to worry about potential startup side-effects. And if those do exist, I think we'd like to flesh them out.

Related: Are there any parts of qt in depends that we can disable to prevent these from being added?

<!--a722867cd34abeea1fadc8d60700f111-->

Gitian builds

Related: Are there any parts of qt in depends that we can disable to prevent these from being added?

I'll look at this as a follow up.