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
Do not require bitness of compiler host and target to match #6859
Comments
Comment author: @gasche I'm postponing this to 4.04, as no direct progress was made during the 4.03 timeline. I heard that we might see more work on cross-compilation in the medium-term future, so hopefully this will move. |
Bumping this as I encountered the problem on 4.07 with the ESP32 backend (not officially supported but I tested it a lot with Mirage). Building the 32bit cross-compiler using a 64bit host compiler lead in wrong assumptions on integers. Thus I had |
Yeah, you need the |
Yes that's what I currently use, so this is definitely not a blocker. It's more of a feature request to reduce the time taken to build a 32bit cross-compiler from a 64bit switch. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Still an issue. |
Does someone know how opam proceeds to deal with the issue?
It seems highly non-trivial to me,, at the moment.
I guess this will be fixed by the whole work on cross-compiling, but
it's probably not possitle to work on just fixing this directly, out of
this global cross-compiling context.
|
The opam switches for creating 32-bit compilers on 64-bit machines (with the There is some very limited support for correctly separating the compiler's own integers (of type |
OK thanks! Makes sense and things are clear!
|
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Still an issue as far as I know. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Original bug ID: 6859
Reporter: @whitequark
Assigned to: @shindere
Status: assigned (set by @damiendoligez on 2017-03-01T13:03:01Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.02.2+dev / +rc1
Category: platform support (windows, cross-compilation, etc)
Tags: cross-compilation
Monitored by: @gasche @diml
Bug description
Currently, it is only possible to build 32-bit binaries using a 32-bit compiler running under a 32-bit ocamlrun. This is annoying for cross-compilers, although tools like opam lessen the pain.
The chief reason for this issue is the fact that integer immediates are stored as
int
, e.g.Const_int of int
and probably a few more places. I recall some plan for low-impact functorization of that aspect of the compiler but I could not find it on mantis, so I'm filing this issue.The text was updated successfully, but these errors were encountered: