Closed eli-schwartz closed 2 months ago
It was added in commit be1a63d3986257b53c7482e5deb3837f140382ee but that commit never made use of it.
@sgn Could you explain why libandroidfw was added in that commit?
It was added in commit be1a63d but that commit never made use of it.
@sgn Could you explain why libandroidfw was added in that commit?
TBH, I don't remember. I think there was a build failure at that time and it require libandroidfw
.
Please keep in mind that I started the development with 30.0.4 instead of 30.0.5. I guess it was required for 30.0.4 and dropped when it moved to 30.0.5.
As libandroidfw
is not used by the android tools then it should be dropped from the codebase.
I think there was a build failure at that time and it require
libandroidfw
.
I even checked the history and could not tell any time when the cmake target defined by libandroidfw was used by another cmake target, so it surprises me that it could fix a build failure if it was still never used.
There was another native submodule which was added in e8f73d65571801f495f89529c07f5671a7612a18 commit is not used anymore.
After all these removals, the source tarball size reduces to 16.2 MB from 20.6 MB.
I tried to build with the following *FLAGS to optimize the build:
-flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
The -Werror=* flags are important to detect cases where the compiler can try to optimize based on assuming UB cannot happen, and miscompile code that has UB in it. strict-aliasing issues are always bad but LTO can make them even worse.
I got this error:
Attached is a full build log. There are other errors too. build.log
There's a tracking issue downstream at https://bugs.gentoo.org/858311
...
Okay, so now you may ask, why am I reporting an error in Android source code to this wrapper project? Good question.
The answer is that I have looked everywhere in the codebase and I cannot tell where the libandroidfw target is ever used. It was added in commit be1a63d3986257b53c7482e5deb3837f140382ee but that commit never made use of it. Helpfully, the commit message is highly detailed and explains the whys and wherefores of why it was added:
It is never mentioned in build.ninja other than as part of the default "all" target. Using a sed to delete:
results in android-tools building and installing correctly (without LTO, anyway). So my assumption is that by dropping this unused dependency, google's source code bugs become "not our problem". Also ~25 fewer build edges means faster builds -- and 16mb less unpacked source code size (did not measure effects on compressed tarballs).