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

ocaml-freestanding becomes a cross-compiler: take 2 #92

Closed
wants to merge 19 commits into from

Conversation

TheLortex
Copy link
Member

This PR replaces #90. The introduction of the PR is still relevant.

Thanks to @mato's work on solo5 (Solo5/solo5#494), we finally have a good and future-proof scheme for ocaml-freestanding. What happens is that for each solo5 toolchain, we will install an ocaml compiler distribution configured with that toolchain. For now, we only have one toolchain which is solo5-none-static.

From the toolchain name is derived a compiler and a linker to use: x86_64-solo5-none-static-cc and x86_64-solo5-none-static-ld which are used to build a freestanding libc/libm and a freestanding cross-compiler. The distribution is installed under the ocamlfind toolchain name freestanding.

This cross-compiler can then be used by ocaml projects to build solo5 unikernels. I've added an example/ folder to display the layout of such a project.
Warning: existing projects depending on ocaml-freestanding will be broken, because they will use the host compiler instead of ARCH-solo5-none-static-cc. These projects should be updated so that they use pkg-config --var=cc ocaml-freestanding to figure out the correct compiler to use.

Because of the lack of unix functions, libcamlrun.a is not built. So only native code compilation is supported. I've added CI to test it on 4.10, 4.11 and 4.12 ubuntu, and updated the cirrus CI for freebsd testing.

@TheLortex
Copy link
Member Author

I've added a new commit for the mirage 3 compatibility. Currently freestanding C stubs use pkg-config --cflags ocaml-freestanding to find the correct flags, but the new solo5 changes break this behavior as the C stubs should be built using the solo5 compiler toolchain.
So we have a choice to make:

  • modify all packages that currently build freestanding C stubs to use the solo5 compiler toolchain instead of the regular cc (bigstringaf, mirage-crypto, tcpip, ...) and cut patch releases to keep the mirage 3 compat
  • modify the flags exposed by pkg-config --cflags ocaml-freestanding to bring back the old behavior. This is what this additional commit does. It relies on solo5 installing a .pc file to describe its toolchain flags. This way, from a mirage 3 point of view, the transition to the new ocaml-freestanding is transparent.

@dinosaure
Copy link
Member

modify the flags exposed by pkg-config --cflags ocaml-freestanding to bring back the old behavior. This is what this additional commit does. It relies on solo5 installing a .pc file to describe its toolchain flags. This way, from a mirage 3 point of view, the transition to the new ocaml-freestanding is transparent.

Thanks for this update, as I said, both options are fine in the scope of the release of MirageOS 4 - even if the second one is better (because it's transparent). I hope, it's the last contentious piece between MirageOS 3 & MirageOS 4.

*  Installed as a findlib toolchain under the name `freestanding`. It
   can be queried using `ocamlfind -toolchain feestanding ocamlopt ...`
   or using dune build context features.
*  Installing ocaml-freestanding now installs:
   - compiler binaries in $PREFIX/freestanding-sysroot/bin/
   - compiler libraries, runtime and headers in $PREFIX/freestanding-sysroot/lib/ocaml/
   - solo5 libc/openlibm implementation in $PREFIX/freestanding-sysroot/lib/nolibc/
   - solo5 libc/openlibm headers in $PREFIX/freestanding-sysroot/include/nolibc/
   - freestanding toolchain definition in $PREFIX/lib/findlib.conf.d/freestanding.conf
   - backwards-compatible pkg-config file in $PREFIX/lib/pkgconfig/ocaml-freestanding.pc
@dinosaure
Copy link
Member

Rebased with master 👍.

@dinosaure dinosaure mentioned this pull request Sep 27, 2021
Makefile Show resolved Hide resolved
echo '#define HAS_SECURE_GETENV' >> ocaml/runtime/caml/s.h
echo '#define HAS_TIMES' >> ocaml/runtime/caml/s.h
echo 'SAK_CFLAGS=' >> ocaml/Makefile.config
echo 'SAK_LINK=cc $(SAK_CFLAGS) $$(OUTPUTEXE)$$(1) $$(2)' >> ocaml/Makefile.config
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why the SAK_ stuff changed here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmhmm that's true. Do you have any clues @TheLortex?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmhm, this update comes from my commit. If I remember correctly, SAK_CC is used to compile OCaml and used by default CC if this variable is defined. About SAK_CFLAGS, it's pretty the same, it uses CFLAGS/OC_FLAGS. These flags are correctly updated before and we should not redo what the OCaml's configure does.

Makefile Show resolved Hide resolved
Makefile Show resolved Hide resolved
Makefile Show resolved Hide resolved
Makefile Show resolved Hide resolved
README.md Show resolved Hide resolved
README.md Show resolved Hide resolved
README.md Show resolved Hide resolved
README.md Show resolved Hide resolved
README.md Show resolved Hide resolved
README.md Show resolved Hide resolved
install.sh Show resolved Hide resolved
install.sh Show resolved Hide resolved
install.sh Show resolved Hide resolved
install.sh Show resolved Hide resolved
install.sh Show resolved Hide resolved
test/dune Show resolved Hide resolved
uninstall.sh Show resolved Hide resolved
if [ "${BUILD_ARCH}" = "aarch64" ]; then
PKG_CONFIG_EXTRA_LIBS="$PKG_CONFIG_EXTRA_LIBS $(gcc -print-libgcc-file-name)" || exit 1
EXTRA_LIBS="$EXTRA_LIBS -lgcc" || exit 1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this change. but I assume you've tested this :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we discovered with @TheLortex that on aarch64, gcc emits some functions which used some internals only available by the fake library libgcc (which does not exists).

It's a bit strange but we must link to it via -lgcc. We should however look and document more precisely that indeed.

@hannesm hannesm mentioned this pull request Dec 30, 2021
@hannesm
Copy link
Member

hannesm commented Dec 30, 2021

I addressed most comments in #104 - remaning are SAK changes and arm64 libgcc. feel free to merge #104 here or continue there. This all looks fine to be merged and released.

@dinosaure
Copy link
Member

Close by #104

@dinosaure dinosaure closed this Jan 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants