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 install native-code executables when cross-compiling #6861

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

Do not install native-code executables when cross-compiling #6861

vicuna opened this issue May 7, 2015 · 7 comments

Comments

@vicuna
Copy link

vicuna commented May 7, 2015

Original bug ID: 6861
Reporter: @whitequark
Assigned to: @shindere
Status: assigned (set by @damiendoligez on 2015-05-08T21:15:11Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.02.2+dev / +rc1
Category: configure and build/install
Tags: cross-compilation
Child of: #6266
Monitored by: @gasche

Bug description

The buildsystem builds a few executables, namely ocamlrun{,d} and ocamlyacc, which cannot be executed since they are built for the target, not host, architecture.

Since ocamlrun and ocamlyacc are a hard dependency for building a cross-compiler, they can be simply symlinked to whatever was used to build the cross-compiler.
ocamlrund may not be present and it is also not a dependency of anything in OCaml ecosystem, so it can be just not installed. It probably makes sense to not build these when cross-compiling as well.

@vicuna
Copy link
Author

vicuna commented May 8, 2015

Comment author: @damiendoligez

It probably makes sense to not build these when cross-compiling as well.

I'm not sure I understand this. It makes a lot of sense to build them so the user can install them on the target, right?

@vicuna
Copy link
Author

vicuna commented May 9, 2015

Comment author: @whitequark

ocamlyacc, no. It is a tool designed to run alongside ocamlc, and ocamlc is not built to be installed on target in the case of a cross-compiler.

ocamlrun{,d}, well, theoretically maybe yes. I don't ever envision building anything without -custom, but I can see why you'd want this for completeness. You could put the target-ocamlrun into lib/ocaml, next to libcamlrun.so.

@whitequark
Copy link
Member

Still an issue.

@github-actions github-actions bot removed the Stale label Jun 15, 2020
@github-actions github-actions bot added the Stale label Jun 16, 2021
@whitequark
Copy link
Member

Still an issue.

@gasche gasche removed the Stale label Jun 16, 2021
@gasche
Copy link
Member

gasche commented Jun 16, 2021

I think that @dra27 and @shindere and @EduardoRFS have been interested in cross-compilation. Personally I consider our build system unpalatable right now, so I avoid working on it when I can.

@EduardoRFS
Copy link
Contributor

EduardoRFS commented Jun 16, 2021

When cross-compiling using make the build system it essentially is cross compiling the compiler to be executed in the target, so it's more like bootstrapping the compiler to a platform.

Maybe a short term solution would be introducing a CROSS_COMPILE=true flag on make, this would also allow to work around the checkstack problem at https://github.com/ocaml/ocaml/blob/trunk/Makefile#L982 This seems wrong, the configure.sh already knows if something is a cross compiler or not, so this solution is just bad, seems reasonable that ocamlrun shouldn't be installed when cross compilation is detected anyway.

I also have this problem at
https://github.com/EduardoRFS/reason-mobile/blob/master/patches/ocaml/files/make.cross.sh#L160

@shindere
Copy link
Contributor

shindere commented Sep 8, 2021 via email

@github-actions github-actions bot added the Stale label Sep 12, 2022
@dra27 dra27 removed the Stale label Sep 13, 2022
@ocaml ocaml deleted a comment from github-actions bot Sep 13, 2022
@ocaml ocaml deleted a comment from github-actions bot Sep 13, 2022
@ocaml ocaml deleted a comment from github-actions bot Sep 13, 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