dunification of MirageOS #1020

dinosaure · 2019-12-04T16:33:12Z

/cc @mirage/core and @TheLortex

Hi all, this is the first draft of a not-completely tested dunification of MirageOS. First, this PR does not work but I think, I reached a step where we need to start to talk technically about the dunification of MirageOS and when we should track minor updates.

The Pull-Request

The PR is the smallest of what I can do (and #1017 helps me a lot). Each commit has a description about the goal and update only one file per one file the project to avoid a misleading of patches.

This PR does not have deletion - not yet. Some warnings (eg. 32) was added. The goal is to propose a smooth view about the dunification of MirageOS.

This PR is only about the dunification. Behind this word, we can imagine a lot (duniverse, variants and so on) but the only goal is to use dune to compile an unikernel.

This PR is not yet fully tested. Currently, only pasteur was tested - pasteur includes a large stack when it use irmin.2.0.0, git and digestif and conduit with httpaf (including tls and nocrypto even if we don't support HTTPS, shame on me). Only UNIX and Solo5 target are tested - I don't have a deployment process for Xen. Despite all this, pasteur still is a good PoC to test/improve dunification of MirageOS.

This PR trusts on dune.2.0.0. Several features are used but not so really required. Small patches on some libraries needed by pasteur are needed because:

they don't compile on dune.2.0.0
they have the UNIX module

This PR should not expect anything else from dune.2.0.0

Issues on the eco-system

MirageOS has a large eco-system where we can find some unusual packaging politics. When we are the ownership on these packages, it's fine to update them according the dunification of MirageOS. However, it's not totally the case where some MirageOS unikernels depend on some libraries outside the scope of the MirageOS organization.

According all of that, and even if we have this PR, we still have some issues on our eco-system. The goal of this PR and the dunification in general is not to fix all of these issues. At least, we highlighted them. But, please, keep in your mind that the only goal of this PR is to tap dune build in his keyboard.

One of the biggest issue on the eco-system was fixed with #1010. I don't want to re-explain all the story about mirage-os-shim, however, as I said, this issue highlighted a weak about a documentation of: how to be MirageOS compatible? And we just discovered that we have many ways.

But an other issue still exists on this PR and was explained/discussed into #1018 about pkg-config. dune can provides some others ways to do some tricks at the link time (eg. variants) but it's not the purpose of this PR. However, we should start then to talk about all of that.

The last issue is about GMP and we will go a bit into details.

Zarith and GMP

The zarith.cmxa has an information used by ocamlopt then: -lgmp. If you want to compile an executable or an object with zarith and without -noautolink, ocamlopt will emit to gcc (at the link time) -lgmp (and then, gcc will take libgmp.a available into your LD_LIBRARY_PATH).

Of course, considering targets like Solo5 or Xen, libgmp.a available on your system does not fit into constraints expected by Xen or Solo5. GMP must be compiled with specific C flags.

This is the purpose of the package gmp-freestanding and gmp-xen. My only concern about this way is to rename libgmp_freestanding.a and libgmp_xen.a to libgmp.a and let the compiler to choose these implementations according the target. Considering flags, Solo5 and Xen can provide in some ways -L$(opam config var lib)/gmp-{freestanding,xen} as a dependency.

NOTE: that means for any compilation of any unikernels, -L shoud always be emitted by mirage-os-xen or ocaml-freestanding even if the unikernel does not depend on gmp. However, -lgmp will be emitted only if we want to link with zarith.cmxa.

Versatility of the linking

The linking step is done by gcc currently in our OCaml world, the linking step is super versatile where static libraries are chosen depending of which path is available on the command-line (and the environment). The predictability of which library will be statically linked to our unikernel is hard to follow/track.

A new tool was added into mirage: cc-to-opt or cc-to-ocamlopt which will takes C flags and do a translation of -L to -I and -l to -cclib -l. It wants to resolve static libraries and say that they exists according all given path by -L. Then, it re-order options due to the precedence of -L over -l (-LA -la -LB and -LA -LB -la don't have the same behavior if liba.a is available into A and B - this behavior is pretty-close to the GMP case where libgmp.a is available into several directories).

At the end, the choice was made to let ocamlopt to link the object file (for Xen/Solo5/Unix). Then, and ld command will be done according the target:

unix: nothing to do, at least, an ln -sfn
solo5: ld with Solo5 link script
xen: ld with some options

Correctness of C stubs linked

The previous point want to serve an other issue about the expected flags used to compile C sources (like GMP or digestif). An unikernel for Solo5 which links with digestif.c (compiled to be used by an UNIX executable) can work. That means that silently, we can link with the wrong libdigestif.a and the unikernel still works.

The only way to verify that we link with the right C stubs is to check (from what I know) assembly code between your unikernel and expected static library.

At this stage, no solution exists so. But, again, this PR highlighted this issue.

UNIX module and `-dontlink`

On the currant status of MirageOS, ocamlbuild is used with -dontlink to avoid any link with unix.cmxa. However, we lost this option if we want to use dune.

About that, the deletion of this option/feature highlighted several packages which are linked with unix.cmxa mostly because they want to be linked with bigarray.cmxa which contains map_file (an UNIX syscall). Again, some packages have this dependency again (like sexplib).

This is the purpose of bigarray-compat and we should use it at any of our projects, at least.

Issue on `dune`

dune unlocks several features to improve the way to compile an unikernel. Some of them are not used now but they exist. The notably feature is, may be, the variant where dune can orchestrate the choice of which OCaml library we should use according the target (freestanding or xen).

At this stage, it's possible to use it when the generated dune file describe which variant it will use (with the variant field).

A proposition on Zarith was made by @TheLortex in this way. We can talk about that on an other issue/PR but the idea is to have a Zarith library which provides freestanding and xen which the right link with GMP.

Another feature is about the forbidden_libraries which is not yet used - but it can be. The purpose of it is to follow who want to link with a specific library and, in our case, unix.cmxa. This dune's field can help us a lot to track the compatibility with MirageOS of our libraries.

The compilation of an unikernel with dune unlocks an other way to develop an our MirageOS where we can start to use duniverse and have a self-contained workspace of all of what we need. In this way, mirage still continues to emit an OPAM file used by duniverse then to download all libraries needed by our unikernel.

And from that, dune can provide a well-defined workspace with right C flags according the target to let the user to use C stubs without the hard plumbing needed when we want to package that to OPAM.

(dirs ...)

The only problem today about dune is: we can not use (dirs ...) to load some specific underlying directories into the dune.build file. I don't know why. The current trick is that mirage configure rewrite not-only dune.build but dune too to load correctly files needed to compile unikernel.

flags needed by the target

Currently, a proper way to get flags needed by the target (C flags for C stubs and linking flags for ld) is not well-defined. The current way chosen by Solo5 is to use pkg-config. The other way chosen by Xen is to provide into the distribution of mirage-os-xen some files needed by dune then.

An explanation is available here: mirage/ocaml-solo5#66

This question is pretty-close to what we want to do with pkg-config (if we want to use it or remove it). Currently, we don't have an homogeneous way to get these information and we should start to discuss/document that.

Conclusion

Let start to talk about the dunification of MirageOS. Please, I really would like to stay focus on the real dunification of MirageOS. I know that this PR can unlock several possibilities but keep in your mind that as long as this PR will not be merged, all other discussions/issues will be vain - because the predicate is to use dune first.

Next week, I will try to provide a CI with this PR to show that this PR works! But we can start to talk about details of the way to dunify a MirageOS.

PS: thanks for reading all!

@default

This patch adds a way to configure the UNIX target where we define a dune's alias: dune build @default and an underlying rule to _generate_ the unikernel.

This module is not mandatory but give us a way to link static libraries with the _unikernel_ into a more predictable way than before. This module tries to resolve static libraries and notice to the user (by logs) which libraries will be linked.

samoht · 2019-12-04T16:53:08Z

Nice work!

The only problem today about dune is: we can not use (dirs ...) to load some specific underlying directories into the dune.build file. I don't know why. The current trick is that mirage configure rewrite not-only dune.build but dune too to load correctly files needed to compile unikernel.

Do you have an example where you need this? This is supposed to be working fine I guess.

I'll have a proper review tomorrow.

avsm · 2019-12-04T17:10:52Z

I like the overall approach. As a quick response, I think that with:

And from that, dune can provide a well-defined workspace with right C flags according the target to let the user to use C stubs without the hard plumbing needed when we want to package that to OPAM.

That this should never happen:

An unikernel for Solo5 which links with digestif.c (compiled to be used by an UNIX executable) can work.

If we just compile every target in a well defined workspace, then dune caching in dune 2.0 can make it as fast, without any dangerous sharing involved.

dinosaure · 2019-12-04T17:15:53Z

Do you have an example where you need this? This is supposed to be working fine I guess.

By facts, we need to put a (dirs ...) into dune instead dune.build when we want to have a Solo5 unikernel. (dirs ...) wants to integrate some generated files by mirage configure -t hvt available in .mirage.solo5 directory - so you can view (dirs .mirage.solo5). These flags are cflags.sexp, lflags, etc.

Into an higher-level, the question is already opened on mirage/ocaml-solo5#66 where:

in this PR, mirage will do the call to pkg-config to get flags
in the ocaml-freestanding PR, the ocaml-freestanding will provides these files

As @hannesm said, the ocaml-freestanding PR finally propose 2 ways (pkg-config and files) to get flags. May be it's wrong. In other side, mirage-os-xen provides files and the mirage tool use them - but it can, in the same way than a Solo5 target, generate by itself these files.

This patch loads into `pwd`/.mirage.solo5/ some well-formed files about flags (used by `cc` and `ld`). They will be tracked by `dune` then according emitted dune configuration. At least, these files and specially `cflags.sexp` will replace the expansion variable :standard available into `c_flags` dune's field. Compilation of manifest.o will use these flags. This part depends on `pkg-config` to load flags from *.pc files.

As UNIX and Solo5 target, Xen can emit special dune's configuration.

This patch integrate the biggest update about the _dunification_ of MirageOS where mostly all are orchestrated here. `configure_dune` is the main function to emit the right `dune.build` file according target __and__ libraries described in `config.ml` It will emit the main `(executable ...)` artifact with specific cflags and lflags. Both are delivered by a __post__ processs `configure_post_build_rules` according the requested target. cc-to-ocamlopt is used to properly link static libraries expected by `config.ml` and -l flags provided by `*.cmxa` artifacts. The executable is described as a target which will used specific variants (`xen` or `freestanding`). _dunified_ project can take the advantage of that to plug a special implementation according the target requested. A `dune-workspace` and a `dune-project` are emitted too to provide a good context about how to compile C stubs specially. `duniverse` can take the advantage of that.

See update into Mirage_clean and give a proper way to delete all generated files.

The link process is defined into the `dune.build` file and the mirage tool does not need to take care about that when `dune build` will do the linking step.

This code try to retrieve static libraries (`*.a`) according the requested target and it uses `pkg-config`. This function is used by the configuration step to emit right link flags.

This patch wants to replace the call of `ocamlbuild` to `dune` with the requested target (see alias emitted by the configuration step).

avsm · 2019-12-04T18:27:39Z

I do prefer having explicit files with the flags rather than invocations to pkg-config. The reason is that this makes tracking build systems rules far easier, instead of the environment variables we have to propagate for pkg-config. I'm happy to port the mirage-xen pieces to install files with flags (some already are installed, but possibly not completely).

dinosaure · 2019-12-04T19:28:09Z

I do prefer having explicit files with the flags rather than invocations to pkg-config. The reason is that this makes tracking build systems rules far easier, instead of the environment variables we have to propagate for pkg-config. I'm happy to port the mirage-xen pieces to install files with flags (some already are installed, but possibly not completely).

Ok good, from what I know, mirage-os-xen does not need an update about this point. If we want to follow this way about ocaml-freestanding, mirage/ocaml-solo5#66 need to be merged. By this way, (dirs ...) will not be a problem!

It seems that this last way can remove all occurrence of pkg-config into the mirage tool - however, we still need to figure out about libraries which has C stubs and want to be packaged into OPAM. This last point is out of the scope of these PR - and, currently, ocamlfind take the relay on that with linkopts field.

avsm · 2019-12-05T09:47:53Z

we still need to figure out about libraries which has C stubs and want to be packaged into OPAM

Yes, mostly this the xen support libraries, and in those case we adapt them all via files containing CFLAGS or some linkopts META file as you suggest.

dinosaure · 2019-12-05T12:12:24Z

I did a new branch clean-dunification-without-pkg-config available on my repository and diff is available here: #1021. Please I would like to continue the discussion here, I just would like to see the status of Travis and give you an easy way to see the patch.

From what I did, if we integrate mirage/ocaml-solo5#66, we mostly can delete any use of pkg-config into the mirage tool which can be good but if we do the choice, we will be stick on a less expressive mechanism to get right flags and static libraries.

At this stage and to avoid an overlap with #1018, do we want to use files or pkg-config to shape the dunification of MirageOS. We can imagine that the design with files works (but limitation can be reach easily, I think, in a near future). From what I know, nobody has a strong opinion on that, but we should keep in our mind that this solution can come with:

a double maintenance cost (with pkg-config for libraries, and files for the mirage tool)
a problem with we want to tune compilation of an unikernel

dinosaure · 2019-12-05T16:44:12Z

@samoht highlighted some problems about the linking:

ocplib-endian comes with unix (we should use https://gihtub.com/dune-universe/ocplib-endian.git#duniverse-1.0` (some others packages have this problem like sexplib)
cstruct.5.0.0 must be used (old version comes with unix)
sexplib should not be a dependency where it was used only to pretty-print s-expression
pkg-config should be removed when underlying packages like targets should not be available first - in other words, opam install mirage && mirage configure -t hvt should work (eg. dunification of MirageOS without pkg-config #1021 for implementation)

About dependencies on unix, I will add (forbidden_libraries unix) into dune.build generated for Solo5 and Xen targets to give you a proper error message (instead a link error).

dinosaure · 2019-12-06T11:00:44Z

forbidden_libraries was added into the generated dune.build file for Xen and Solo5 target here: af028f9 and it will be cherry-pick into this PR. The PR without pkg-config is better when the suppression of pkg-config is quasi-total, only Xen was not fixed about that.

The change is available in this patch: d18c02b.

Into details, flags provided by ocaml-freestanding is not very consistent where libmirage-solo5_bindings.a must be added into libs.sexp even if this static library is not a part of ocaml-freestanding (cc @mato). So I updated them to add libmirage-solo5_bindings.a, then dune.build with a specific rule copies the static library according the environment (OPAM environment or dune environment - the second is priority).

A mirage configure && mirage build or a mirage configure -t hvt && mirage build works with mirage-skeleton with OCaml 4.07.1.

dinosaure · 2019-12-06T13:34:21Z

Ok, good news, from clean-dunification-without-pkg-config, only 2 packages need an update and MODE=hvt make into mirage-skeleton works 🎉 !

nocrypto depends on bigarray: I did a new branch into Move to bigarray-compat including patch from opam-repository dinosaure/ocaml-nocrypto#1 with the smallest patch. According current status of nocrypto, I advise to add an other patch to opam-repository.
sexplib depends on bigarray: I did Use bigarray-compat instead bigarray to avoid a link with unix janestreet/sexplib#40
ocplib-endian depends on bigarray (https://github.com/dune-universe/ocplib-endian.git#duniverse-1.0)
~~gmp-freestanding must rename libgmp-freestanding.a to libgmp.a~~

mato · 2019-12-09T16:58:28Z

@dinosaure: Thanks for working on this. It's a complex change with many moving pieces, and I'm not sure I understand all the changes you are making. I'm going to try and reply to the various points you've raised, but will also ask questions that may have already been answered elsewhere, or seem "obvious" to others, so please bear with me.

This is the purpose of the package gmp-freestanding and gmp-xen. My only concern about this way is to rename libgmp_freestanding.a and libgmp_xen.a to libgmp.a and let the compiler to choose these implementations according the target.

If I understand this correctly, you are proposing that:

For a package which requires specially ("cross") compiled C libraries and a target, where target is, for example, xen or freestanding (a.k.a. Solo5):

Instead of package providing a library lib<package>_<target>.a and mucking about with META files to force the linker to use the non-standard library name, package will provide lib<package>.a in some target-specific location and something (possibly ocaml-freestanding, but see below) will provide information to mirage needed to set the linker's library search path to use only(!) libraries from the target-specific location(s).

Correct?

Considering flags, Solo5 and Xen can provide in some ways -L$(opam config var lib)/gmp-{freestanding,xen} as a dependency. NOTE: that means for any compilation of any unikernels, -L shoud always be emitted by mirage-os-xen or ocaml-freestanding even if the unikernel does not depend on gmp

Without pkg-config we lose the ability to compose -L search paths -- what you write above seems to require ocaml-freestanding to know about every possible package in order to be able to emit the -L$(opam config var lib)/<package>. That does not scale, and is the biggest limitation of dropping pkg-config altogether.

As an alternative, could we instead have_package_-target install its libraries into a shared directory, such as $(opam config var lib)/mirage-<target>/lib, and this would be added to -L/provided to mirage by some suitable package? I write "some suitable" deliberately as this is probably not ocaml-freestanding's job, but should instead be done by mirage-<target>, i.e. mirage-xen or `mirage-solo5.

Related to this:

Into details, flags provided by ocaml-freestanding is not very consistent where libmirage-solo5_bindings.a must be added into libs.sexp even if this static library is not a part of ocaml-freestanding (cc @mato). So I updated them to add libmirage-solo5_bindings.a, then dune.build with a specific rule copies the static library according the environment (OPAM environment or dune environment - the second is priority).

That's because libmirage-solo5_bindings.a comes from a pkg-config .pc file: https://github.com/mirage/mirage-solo5/blob/master/lib/bindings/mirage-solo5.pc which is then used by mirage as the actual package queried from pkg-config: https://github.com/mirage/mirage/blob/master/lib/mirage_link.ml#L8. mirage itself currently does not ask for ocaml-freestanding explicitly, only as a pkg-config requirement of mirage-solo5.

Could the solution I write about further above, using a single, shared target-specific directory for C libraries be made to work for mirage-solo5 also? How does dune determine the name of the C library it will link in? For a (OCaml? OPAM?) package foo, is it always lib<foo>.a?

A new tool was added into mirage: cc-to-opt or cc-to-ocamlopt which will takes C flags and do a translation of -L to -I and -l to -cclib -l. It wants to resolve static libraries and say that they exists according all given path by -L. Then, it re-order options due to the precedence of -L over -l (-LA -la -LB and -LA -LB -la don't have the same behavior if liba.a is available into A and B - this behavior is pretty-close to the GMP case where libgmp.a is available into several directories).

Three questions:

Do we need this tool at all? Couldn't ocaml-freestanding or mirage-solo5 generate the information required in a format already suitable for passing to ocamlopt?
Relying on directory precedence only in the presence of multiple libraries with the same name is incredibly fragile and will come back to bite us in the future. Can't we have one and one only specific search path per xen/freestanding/...?
If you are using ocamlopt to link instead of ld, does that mean you are no longer passing -nostdlib? That would be bad, see above. The unikernel must not accidentally link in host libraries.

The previous point want to serve an other issue about the expected flags used to compile C sources (like GMP or digestif). An unikernel for Solo5 which links with digestif.c (compiled to be used by an UNIX executable) can work. That means that silently, we can link with the wrong libdigestif.a and the unikernel still works.

Again, this seems like almost but not quite the same issue as above? Sorry if I'm repeating myself, but it's important. We need a way to ensure that the toolchain is using -nostdlib and an explicit target-specific list of search path(s) only. Is this not possible?

dinosaure · 2019-12-09T17:22:00Z

Link step

As @samoht asked, I delayed the resolution of static libraries compiled with specific flags according the target to mirage build (instead mirage configure). A command-line like:

$ opam install mirage && mirage configure -t hvt

Should works. However, make depends still is needed before a mirage build. Computation still uses cc-to-opt small pass to correctly be more predictable about which static libraries will be linked. However, this pass still be on top of what META files give to us.

A new file appears under the hood extra-libraries.sexp which is empty at the beginning and then was filled by pkg-config --static --libs %{target} and ocamlfind query -predicate native -format '%d %(%{target}_linkopts) to still be happy with the current status of the MirageOS eco-system.

In others words, pkg-config and ocamlfind still are needed.

A new flag was added (-noautolink) into the link command only for Solo5 and Xen target when ocamlopt must not follows -l flags given by *.cm{,x}a and takes them from META files. So from the old world (nocrypto, digestif.0.74 and checkseum.0.0.9), all works. I still need to figure out the new world however (specially about digestif and variants and others provided *.a).

Compatible with digestif.0.8.0/checkseum.0.9.0
Compatible with nocrypto

A clear limitation is that for any library which uses a C stub and do not get right information on META files, we will have a link error about some symbols due to -noautolink.

dinosaure · 2019-12-09T17:46:31Z

Instead of package providing a library lib_.a and mucking about with META files to force the linker to use the non-standard library name, package will provide lib.a in some target-specific location and something (possibly ocaml-freestanding, but see below) will provide information to mirage needed to set the linker's library search path to use only(!) libraries from the target-specific location(s).

Correct?

Correct at the beginning, not needed now because we use -noautolink. This is the way chosen before and ocamlopt with -output-complete-obj wants to follow flags given by *.cm{,x}a (like zarith.cmxa informs to put -lgmp at the link step).

Possible solution about that:

-noautolink as I showed in my previous comment
avoid the link by dune, I still continue to not fully understand the diff between -output-obj and -output-complete-obj and I suspect that the diff is probably the problem - and the main difference between dune and ocamlbuild.

Without pkg-config we lose the ability to compose -L search paths -- what you write above seems to require ocaml-freestanding to know about every possible package in order to be able to emit the -L$(opam config var lib)/. That does not scale, and is the biggest limitation of dropping pkg-config altogether.

-L flags if we look into details was currently given by 2 tools:

pkg-config for Solo5 stuff (but Xen too)
ocamlfind for libraries like nocrypto or digestif

About the current status of mirage, we still must have ocaml-freestanding for this purpose. My only update (even if it's little bit hard to follow) is to translate these information to some files (eg. mirage/ocaml-solo5#66) according the dune's format. The old part is available here: https://github.com/mirage/mirage/pull/1020/files#diff-34f96126d5975959270e9225bfd90fa0L29

Now, with dune I firstly moved that to the configure time and, from the request of @samoht, moved this step to the build time.

As an alternative, could we instead have_package_-target install its libraries into a shared directory, such as $(opam config var lib)/mirage-/lib, and this would be added to -L/provided to mirage by some suitable package? I write "some suitable" deliberately as this is probably not ocaml-freestanding's job, but should instead be done by mirage-, i.e. mirage-xen or `mirage-solo5.

I think, you describe in some words what is the current problem. layout of libraries with C stubs to be compatible with MirageOS is not documented. nocrypto has way and digestif has an other way. From this erratic eco-system, we currently want to move all of that to a dune's layout with variants - but still be compatible with old layout.

At the end, the story is only about how to correctly link an unikernel. But I will describe by through in another comment.

Do we need this tool at all? Couldn't ocaml-freestanding or mirage-solo5 generate the information required in a format already suitable for passing to ocamlopt?

We currently need this tool not only for ocaml-freestanding and mirage-solo5 but for libraries like nocrypto and digestif (or bigstringaf). So libraries outside the scope of MirageOS.

Relying on directory precedence only in the presence of multiple libraries with the same name is incredibly fragile and will come back to bite us in the future. Can't we have one and one only specific search path per xen/freestanding/...?

I completely agree with you but the diff between now and what is proposed in this PR is to fix it a bit with what we can have from the eco-system. dune gives an other way but we need to keep in our mind that some packages will not be updated to the dune's layout in a near future.

If you are using ocamlopt to link instead of ld, does that mean you are no longer passing -nostdlib? That would be bad, see above. The unikernel must not accidentally link in host libraries.

ld still is used at the final step for Solo5 and Xen target and we use -nostdlib 👍 . The linker is used by ocamlopt to produce a *.o because dune emits ocamlopt -output-complete-obj ....

dinosaure · 2019-12-09T18:04:48Z

Status of link step

So I just would like to clarify a non obvious situation about MirageOS.

Currently, most of problems highlighted by the dunification of MirageOS is about the linking step. This problem is currently fixed by several ways:

pkg-config
ocamlfind
the cmxa format

All of three can give to us information needed to correctly link libraries and C stubs/archives, etc. From what I know, the mostly popular way to get this information is ocamlfind with the META file but it does not fit correctly.

The cmxa format is the default way to get right C stubs/C archives, but it's possibly the wrong way (currently nocrypto.cmxa gives to us -lnocrypto_stubs by default, it's the same for zarith.cmxa).

pkg-config go further and can be more precise about what we needs to properly link our unikernel but we have some concerns about this tool (cc @hannesm).

And, on top of that, we want to move to the dune's variant layout.

Concerns about what `mirage` does not do

In any way, we decided to let this task to the build system (currently to ocamlbuild/ocamlfind) but I'm not sure that is the right direction to do. MirageOS has a so specific link step and, even if I reach a status when mirage-skeleton is happy with dune, the cost is huge and I'm sure because we clearly use dune to a non-conventional way.

So I start to think about a mirage link to take care about the link step by ourselves with a deal with ocamlopt only. As @mato said, this part is incredibly fragile.

Let's focus about the dunification

I'm not really happy with the status of https://github.com/mirage/mirage.git#clean-dunification-without-pkg-config but the underlying problem is not really about dune but about what the mirage should do on top of the build-system. But I will keep in my mind that and may be provide a better solution for all.

mato · 2019-12-10T10:39:22Z

I'm not really happy with the status of https://github.com/mirage/mirage.git#clean-dunification-without-pkg-config

Me neither.

but the underlying problem is not really about dune but about what the mirage should do on top of the build-system. But I will keep in my mind that and may be provide a better solution for all.

We should try and find a proper solution to the problem of "Mirage-compatible" packages, and we should do that now rather than later, since as far as I can tell the current state of the "dunification" just increases complexity and technical debt.

If we can replace pkg-config entirely and get other benefits such as a standardised way of building Mirage-compatible packages, we should consider such a solution "now" (with e.g. a "flag day" for the MirageOS release that includes it), even if that means breaking compatibility with existing packages. Conversely, if the tools (dune, ocamfind, ...) are not up to the task, we should also consider fixing the tools!

Given the complexity involved, the best way to progress on this would be to actually sit down together for a couple of days at a computer, possibly with some dune folks around, and figure it out. However, I don't see that happening this year, I already have too much on my plate with higher-priority work involving building systems that use MirageOS.

Any ideas on how to progress this? @avsm @samoht @hannesm @dinosaure

mato · 2019-12-10T12:21:22Z

Attaching today's discussion from Slack, so that we don't lose it.
slack-log.txt

dinosaure mentioned this pull request Dec 4, 2019

Use dune to build unikernels #979

Closed

dinosaure added 3 commits December 4, 2019 17:49

Add Mirage_impl_misc.sexp_of_fmt

f3f6406

Add Mirage_configure_unix

82c7ee6

This patch adds a way to configure the UNIX target where we define a dune's alias: dune build @default and an underlying rule to _generate_ the unikernel.

Add a cc-to-ocamlopt library

498a10f

This module is not mandatory but give us a way to link static libraries with the _unikernel_ into a more predictable way than before. This module tries to resolve static libraries and notice to the user (by logs) which libraries will be linked.

dinosaure force-pushed the clean-dunification branch from 1a6138a to 3d8efd4 Compare December 4, 2019 16:49

dinosaure added 11 commits December 4, 2019 18:35

Add some alias of modules into Mirage_configure_solo5

700aeb7

Emit dune's configuration for Xen target

753e1fa

As UNIX and Solo5 target, Xen can emit special dune's configuration.

Add some alias of modules into Mirage_configure_xen

52a0dab

Use configure_dune instead configure_myocamlbuild. DUNIFICATION!

6aca230

Externalize clean_dune* functions

f6026bc

See update into Mirage_clean and give a proper way to delete all generated files.

Clean generated dune files

a054558

Delete any link process

76e2a7e

The link process is defined into the `dune.build` file and the mirage tool does not need to take care about that when `dune build` will do the linking step.

Add Mirage_impl_misc.static_libs to retrieve static libraries

62f349f

This code try to retrieve static libraries (`*.a`) according the requested target and it uses `pkg-config`. This function is used by the configuration step to emit right link flags.

Redefine Mirage_build.compile to execute dune build

5b2c1bb

This patch wants to replace the call of `ocamlbuild` to `dune` with the requested target (see alias emitted by the configuration step).

dinosaure force-pushed the clean-dunification branch from 3d8efd4 to 5b2c1bb Compare December 4, 2019 17:35

dinosaure mentioned this pull request Dec 5, 2019

dunification of MirageOS without pkg-config #1021

Closed

Add forbidden_libraries for Solo5 and Xen target

59430a4

This was referenced Dec 10, 2019

Use Dune instead of OCamlbuild to build unikernels #969

Closed

Dunification of MirageOS #1024

Closed

dinosaure closed this Dec 17, 2019

TheLortex mentioned this pull request May 5, 2021

Use dune to build unikernels #1226

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

dunification of MirageOS #1020

dunification of MirageOS #1020

dinosaure commented Dec 4, 2019

samoht commented Dec 4, 2019

avsm commented Dec 4, 2019

dinosaure commented Dec 4, 2019

avsm commented Dec 4, 2019

dinosaure commented Dec 4, 2019 •

edited

Loading

avsm commented Dec 5, 2019

dinosaure commented Dec 5, 2019

dinosaure commented Dec 5, 2019 •

edited

Loading

dinosaure commented Dec 6, 2019

dinosaure commented Dec 6, 2019 •

edited

Loading

mato commented Dec 9, 2019

dinosaure commented Dec 9, 2019 •

edited

Loading

dinosaure commented Dec 9, 2019

dinosaure commented Dec 9, 2019

mato commented Dec 10, 2019

mato commented Dec 10, 2019

dunification of MirageOS #1020

dunification of MirageOS #1020

Conversation

dinosaure commented Dec 4, 2019

The Pull-Request

Issues on the eco-system

Zarith and GMP

Versatility of the linking

Correctness of C stubs linked

UNIX module and -dontlink

Issue on dune

(dirs ...)

flags needed by the target

Conclusion

samoht commented Dec 4, 2019

avsm commented Dec 4, 2019

dinosaure commented Dec 4, 2019

avsm commented Dec 4, 2019

dinosaure commented Dec 4, 2019 • edited Loading

avsm commented Dec 5, 2019

dinosaure commented Dec 5, 2019

dinosaure commented Dec 5, 2019 • edited Loading

dinosaure commented Dec 6, 2019

dinosaure commented Dec 6, 2019 • edited Loading

mato commented Dec 9, 2019

dinosaure commented Dec 9, 2019 • edited Loading

Link step

dinosaure commented Dec 9, 2019

dinosaure commented Dec 9, 2019

Status of link step

Concerns about what mirage does not do

Let's focus about the dunification

mato commented Dec 10, 2019

mato commented Dec 10, 2019

UNIX module and `-dontlink`

Issue on `dune`

dinosaure commented Dec 4, 2019 •

edited

Loading

dinosaure commented Dec 5, 2019 •

edited

Loading

dinosaure commented Dec 6, 2019 •

edited

Loading

dinosaure commented Dec 9, 2019 •

edited

Loading

Concerns about what `mirage` does not do