Skip to content
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

asmcomp/arch.cmi and asmcomp/mach.cmi make inconsistent assumptions over interface Arch on RPi only #6344

Closed
vicuna opened this issue Mar 7, 2014 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Mar 7, 2014

Original bug ID: 6344
Reporter: gildor
Assigned to: gildor
Status: closed (set by @xavierleroy on 2016-12-07T10:48:54Z)
Resolution: fixed
Priority: normal
Severity: minor
Platform: raspberry pi
Version: 4.02.0+dev
Category: back end (clambda to assembly)

Bug description

Hi,

I got the following error 3 time in a row. I checked for deletion of file in recent commit but found nothing:

boot/ocamlrun ./ocamlopt -nostdlib -I stdlib -I otherlibs/dynlink -strict-sequence -w +33..39 -warn-error A -I utils -I parsing -I typing -I bytecomp -I asmcomp -I driver -I toplevel -c asmcomp/mach.ml
File "asmcomp/mach.ml", line 1:
Error: The files asmcomp/arch.cmi and asmcomp/mach.cmi
make inconsistent assumptions over interface Arch

Steps to reproduce

http://deci.ovh.le-gall.net:8080/job/ocaml/201/label=raspberrypi/console

@vicuna
Copy link
Author

vicuna commented Mar 21, 2014

Comment author: @maranget

I ran accross the same issue on ARM 32bits.
I solved it by bootstraping the compiler (make bootstrap)

--Luc

@vicuna
Copy link
Author

vicuna commented Mar 25, 2014

Comment author: gildor

Fixed as a side effect of r14479.

@vicuna
Copy link
Author

vicuna commented Apr 22, 2015

Comment author: @damiendoligez

FTR, this bug has appeared again (on the CI machines).

It is a combination of two things:

  1. asmcomp/arch.ml doesn't have a corresponding .mli file
  2. ocamlc and ocamlopt produce .cmi files with different digests when compiling this file

This is because ocamlc (which is the bootstrap byte-code executable from the svn repo) is lagging behind ocamlopt (freshly compiled from the latest sources).
Hence bootstrapping solves the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant