-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Cross compilation for iOs, Android etc #6266
Comments
Comment author: @gasche I know nothing at all about cross-compilation, but I think that cross-compilation to android is already possible today, as explained by Jonathan Protzenko in the following blog post. I've also heard about iOS applications implemented in OCaml, see Psellos for example. |
Comment author: strobegen Yes it all possible now, I also know examples of few games written on Ocaml in iOs App Store (I guess, I was read some time ago article about small team which shipped few game titles to AppStore (not psellos)) but this functionally doesn't included to default compiler, currently only short way to build this kinds of apps for iOs is OCamlXARM (http://psellos.com/ocaml/compile-to-iphone.html), I'm not sure but I guess that OCamlXARM contain few patches to original Ocaml distribution related to ARM assembler (& crosscompiling) parts. Therefore my opinion that it will be very useful for Ocaml community if this functionally will be available in default distribution and officially supported: |
Comment author: @whitequark I have started working on proper cross-compilation to Android, and shortly after that I will probably switch to iOS. My goal is to produce small, self-contained patches that can be merged one by one; I will post a patchset shortly. In fact, the amount of work required is not as large as one would expect. |
Comment author: @whitequark I have uploaded three small patches, which allow Android cross-compilation to proceed (both world and world.opt), given that config/{Makefile,m.h,s.h} are provided. This can be easily tested using:
I will follow up these patches with ones that properly detect the target environment features without running target binaries. |
Comment author: @whitequark Actually, maybe not. I have just realized that my approach is fundamentally flawed while writing out some detailed instructions. Please wait for an updated patchset. |
Comment author: strobegen I will try to test when it be ready |
Comment author: @whitequark @gasche, I've attached a patch that brings cross-builds one step closer. Specifically this patch ensures that the variable CAMLRUN, which is already set by the configure script, is actually used when running boot/ binaries, freshly built binaries, and is also embedded in the shebang line in all the built tools. It also replaces some usage of gcc with $(CC). |
Comment author: @gasche Applying the patch makes "make world.opt" fail on my machine at the following point: make ocamlc.opt |
Comment author: @whitequark I've updated the patch. Notable changes:
make world world.opt now passes. |
Comment author: @gasche The patch seems okay in principle and I was about to merge it, but:
whitequark, would you mind preparing two versions of the patch, one that applies cleanly to trunk and the other for 4.02. I feel sorry to ask for such tedious work, I could do it but I'll rather try to merge the other patches on my list during my weekend time window. Damien, could you give your opinion on whether the present change and trunk@15784 are eligible for 4.02+dev? |
Comment author: @damiendoligez @whitequark if you don't want to bother with two versions of the patch, let's go for 4.02 and I'll deal with the conflicts when I merge it into trunk (after the 4.02.2 release). Or split it into two patches, one for CAMLRUN and one for CC. I'm a bit nervous with the use of -use-runtime because it precludes using libraries that have C object files, but I guess it's OK for building the compiler. There is a small problem with the patch: as far as I can tell, it gives the -use-runtime option twice to the compiler (but only in Makefile, not in Makefile.nt). You have to decide whether to add it to OCAMLC or to give it on the command line. I'm OK for integrating this and trunk@15784 into 4.02.2. |
Comment author: @whitequark I've attached diffs for 4.02 and trunk. I've fixed the double -use-runtime problem. |
Comment author: @gasche Damien, I just tried to cherry-pick trunk@15784 in 4.02, but:
My guess would be that -DPROFILING is the right thing to do both in trunk and in byterun/. I can make the change but I'd rather double-check it. |
Comment author: @whitequark Ping? |
1 similar comment
Comment author: @whitequark Ping? |
Comment author: @damiendoligez Re: -DPROFILING I fixed it in 4.02 and not trunk because it will get merged eventually, and I don't expect it to cause problems in the meantime. It's in asmrun and not byterun because byterun doesn't have a set of object files annotated for profiling. PS. If commit 15762 is bothering you, feel free to overwrite it, it's not important. |
Comment author: @damiendoligez I cherry-picked trunk@15784. Then I tried to apply this patch (the "trunk" one applies cleanly to 4.02) but there is a problem: it breaks the bootstrap. The way you use I think the solution is to replace |
Comment author: @whitequark No, this of course does not work. The cross-compiling patch uses -use-runtime in order to set the #! field correctly. With your patch, the /bin looks like this: In order for cross-compilation to be possible, all of these should point to #!/home/whitequark/.opam/4.02.1+32bit/bin/ocamlrun. (I'm especially puzzled by ocamlopt, which is not required for bootstrapping...) |
Comment author: @damiendoligez For ocamlopt (and ocaml): it's because they are made by the same Makefile as ocamlc. I think the solution is to use an as-yet undocumented feature of these two options: if you specify both -use-runtime and -use-prims, the list of primitives will come from -use-prims but the runtime path will come from -use-runtime. It works because the bootstrap doesn't care what's in the header, and when you're cross-compiling the lists of primitives are the same so you care only about the header. Here is a new diff. Please check if it works for cross-compilation. |
Comment author: @whitequark Yup, this works completely! I've imported it in opam-android and I have built the compiler and a few packages, with C extensions and not. Amazing. Thank you so much for your work on this. |
Comment author: @damiendoligez Patch applied to branch 4.02 (rev 16093). |
Comment author: @damiendoligez Except that it doesn't work... I've reverted the patch while we're investigating. |
Comment author: @damiendoligez Mark Shinwell and I brainstormed about this issue, here are our Here is why it doesn't work: in normal mode, it sets the absolute path What we need is to set the header to the absolute path of the Then, if you want to For example, assuming you want to install in binary directory on target = /usr/local/bin and you need to use: Then the bytecode file headers will have the correct value: If the target's filesystem is not mounted on the host, you can choose This is all from analyzing the build procedure and the previous |
Comment author: @whitequark No, that's wrong. I'm not cross-building the compiler itself! The newly built compiler will be executed on the same machine, and from the same filesystem, as the host compiler. The reason I need to change ocamlrun at all is that by default, the #! in the newly built compiler points to /its own/ ocamlrun, which is built, like the runtime library is, for the target, and so it cannot be executed on host. |
Comment author: @whitequark Essentially the problem we're running into is that the compiler and the runtime library (and thus ocamlrun) built in the same build tree will be executed on different architectures. |
Comment author: @damiendoligez Ah ok I understand now. Here is a new plan:
Does this sound workable? |
Comment author: @damiendoligez Can you try this new version (camlrun-fixed-4.diff) ? |
Comment author: @whitequark It seems to build correctly but fails at installation: cd byterun; make install |
Comment author: @whitequark After removing the |
Comment author: @damiendoligez The purpose of For ocamlyacc, we should probably do the same as for ocamlrun, namely copy the one from the pre-existing install. For ocamlrund, we should not install it on the host. I'll make a new patch. |
Comment author: @whitequark The OPAM package supplies a config/Makefile explicitly: https://github.com/whitequark/opam-android/blob/master/packages/ocaml-android32.4.02.2/files/config/Makefile.in#L9 |
Comment author: @dbuenzli @doligez it's always a good idea to have a look at the posix spec. You'll see that the type utility has neither standarized argument options nor standarized a output. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/type.html |
Comment author: @dbuenzli
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html |
Comment author: @damiendoligez
I've left the install of ocamlrund for the moment, I'll probably later add a variable to config/Makefile (CROSS_COMPILER=true/false) to handle this. Can you please check this new version (camlrun-fixed-5.diff)? @dbuenzli thanks for the advice but I'd already extended the |
Comment author: @whitequark The new patch does not apply at all to the 4.02 branch. |
Comment author: @damiendoligez I'm sorry, the branch moved under my feet. Here's one that applies cleanly. |
Comment author: @mshinwell whitequark: does the new patch work? |
Comment author: @whitequark No, it does not apply. |
Comment author: @damiendoligez I think I know what's going on. 4.02 is changing, and you're getting the version from the mirror, which is up to 4 hours behind the version I get. I'll make a GitHub PR, it'll be easier to work with that. |
Comment author: @damiendoligez Let's continue this discussion (and debugging) at #183 . |
Comment author: @damiendoligez applied to branch 4.02 (rev 16114) |
Original bug ID: 6266
Reporter: strobegen
Assigned to: @damiendoligez
Status: closed (set by @damiendoligez on 2015-05-12T14:46:59Z)
Resolution: fixed
Priority: normal
Severity: feature
Target version: 4.02.2+dev / +rc1
Fixed in version: 4.02.2+dev / +rc1
Category: ~DO NOT USE (was: OCaml general)
Tags: patch
Related to: #4303 #5887 #6613
Parent of: #6861
Monitored by: @whitequark @gasche @dbuenzli gerd
Bug description
I guess that out of box compiling support for mobile platforms like iOs and Android might be a significant stimulus for popularization of language.
Currently mobile market is huge in stlll growing (for instance http://www.asymco.com/2012/01/17/the-rise-and-fall-of-personal-computing/).
I think that creating lot of bindings for native platforms APIs (like Xamarian did for mono, for instance) is not so important - that is really necessary that:
File attachments
The text was updated successfully, but these errors were encountered: