Use llvm-strip with support for our cross-compilation targets
#23
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When stripping was introduced, it used the system `strip` binary from
GNU which isn't usually built to support cross-compilation. On my
system I am greeted with the following error when `strip` runs:
strip: Unable to recognise the format of the input file 'xxx/libevolve_android.so'
But obviously no-one checks process status codes -_-, so this command
"silently" continues without modifying the library. That should have
left us with a functional yet fat/unstripped library.
When this feature was developed the same error message (and unstripped
library) was likely seen, resulting in a search for how to make the
format recognizable and ultimately having `--target=elf64-little` with
`// I'm told this should always be valid for Android, so use this as the
target` above it. This is not a complete target and lacks the machine
and operating system, resulting in an invalid library that won't run on
Android. It was removed in hopes of getting a valid binary, but there
is supposedly still an issue with loading the "unstripped?" library
(besides it not actually being stripped).
Just like all other compiler tools and linkers in `xbuild` use `strip`
from LLVM which has cross-compilation support (we already relied on
that when the `.so` was first compiled and linked...). This infers the
right target from the file and automatically strips everything (i.e.
`--strip-all` is superfluous).
maxded
approved these changes
Jan 6, 2025
|
Locally, yes: The app also launches when "built+installed" via |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When stripping was introduced, it used the system
stripbinary from GNU which isn't usually built to support cross-compilation. On my system I am greeted with the following error whenstripruns:But obviously no-one checks process status codes -_-, so this command "silently" continues without modifying the library. That should have left us with a functional yet fat/unstripped library.
When this feature was developed the same error message (and unstripped library) was likely seen, resulting in a search for how to make the format recognizable and ultimately having
--target=elf64-littlewith// I'm told this should always be valid for Android, so use this as the targetabove it. This is not a complete target and lacks the machine and operating system, resulting in an invalid library that won't run on Android. It was removed in hopes of getting a valid binary, but there is supposedly still an issue with loading the "unstripped?" library (besides it not actually being stripped).Just like all other compiler tools and linkers in
xbuildusestripfrom LLVM which has cross-compilation support (we already relied on that when the.sowas first compiled and linked...). This infers the right target from the file and automatically strips everything (i.e.--strip-allis superfluous).