<div dir="ltr"><div>Out of curiosity, do we have a pointer to the "relocation patch" and its upstreaming discussion? If some upstream changes can be made to make binary distribution easier, we could try to push them.<br><br></div>(If I understand <a href="https://github.com/ocaml/opam-repository/blob/master/compilers/4.02.3/4.02.3%2Bmusl%2Bstatic/4.02.3%2Bmusl%2Bstatic.comp">https://github.com/ocaml/opam-repository/blob/master/compilers/4.02.3/4.02.3%2Bmusl%2Bstatic/4.02.3%2Bmusl%2Bstatic.comp</a> correctly, the upstream compiler needs no patching to work with musl.)<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 22, 2016 at 8:53 AM, Anil Madhavapeddy <span dir="ltr"><<a href="mailto:anil@recoil.org" target="_blank">anil@recoil.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 22 Jan 2016, at 05:47, Louis Gesbert <<a href="mailto:louis.gesbert@ocamlpro.com">louis.gesbert@ocamlpro.com</a>> wrote:<br>
><br>
> Le vendredi 22 janvier 2016, 08:34:34 Gabriel Scherer a écrit :<br>
>> I would be interested in some more information on this. This seems very<br>
>> simple as you say it, but I had not thought about the fact that OPAM<br>
>> already has the capacities to act as a binary distribution platform -- I<br>
>> somehow thought that there would be an announcement of some new extra<br>
>> features at some point designed for binary distribution.<br>
>><br>
>> Louis, you are saying that this is feasible. Are you aware of this actually<br>
>> having been done? For example, is anyone working on providing a, say, opam<br>
>> repository for x86-64 binaries corresponding to the packages available on<br>
>> opam-repository?<br>
>><br>
>> I suppose that if people proposed that, they would probably pre-build<br>
>> binaries for only a subset of the possible packages or configurations.<br>
>> Would it work to mix a "binary repository" that provides only a subset of<br>
>> the packages, and the official source repository, and would package query<br>
>> solvers have a way to do the right thing there? Or would it be the<br>
>> responsibility of the alternate repository provider to include a<br>
>> source-only fallback for the non-distributed packages? (This would make it<br>
>> harder to have a single repository with binary packages for several<br>
>> architectures.)<br>
><br>
> `ocp-bin` was an experiment to provide such a cache of pre-built packages,<br>
> falling back to building from source when unavailable for the current setup.<br>
> With the official OCaml distribution, you would hit issues of relocation<br>
> though, although there are some hacks around that<br>
> (<a href="https://github.com/OCamlPro/ocp-reloc" rel="noreferrer" target="_blank">https://github.com/OCamlPro/ocp-reloc</a>)<br>
><br>
> So although there are no real barriers in Opam for a binary repository, doing<br>
> something like a conversion from source repo to binary repo, especially with<br>
> OCaml, raises some challenges.<br>
<br>
</div></div>How about an OPAM switch that uses the compiler relocation patch and musl libc and the right CFLAGS to link everything statically by default?  That should provide an experience similar to Go, with an output binary that is standalone (including libc).<br>
<span class="HOEnZb"><font color="#888888"><br>
Anil<br>
<br>
</font></span></blockquote></div><br></div>