I posted this originally because I was curious, but a client really wanted to know today so I had to dig. Turns out that there is a CLI command size
that can help:
$ size -arch arm64 myLib.a
__TEXT __DATA __OBJC others dec hex
18436 7156 0 42642 68234 10a8a myLib.a(a.o)
1659 528 0 7209 9396 24b4 myLib.a(b.o)
...
Wow - that "others" looks really huge. Wonder what's in it? Hmmm, try the -m
option, and you get a really long output of each file in the library, and the size of each segment in the library.
When I use the -m
option on my library, I get a slew of segments with prefix names of "__debug":
myLib.a(a.o):
Segment : 47665
Section (__TEXT, __text): 9832
Section (__DWARF, __debug_info): 9625
Section (__DWARF, __debug_abbrev): 867
Section (__DWARF, __debug_aranges): 64
Section (__DWARF, __debug_macinfo): 0
Section (__DWARF, __debug_line): 2142
Section (__DWARF, __debug_loc): 7237
Section (__DWARF, __debug_str): 4750
Section (__DWARF, __debug_ranges): 240
Section (__DATA, __data): 0
Section (__TEXT, __literal8): 16
...
Section (__DWARF, __apple_names): 2364
Section (__DWARF, __apple_objc): 196
Section (__DWARF, __apple_namespac): 36
Section (__DWARF, __apple_types): 1924
total 47652
total 47665
To get a value of what this code will consume when stripped in the final app, I need to get the full segment size and subtract out the size of all the "__debug" prefixed segments.
# Get the full size of all object files in the library
$ size -m -arch arm64 *.a | grep '^.total' | sed -n -e 's/^.total //p' | awk '{s+=$1} END {print s}'
381423
$
# Get the size of the debugging sections:
$ size -m -arch arm64 *.a | grep __debug_ | sed -n -e 's/^.*: //p' | awk '{s+=$1} END {print s}'
212702
$
The total is thus 381423 - 212702 = 168721 # more or less
PS: awk
script from This SO post