-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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 targets [WIP] #3572
Android targets [WIP] #3572
Conversation
I'm just going to now call you the "porting wizard". :) |
@@ -23,5 +23,7 @@ lib LibPCRE | |||
$pcre_free : Free | |||
end | |||
|
|||
LibPCRE.pcre_malloc = ->GC.malloc(LibC::SizeT) | |||
LibPCRE.pcre_free = ->GC.free(Void*) | |||
{% unless flag?(:without_pcre) %} |
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.
These two lines are the ones responsible for always linking apps against PCRE into the built binary, whatever if the application uses PCRE or not. It may be interesting to have a special macro for lib
that would be called whenever that lib
is actually used @asterite
I disable it because I don't need it (yet) and building libraries for the NDK is a pain, so I settled for iconv
, gc
and libevent
for the time being.
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.
The macro idea is good, we sometimes need to run code but only if the lib is actually used. The "problem" is that the compiler finds out if a lib is used when a lib fun is invoked, and at that point the macro would need to be expanded and typed... and then the codegen should put that code right where the macro definition exists. I'll try to think how to implement this, maybe it's not that hard. I'm thinking about something like macro initialize
, but another (better) name should be good too.
src/signal.cr
Outdated
@@ -126,4 +126,6 @@ fun __crystal_sigfault_handler(sig : LibC::Int, addr : Void*) | |||
LibC._exit sig | |||
end | |||
|
|||
LibExt.setup_sigfault_handler | |||
{% unless flag?(:without_sigfault_handler) %} |
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.
Same here: I chilled to build libcrystal.a
thought it should be relatively easy.
src/main.cr
Outdated
redefine_main do |main| | ||
{{main}} | ||
end | ||
{% unless flag?(:android) || flag?(:without_main) %} |
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.
I also added the without_main flag because it may be useful in some contexts. I.e., building libraries.
@kirbyfan64 Julien Portalier |
Well that explains it all :O |
f3d3e45
to
6f6a404
Compare
I think these shards are relevant here: |
This appears to have stalled out. What is needed to get this QA'd and merged? There is a lot of value here. It also seems to me that this would also help in the effort to get crystal on iOS as well. |
|
iOS is quite different, but basically that doesn't change much than adding a target to Crystal. Except that iOS requires special fixes for the ARM ABI. |
Use a single name (`errno`) instead of using the target specific naming (`__error`, `__errno`, `__errno_location`). With support for Android NDK.
6f6a404
to
803eaf8
Compare
@ysbaddaden Can we close this, but maybe keep it as a branch somewhere until it can be merged? Just so that we don't keep stalled PRs (I'd like to do a cleanup). |
Closing for the time being. Regenerating C bindings is boring, and some additions such as VaList made it harder :( |
Is this still in progress or is it abandoned? I see that the incoming fork has commits as recent as March 2019 (less than three months ago). |
Hello, has there been any progress here? |
Nobody is working in android precisely. @jhass has done some progress to add arm64 CI to avoid going backwards in the progress to that. Other than that, no. |
Thanks for the update. Is there anything we can do to accelerate the process? |
Sure, you can contribute :) pull requests welcome! |
I'm kinda new to LLVM and stuff, but doesn't it's bitcode get compiled on Android too? I mean, why can't bitcode produced by the Crystal compiler run on Android? |
Producing bytecode for the usual Android architectures is not the problem, the task is ABI compatibility and porting the standard library. |
Damn right The hardest part of porting the stdlib will probably be the LLVM module |
What LLVM module? |
The LLVM module available at the top-level |
That should just work when the ABI is implemented properly. |
Basic support for building Crystal apps targeting Android.
arm-unknown-linux-androideabi
Glue for
ANativeActivity
and other Android NDK API (ANativeWindow
, event listeners/dispatchers, JNI, ...) to build Android aware applications will eventually come as an external shard.