Build failure on raspberry pi: "input_value: integer too large"

[vicuna]

Original bug ID: 5977
Reporter: gildor
Assigned to: @alainfrisch
Status: closed (set by @xavierleroy on 2015-12-11T18:18:36Z)
Resolution: fixed
Priority: normal
Severity: minor
Platform: armv6l
OS: Raspbian (aka Debian Wheezy)
OS Version: wheezy
Version: later
Category: ~DO NOT USE (was: OCaml general)
Related to: #5575 #5793 #5986
Monitored by: @dbuenzli

Bug description

When trying to build from a clean environment:

make[2]: Entering directory /home/jenkins/workspace/ocaml/label/femto/stdlib' ../boot/ocamlrun ../boot/ocamlc -strict-sequence -w +33..39 -g -warn-error A -nostdlib ./Compflags pervasives.cmi` -c pervasives.mli
Fatal error: exception Failure("input_value: integer too large")
make[2]: *** [pervasives.cmi] Error 2

Full log here:
http://deci.ovh.le-gall.net:8080/job/ocaml/label=femto/25/console

Steps to reproduce

Build from scratch on Raspbian system:
svn co
make clean || true
./configure
make world

Additional information

Feel free to contact me if you need to access the system.

File attachments

• consoleText.txt

[vicuna]

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).

[vicuna]

Comment author: @alainfrisch

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

[vicuna]

Comment author: @alainfrisch

See also #5575.

[vicuna]

Comment author: @alainfrisch

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

[vicuna]

Comment author: @alainfrisch

Fixed in commit 13488 (on trunk).

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

[vicuna]

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.

[vicuna]

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).

[vicuna]

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).

[vicuna]

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!

[vicuna]

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.

[vicuna]

Comment author: gildor

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

[vicuna]

Comment author: @alainfrisch

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