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

Allow generating bytecode executables without the header #6199

Closed
vicuna opened this issue Oct 2, 2013 · 6 comments
Closed

Allow generating bytecode executables without the header #6199

vicuna opened this issue Oct 2, 2013 · 6 comments

Comments

@vicuna
Copy link

vicuna commented Oct 2, 2013

Original bug ID: 6199
Reporter: @alainfrisch
Status: confirmed (set by @damiendoligez on 2014-06-04T20:05:23Z)
Resolution: open
Priority: normal
Severity: feature
Category: configure and build/install
Monitored by: @gasche

Bug description

ocamlc generates bytecode executable starting with a header in charge of launching ocamlrun. Under Unix, this is a simple #! header (containing the absolute path of ocamlrun) and under Windows, this is an ad hoc program obtained from stdlib/header.c. This creates some issues:

  • Bootstrapping the compiler produces ocamlc/ocamllex executables (stored in the SVN) which depend on the machine where bootstrapping was done. Simply bootstrapping the same version on two different working copies will give different results.

  • The header encourages to not call ocamlrun explicitly, but this makes it difficult to provide a relocatable binary distribution of the toolchain, or simply to distribute a bytecode executable (if not compiled with -custom, we really need to call ocamlrun anyway).

  • Under Windows, the header is not tiny (about 223kB). (Arguably, we don't really care.) More importantly, maybe, is that calling a bytecode executable with the header creates two Windows processes, while using ocamlrun explicitly creates only one.

I propose to add a link-time flag to ocamlc to avoid inserting an header in the resulting program (and probably stop setting its executable flag). Or maybe this could simply be a special value for use_runtime. We would then use this flag so that the bootstrap tools (boot/ocamlc, boot/ocamllex) don't contain this header.

This will not fix the idempotency problem completely (because some local configuration values are hardcoded in config.ml), but it will be a good step in this direction. Having real idempotency of the bootstrap procedure would allow a nice application: checking in a CI server that the bootstrap fixpoint is reached in the SVN.

@gasche
Copy link
Member

gasche commented Mar 22, 2019

Note: I want to have relocatable OCaml binaries, so that the opam binary cache can work across switches. (Currently the new esy tool uses the hack of rewriting path inside the executables to provide this feature.).

On the specific problem of the shebang, there are two ways to do it:

  1. I would like to experiment with what happens, in an opam world, if you use #!/usr/bin/env ocamlrun; this should work as long as the right opam/$switch/bin is in your path, and it may be the simplest solution.
  2. The other option is to remove shebangs everywhere, and stop expecting that ./foo.byte will work. The question is to know how many OCaml packages break if you remove shebangs, and for that my plan it to implement a configure-option that remove all shebangs, and try to build the opam universe in that world.

I expect the present feature request to be very useful when playing around to implement option (2).

@yakobowski
Copy link
Contributor

The other option is to remove shebangs everywhere, and stop expecting that ./foo.byte will work.

Irrespective of whether this breaks the compilation of packages or not, you would also be breaking a long-established tradition. I suspect many users rely on bytecode "executables" to be well, executable. And given the variations in compilation times between bytecode and native, I believe that many people debug using the bytecode versions.

@damiendoligez
Copy link
Member

@gasche in the meantime you can exploit the second bug I describe in #8537 and just use -runtime-variant none, that will give you a bytecode file without shebang.

@gasche
Copy link
Member

gasche commented Mar 22, 2019

@yakobowski the build scripts I can test in the opam-repository. People will have to take care of themselves :-)

In any case, I now believe that the advantages of relocatability outweigh the costs (but of course we should try to reduce those as well).

@dbuenzli
Copy link
Contributor

xref with #5950 the (suspended) relocatable compiler issue.

@dra27
Copy link
Member

dra27 commented Jul 19, 2019

This issue is (I think) completely addressed by the --without-runtime option in 4.09.0

@dra27 dra27 closed this as completed Jul 19, 2019
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