|Anonymous | Login | Signup for a new account||2017-05-27 12:04 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005977||OCaml||~DO NOT USE (was: OCaml general)||public||2013-04-08 23:49||2015-12-11 19:18|
|Platform||armv6l||OS||Raspbian (aka Debian Wheezy)||OS Version||wheezy|
|Target Version||Fixed in Version|
|Summary||0005977: Build failure on raspberry pi: "input_value: integer too large"|
|Description||When trying to build from a clean environment:|
make: 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: *** [pervasives.cmi] Error 2
Full log here:
|Steps To Reproduce||Build from scratch on Raspbian system:|
make clean || true
|Additional Information||Feel free to contact me if you need to access the system.|
|Tags||No tags attached.|
|Attached Files||consoleText.txt [^] (20,498 bytes) 2013-04-08 23:49 [Show Content]|
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 PR#5793).
|This seems to be caused by some integer constants in stdlib/random.ml|
|See also 0005575.|
|I'll modify those constants to apply the "land 0x3fff..." filter to make them 32-bit friendly.|
edited on: 2013-04-09 14:20
Fixed in commit 13488 (on trunk).
Sylvain: can you check that this indeed fixes your problem as well?
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.
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).
|... 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).|
|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!|
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.
|The compilation on the RPi now succeed on this step (but fail after due to having enough memory in camlp4).|
|Thanks for the feedback. Concerning camlp4, you can disable its compilation quite simply now (./configure -no-camlp4).|
|2013-04-08 23:49||gildor||New Issue|
|2013-04-08 23:49||gildor||File Added: consoleText.txt|
|2013-04-09 13:41||frisch||Note Added: 0009047|
|2013-04-09 13:51||frisch||Note Added: 0009048|
|2013-04-09 14:04||frisch||Note Added: 0009049|
|2013-04-09 14:04||frisch||Relationship added||related to 0005575|
|2013-04-09 14:05||frisch||Relationship added||related to 0005793|
|2013-04-09 14:14||frisch||Note Added: 0009050|
|2013-04-09 14:14||frisch||Assigned To||=> frisch|
|2013-04-09 14:14||frisch||Status||new => assigned|
|2013-04-09 14:18||frisch||Note Added: 0009051|
|2013-04-09 14:20||frisch||Note Edited: 0009051||View Revisions|
|2013-04-09 14:25||frisch||Note Added: 0009052|
|2013-04-09 15:35||gildor||Note Added: 0009053|
|2013-04-09 15:39||gildor||Note Added: 0009054|
|2013-04-09 16:04||frisch||Note Added: 0009055|
|2013-04-09 16:14||gildor||Note Added: 0009056|
|2013-04-10 00:26||gildor||Note Added: 0009057|
|2013-04-10 00:26||gildor||Status||assigned => resolved|
|2013-04-10 00:26||gildor||Resolution||open => fixed|
|2013-04-10 09:19||frisch||Note Added: 0009058|
|2013-04-15 11:12||frisch||Relationship added||related to 0005986|
|2015-12-11 19:18||xleroy||Status||resolved => closed|
|2017-02-23 16:36||doligez||Category||OCaml general => -OCaml general|
|2017-03-03 17:55||doligez||Category||-OCaml general => -(deprecated) general|
|2017-03-03 18:01||doligez||Category||-(deprecated) general => ~deprecated (was: OCaml general)|
|2017-03-06 17:04||doligez||Category||~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)|
|Copyright © 2000 - 2011 MantisBT Group|