search

JeromeDeBretagne / erlanglauncher

Example of Android/Erlang communication with Jinterface; fork from knewter's code
12 stars 2 forks source link

Compiling crypto and ssl #4

Closed D4no0 closed 3 years ago

D4no0 commented 3 years ago

It seems that currently the build skips building ssl, so it also skips crypto library. Phoenix relies on this library, so you cannot start a phoenix application without having crypto. Is it a current limitation of the system that crypto is not compiled or it can be enabled?

JeromeDeBretagne commented 3 years ago

The instructions to build Erlang for Android currently pass the --without-ssl parameter : https://github.com/erlang/otp/blob/master/HOWTO/INSTALL-ANDROID.md

Someone should investigate the dependencies to see whether it may already work as-is when simply removing this parameter or if the instructions would need to be adjusted when cross-compiling for Android with SSL.

JeromeDeBretagne commented 3 years ago

Hi @D4no0,

Thanks to the discussion you started on the Erlang bug tracker in ERL-1408, I've been able to build Erlang for Android with OpenSSL 1.1.1i linked statically. The trick was indeed to create a lib directory after the OpenSSL build, and to create in it a libcrypto.a symlink pointing to the libcrypto.a library. Let me know if you want some support to create a pull request to improve the documentation about how to build Erlang for Android with OpenSSL.

As suggested, I've added the crypto and ssl applications in this sample project in commit d204472 and I've tested that crypto is working properly in both 32-bit and 64-bit cases. I hope you are progressing with your evaluation of Phoenix.

For info, I've also started another repository to publish the full Erlang releases for Android at https://github.com/JeromeDeBretagne/erlang-otp-releases-for-android, it contains the full list of Erlang/OTP applications (with the exception of wx).

Cheers, Jérôme

D4no0 commented 3 years ago

Yeah I've managed to start a phoenix server and it works out of the box! (almost). The problem with elixir releases are the same as the ones with erlang, the launch script uses relative path, witch will never work when files are symlinked from .so files. I will open an issue in elixir repository to propose introduction of environment variables as a workaround for this.

Also I will try to change the Makefile.in for crypto to throw error when libcrypto.a is not found when argument --disable-dynamic-ssl is passed, since currently the default behavior is to change to dynamic linking which makes no sense.

After this, the next step is to make a deployment script that will handle the possibility to deploy the application, currently the one in this repository works, however it needs to be improved. Also I know for sure that technologies like xamarin had (not sure if this is possible currently) shared runtime for development, meaning that they copied once the runtime in a shared folder (sdcard/tmp) and deployed only the compiled code, this is useful, however it is not clear how much of an improvement is that and if it worth investing time into.

The biggest problem currently is the native libraries used by interfaces like nif and port. The problem is that user also defines Makefiles, meaning that you should pass all the compiler flags and type of output, witch is not ideal, since you need to change makefiles for all existent projects using native code that doesn't handle cross-compiling. It seems that platforms like nerves elixir are using custom Makefiles . In general the perfect solution would be to generate Makefiles automatically based on some config?

JeromeDeBretagne commented 3 years ago

I don't know much about Elixir releases on my side, good luck with this project. Feel free to loop me in the discussion once you've created the issue in its repository, especially if there are some questions about the Android specificities.

I have never used Xamarin so I can't take inspiration from their approach, about how to propose a shared runtime. With this repository, you should be able to drop an Erlang application release quite flexibly already, as the runtime is already working and beam files don't need to be executable (so they shouldn't have any restrictions for their location on the filesystem).

Projects using native code are trickier indeed, especially if they don't handle cross-compiling nicely, that's for sure.