search

bazelbuild / bazel

a fast, scalable, multi-language and extensible build system
https://bazel.build
Apache License 2.0
23.15k stars 4.05k forks source link

Large binary size when building optimized Android NDK binaries #7150

Open feliwir opened 5 years ago

feliwir commented 5 years ago

Description of the problem / feature request:

I am building an android app with native code, for which i use cc_library etc. When building with default bazel build //app/... the size of the native .so file is about 30MB. To reduce the binary size i passed -c opt to strip debug symbols and optimize the build, but the native library ended up being 271MB (yes, just the .so file). I have no idea how it got that large, because it was just 6MB when i've built the same source with android studio & cmake before. When building with -cxxopts=-O2 --strip always and without -c opt i could atleast get down to 18MB size.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Not sure.

What operating system are you running Bazel on?

Ubuntu 18.10

What's the output of bazel info release?

INFO: Invocation ID: 12806307-0534-40cc-a3c7-b0f09a2975c7 release 0.21.0

Have you found anything relevant by searching the web?

No

Any other information, logs, or outputs that you want to share?

Since this is a propietary project i can't share any more information. Since i asked in Slack before i know that others have encountered similar problems.

jin commented 5 years ago

@hlopko are there any known issues around -c opt in the context of this issue?

matthewxperiel commented 5 years ago

We also see a similar size issue when build with -c opt.

hlopko commented 5 years ago

Can you try the build with --nolegacy_whole_archive?

matthewxperiel commented 5 years ago

Building with --nolegacy_whole_archive did not reduce the size of the binary when building with -c opt

hlopko commented 5 years ago

Can you run your build with --subcommands and see what gets pulled into the result? I'm afraid we'll need a bit more debugging/diffing on your side to tell us what is it that we do wrong..

jin commented 5 years ago

Marking as P2, we'll re-look at the default NDK compilation/linking flags while overhauling the current CROSSTOOL approach to use Starlark/Toolchains.

github-actions[bot] commented 1 year ago

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 2+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

feliwir commented 1 year ago

I think this is still open?