You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adding -Wl,--exclude-libs,libgcc_real.a to LOCAL_LDFLAGS fixes this, so this was caused by changing libgcc.a to be a version script (r19, if memory serves).
The text was updated successfully, but these errors were encountered:
This isn't as problematic as I'd feared. The ABI that this causes issues on (arm32) was unaffected for the same reason that it's the one that usually has problems: it uses a different unwinder. Since libunwind was always being linked first and --exclude-libs was still working fine with libunwind, the unwind symbols remained hidden in 32-bit arm outputs.
When we switched to using a linker script for libgcc in r19 we broke
`-Wl,--exclude-libs,libgcc.a`, because `--exclude-libs` has no effect
on the contents of linker scripts. As such, libgcc was not being
hidden as expected.
The good news is that on the one platform this causes the most trouble
(Arm32, since it uses the LLVM unwinder for exception handling rather
than libgcc) this didn't cause any issues. Since libunwind was linked
first (and the `--exclude-libs` worked there, since the actual library
was named), the libgcc unwind symbols did not end up in the output at
all.
So while this has not caused any issues, it is still a good idea for
us to link libgcc hidden to guard against any future unwind ABI
breaks.
Test: Added a test that checks ndk-build output with readelf
Bug: android/ndk#1092
Change-Id: I5c8203afd29f0b7b272a51aadfc1a5ca6cbd33e4
disigma
pushed a commit
to wimal-build/ndk
that referenced
this issue
Oct 5, 2019
When we switched to using a linker script for libgcc in r19 we broke
`-Wl,--exclude-libs,libgcc.a`, because `--exclude-libs` has no effect
on the contents of linker scripts. As such, libgcc was not being
hidden as expected.
The good news is that on the one platform this causes the most trouble
(Arm32, since it uses the LLVM unwinder for exception handling rather
than libgcc) this didn't cause any issues. Since libunwind was linked
first (and the `--exclude-libs` worked there, since the actual library
was named), the libgcc unwind symbols did not end up in the output at
all.
So while this has not caused any issues, it is still a good idea for
us to link libgcc hidden to guard against any future unwind ABI
breaks.
Test: Added a test that checks ndk-build output with readelf
Bug: android/ndk#1092
Change-Id: I5c8203afd29f0b7b272a51aadfc1a5ca6cbd33e4
(cherry picked from commit b1d17d6)
APP_STL := c++_static
$ ndk-build -C foo APP_ABI=arm64-v8a -B V=1 (build output shows -Wl,--exclude-libs,libgcc.a) $ readelf -sW libs/arm64-v8a/libfoo.so| grep _Unwind (shows global visibility unwind symbols)
Adding
-Wl,--exclude-libs,libgcc_real.a
toLOCAL_LDFLAGS
fixes this, so this was caused by changing libgcc.a to be a version script (r19, if memory serves).The text was updated successfully, but these errors were encountered: