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

Do not require bitness of compiler host and target to match #6859

Open
vicuna opened this issue May 7, 2015 · 13 comments
Open

Do not require bitness of compiler host and target to match #6859

vicuna opened this issue May 7, 2015 · 13 comments

Comments

@vicuna
Copy link

vicuna commented May 7, 2015

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.

@vicuna
Copy link
Author

vicuna commented May 7, 2015

Comment author: @gasche

#170 ( #170 ) seems related as it keeps integers as strings during the parsing phase -- they are converted back in typecore.ml.

@vicuna
Copy link
Author

vicuna commented Apr 18, 2016

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.

@TheLortex
Copy link
Contributor

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 max_int equal to -1 due to incorrect optimizations.

@whitequark
Copy link
Member

Yeah, you need the +32bit opam switch.

@TheLortex
Copy link
Contributor

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.

@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label May 11, 2020
@whitequark
Copy link
Member

Still an issue.

@ghost ghost removed the Stale label May 12, 2020
@shindere
Copy link
Contributor

shindere commented Jun 4, 2020 via email

@lthls
Copy link
Contributor

lthls commented Jun 4, 2020

The opam switches for creating 32-bit compilers on 64-bit machines (with the +32bit suffix) simply pass some options to the configure script so that the compiler assumes a 32-bit architecture, and the external tools (the C compiler, linker and assembler) are called with the right options to generate 32-bit code. This works because at least on x86, 64-bit processors (and operating systems, I assume) include support for running 32-bit executables, so even executables (like ocamlrun) generated for the target can be run on the host.

There is some very limited support for correctly separating the compiler's own integers (of type int) from the target's integers in the Targetint module, and proper cross-compilation support will likely build on it, but for now it is only used in a few places.

@shindere
Copy link
Contributor

shindere commented Jun 4, 2020 via email

@github-actions
Copy link

github-actions bot commented Nov 8, 2021

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.

@github-actions github-actions bot added the Stale label Nov 8, 2021
@whitequark
Copy link
Member

Still an issue as far as I know.

@github-actions github-actions bot removed the Stale label Nov 10, 2021
@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label Nov 14, 2022
@lthls lthls removed the Stale label Nov 14, 2022
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

6 participants