Comment author: @alainfrisch

This problem has also been spotted on (other) 32-bit architectures. Bootstrapping the compiler (on today's trunk) on a 64-bit architecture results in bytecode executables containing 64-bit integers which cannot be read on a 32-bit machine.

This has been introduced by commit 13241 (intended to fix #5793).

Comment author: @alainfrisch

This seems to be caused by some integer constants in stdlib/random.ml

Comment author: @alainfrisch

See also #5575.

Comment author: @alainfrisch

I'll modify those constants to apply the "land 0x3fff..." filter to make them 32-bit friendly.

Comment author: @alainfrisch

Fixed in commit 13488 (on trunk).

Sylvain: can you check that this indeed fixes your problem as well?

Comment author: @alainfrisch

We should find a way to avoid such problems in the future. The problem is that some hexadecimal integer constants are valid in 32-bit but result in a different integers than on 64-bit, thus making it impossible to have a proper marshaling/demarshaling round-trip between those architectures.

This is somehow similar to unprotected end-of-line in string literals, which produce different strings according to the platform. We could similarly introduce a warning in the parser to spot report such integers.

It would also be useful to introduce a new marshaling flag to prevent the marshaler from producing 64-bit integers (and maybe somehow find a way to enable this flag during bootstrap), in order to check upon marshaling that the resulting data will be readable by a 32-bit process.

Comment author: gildor

I'll check it tonight, right now my RPi jenkins slave is not up.

Although, if you want to avoid such situation, you can use my jenkins builder! I can provide you with an account and instruction to setup a svn hook that will automatically trigger build on Debian Squeeze 32/64 bits and RPi (need to setup this node as well) when you commit to trunk.

I am also planning to add Mac OS X and probably Windows (long term plan).

Comment author: gildor

... and send a mail to the ocaml-dev list and if you really want transform the test suite into JUnit compliant test to get a nice overview of what is broken and... (feel the blank with what is need for continuous integration).

Comment author: @alainfrisch

Are you in touch with OCamlLabs folks? My understanding is that they planned to work on continuous integration for OCaml. Let's not duplicate the effort!

Comment author: gildor

I know they are working on something, not sure what and when it will be available. So far my understanding was that it was all about OPAM, OCaml just being the starting point. I think it is a lot more general than just OCaml...

Anyway, my proposal is just about providing a solution for today bug. It will run anyway, but with 1 day of latency (I scan the SVN of caml everyday).

Side Note: you can start with my jenkins instance and continue with OCamlLabs, half of setting up continuous integration is a matter of making your code "testable" automatically.

Comment author: gildor

The compilation on the RPi now succeed on this step (but fail after due to having enough memory in camlp4).

Comment author: @alainfrisch

Thanks for the feedback. Concerning camlp4, you can disable its compilation quite simply now (./configure -no-camlp4).