Not so much a bug as an enormous improvement in library size with an unknown reason. These file sizes are for the arm64 ABI of liboboe.so:
version 1.5: 2.23Mi
version 1.6: 426Ki
That's a 5.75X reduction, and afaik nothing changed on our end.
The instrumented tests all pass, so either we don't have test coverage for an area which will now fail, something changed in our build config, or something changed in the NDK.
And the lack of debug info corresponds to our build script, specifically the following cmake argument:
-DCMAKE_BUILD_TYPE=Release
This will cause all debug info to be stripped from the resulting libraries, which explains the smaller file size.
This build script hasn't changed recently though so it doesn't explain why earlier releases do contain debug information.
This is likely due to using an updated version of cmake which actually respects the directive, or perhaps the NDK ${ANDROID_NDK}/build/cmake/android.toolchain.cmake file changed and no longer overrides Release with RelWithDebInfo.
Either way, there's nothing wrong with our libraries (aside from the lack of debug information).
2 conclusions:
#1 Oboe should be compiled with RelWithDebInfo. This will include the debug information, which will increase file size, however, Android Gradle Plugin will strip the debug info when the libraries are packaged into an APK so there is no bloat for the end users #2 We should really use a cloud build for creating our libraries, that way we can have a controlled environment and avoid issues like this in future. Issue filed.
Activity
dturner commented on Jun 10, 2021
Running Bloaty diff (which incidentally has the best library name ever) shows the following:
$ ./bloaty ../oboe-aar-diff/liboboe-1.6-arm64.so -- ../oboe-aar-diff/liboboe-1.5-arm64.so FILE SIZE VM SIZE -------------- -------------- [NEW] +1.81Ki [NEW] +1.75Ki .got.plt +28% +1.55Ki +29% +1.55Ki .hash +1.5% +1.36Ki +1.5% +1.36Ki .text +2.7% +1.02Ki +2.7% +1.02Ki .dynstr +2.3% +1.01Ki [ = ] 0 .strtab +3.9% +912 +3.9% +912 .rela.dyn +3.0% +624 +3.0% +624 .dynsym [NEW] +568 [NEW] +568 [LOAD #1 [RX]] +5.1% +552 +5.1% +552 .rodata +4.9% +376 +4.9% +376 .data.rel.ro +0.1% +62 +0.3% +148 [12 Others] [DEL] -512 [DEL] -512 [LOAD #0 [RX]] [DEL] -1.38Ki [ = ] 0 [Unmapped] -68.6% -1.67Ki -70.4% -1.67Ki .got -13.8% -7.99Ki [ = ] 0 .symtab -95.9% -66.6Ki [ = ] 0 .debug_abbrev -96.0% -74.4Ki [ = ] 0 .debug_ranges -97.8% -230Ki [ = ] 0 .debug_line -97.2% -300Ki [ = ] 0 .debug_str -90.5% -319Ki [ = ] 0 .debug_loc -97.0% -860Ki [ = ] 0 .debug_info -81.3% -1.81Mi +2.7% +6.62Ki TOTALClearly there's a smoking gun with the debug information.
dturner commented on Jun 10, 2021
And the lack of debug info corresponds to our build script, specifically the following cmake argument:
This will cause all debug info to be stripped from the resulting libraries, which explains the smaller file size.
This build script hasn't changed recently though so it doesn't explain why earlier releases do contain debug information.
This is likely due to using an updated version of cmake which actually respects the directive, or perhaps the NDK ${ANDROID_NDK}/build/cmake/android.toolchain.cmake file changed and no longer overrides Release with RelWithDebInfo.
Either way, there's nothing wrong with our libraries (aside from the lack of debug information).
2 conclusions:
#1 Oboe should be compiled with RelWithDebInfo. This will include the debug information, which will increase file size, however, Android Gradle Plugin will strip the debug info when the libraries are packaged into an APK so there is no bloat for the end users
#2 We should really use a cloud build for creating our libraries, that way we can have a controlled environment and avoid issues like this in future. Issue filed.
Build libs with debug info. Fixes google#1301.