New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Android and related cross fixes #56197
Conversation
echo "-D__ANDROID_API__=${stdenv.targetPlatform.sdkVer}" >> $out/nix-support/cc-cflags | ||
echo "-D__ANDROID_API__=${stdenv.targetPlatform.sdkVer} " >> $out/nix-support/cc-cflags | ||
echo "-target ${stdenv.targetPlatform.config} " >> $out/nix-support/cc-cflags | ||
echo "--gcc-toolchain=${androidndk}/libexec/android-sdk/ndk-bundle/toolchains/${targetInfo.triple}-${targetInfo.gccVer}/prebuilt/${hostInfo.double} " >> $out/nix-support/cc-cflags |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is stuff for LLVM?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah androidndk 18+ is using clang + ld.bfd. Apparently they are planning to move lld eventually. Maybe this would be a good chance to get rid of their toolchain completely and just use gccCrossStageStatic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the nixpkgs side, gcc would be probably easier to support, since at the moment the defacto standard is: linux == gcc
. Does the current cross-compiling port uses bionic or musl on android?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It uses bionic which would still make since. Right now we also use the NDKs c compiler which isn’t really necessary although it does save us building gcc for android. Since we have androidndk in hydra now i think it becomes easier to do thay.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It uses bionic which would still make since. Right now we also use the NDKs c compiler which isn’t really necessary although it does save us building gcc for android. Since we have androidndk in hydra now i think it becomes easier to do that.
@@ -13,6 +13,7 @@ | |||
, extraPackages ? [], extraBuildCommands ? "" | |||
, isGNU ? false, isClang ? cc.isClang or false, gnugrep ? null | |||
, buildPackages ? {} | |||
, passthru ? {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This actually isn't needed anymore, although it might still be nice to get androidndk out of stdenv.
pkgs/top-level/static.nix
Outdated
@@ -151,4 +148,7 @@ in { | |||
}; | |||
}; | |||
|
|||
unbound = super.unbound.override { | |||
static = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe enableStatic
for consistency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, there does not seem to be a standard on naming things like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it’s inconsistent… enableStatic usually implies that you should build static libraries. In this case the static is needed for building the binaries statically. That’s the distinction i’ve arrived at between the two.
Now that i think about it, these aren’t really needed for this pr so i could leave them out.
Could we do that for all gcc toolchains then? I think making it consistent is best for things like this. |
Not sure if this is a regression, but on this branch I cannot build
(via |
|
These are no longer used. We build all targets now.
LLVM should be target independent because it will work with all machine types. This is different from GCC where it needs to know what target to build ahead of time.
(cherry picked from commit 08f5b419b9efc77db044f8c1d725632552617966)
This should be picking up the OpenGL ES headers provided by the NDK. More testing is needed.
d1d054b
to
d665b8c
Compare
In the hope of not just producing noise: It seems that even with these changes, SDL (the C-library, independent of Haskell) does not cross-build, unless I am invoking it in a wrong way:
|
Motivation for this change
Gets more android things to build correctly.