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
The fake GCC wrappers we have that point to Clang can find the linker now, but still won't find the CRT objects since Clang will only search the sysroot for them, and can't do that properly without a versioned target. GCC would search -L directories.
The goal of these was to keep old build scripts working without changes to the command line. Given that a future release (r21? gradle changes haven't landed yet so maybe further out) will remove the $NDK/platforms directory and whatnot to save space, which will break all these use cases anyway. Given that, and that it would probably take a Clang change that we don't actually want to get the wrappers working, we should probably just remove them.
Alternatively, we could have the GCC wrappers select an Android release by default. The user's -L would override so it would get the right libraries, but it would get the wrong CRT objects. I don't think we should do this, but I don't see other ways of getting these working short of undesirable Clang changes (which would have a long enough lead time that they're probably pointless anyway).
The text was updated successfully, but these errors were encountered:
These don't work and the intended use case (keeping old build scripts
working) is going to break when we purge the old install locations
anyway.
Test: ./checkbuild.py
Bug: android/ndk#862
Change-Id: I69107451b8c719863f3029b2361bfc90f00ed89c
(cherry picked from commit b6e4b3d)
disigma
pushed a commit
to wimal-build/ndk
that referenced
this issue
Feb 22, 2019
* Update ndk from branch 'ndk-release-r19'
to 5e5d0a21b6c501a945a34dca8565ff1fca16f7a0
- Merge "Remove the GCC wrappers." into ndk-release-r19
- Remove the GCC wrappers.
These don't work and the intended use case (keeping old build scripts
working) is going to break when we purge the old install locations
anyway.
Test: ./checkbuild.py
Bug: android/ndk#862
Change-Id: I69107451b8c719863f3029b2361bfc90f00ed89c
(cherry picked from commit b6e4b3d8adfd827eb797e17ecbf04747cb492a56)
mehulagg
pushed a commit
to mehulagg/superproject
that referenced
this issue
Dec 21, 2019
From my comments here: https://stackoverflow.com/a/53535894/632035
The fake GCC wrappers we have that point to Clang can find the linker now, but still won't find the CRT objects since Clang will only search the sysroot for them, and can't do that properly without a versioned target. GCC would search
-L
directories.The goal of these was to keep old build scripts working without changes to the command line. Given that a future release (r21? gradle changes haven't landed yet so maybe further out) will remove the
$NDK/platforms
directory and whatnot to save space, which will break all these use cases anyway. Given that, and that it would probably take a Clang change that we don't actually want to get the wrappers working, we should probably just remove them.Alternatively, we could have the GCC wrappers select an Android release by default. The user's
-L
would override so it would get the right libraries, but it would get the wrong CRT objects. I don't think we should do this, but I don't see other ways of getting these working short of undesirable Clang changes (which would have a long enough lead time that they're probably pointless anyway).The text was updated successfully, but these errors were encountered: