Support OCaml 5.2 #134

It's probably a better way to add libraries when we link objects from OCaml. With these options, we allow the linker to resolve all symbols regardless the order of these libraries. Indeed, the linker will repeatly lookup on these libraries until all symbols are resolved. However, it seems that these options can have an impact about performances of the linker. If we need to improve this situation, we must recalculate a topological order of libraries. But for our purpose, that's probably fine. Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

`sed -i` is not POSIX, it's better to generate a `*.sed` file and move it to the real destination. Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

With OCaml 5, the pattern was updated and has $$PTHREAD_LIB. We update accordingly. Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

…efile Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

Currently, OCaml 5.0 wants to create 128 domains which requires a big allocation. We decided to allow the usage of only 1 domain. Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

…file) Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

Initially, we used NULL and it seems that these values are used by GMP. We probably break something here if NULL <> 0 but conventionally, NULL = 0. Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

As usual, we stub fputs, fopen and fclose which manipulate file description (and they don't exist with Solo5). However, puts and putchar use stdout and we decided to implement them (they will write _via_ Solo5 into stderr). Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

Note that these functions are not stubbed but they are just exported. They are probably not needed by the OCaml runtime but needed by the way to build OCaml. Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

Co-authored-by: Pierre Alain <[email protected]> Co-authored-by: Kate <[email protected]> Co-authored-by: Christiano Haesbaert <[email protected]>

…port) Co-authored-by: Pierre Alain <[email protected]>

`execv` is used in `header.c` which will not be used in native cross-compiler anyway

Use the builtin implementation of atomics of the compiler instead of a dummy one The compiler-provided `stdatomic.h` follows our constraints. Even if it is not explicitly listed in the freestanding headers: - clang still enables it with `-nostdlibinc` that the solo5 toolchain uses, - all gcc headers are brought into view anyway, - those headers respect `-ffreestanding` (ie they do not pull unwanted headers when `-ffreestanding` is enabled).

Remove the dependency from `nolibc.a` to a phony target that forces running `ar` on all builds The dependency to the test target is moved to `all`

- SYSDEP_OBJS is constant so move it to the relevant Makefile - MAKECONF_CFLAGS is always empty so remove it - Drop the variables concerning the build machine - Rename the variables concerning the target using TARGET (rather than BUILD) - Remove aspects that are to be moved to a new solo5-ocaml toolchain: - adding explicitly the libgcc for the aarch64 target - picking the exact version and options of commands

Use `${OPT#*=}` to remove only up to the first `=` (in case more than one appear in the argument)

Add a script to generate all the tools of a OCaml/Solo5 specific toolchain, using the `ARCH-solo5-ocaml-` tool prefix, in order to: - allow to have a clean way to point to the build directories in `-I` and `-L` options for nolibc and openlibm during the build, and to the installed directories after installation - build upon the toolchain autoconfiguration in OCaml's configure, so that it is not necessary to override each tool separately Add Makefile recipes to build the two variants of the toolchain, the one for build and the one to be installed Add a configure option to set up the tool prefix to use for the binutils that are not part of the Solo5 toolchain WIP: This creates wrappers for all the standard binutils, OCaml is using autoconf that detect most of them. This commit goes for consistency (covering them all) but maybe some are really not necessary.

Define openlibm's __BSD_VISIBLE and __XSI_VISIBLE to false when compiling C files openlibm headers use those macros to detect BSD and X/Open, but solo5 is neither When left undefined, compiling openlibm generates warnings when compiling OCaml (those warnings are turned into errors when compiling development versions of the compiler)

Disable Clang's unused-command-line-argument warning that triggers often as our toolchain is not smart enough to generate only useful arguments for each call

Following the introduction of the OCaml/Solo5 toolchain, clean up all the options used to build the libraries

Use OCaml's cross-compiler-aware versions of configure and make, which are able to detect the toolchain using only the configure `--target` argument Until this is available upstream, this is to be provided through local patches Reorganise Makefile targets so that `ocaml` is no longer both a directory and a phony target to build the compiler: - the `ocaml` target now creates the `ocaml` directory from either an `ocaml-src.tar.gz` archive or from the content of the `ocaml-src` OPAM package, and then applies patches found in `patches/<OCaml version>/` - an empty `_build/ocaml_is_built` file is used to record whether, and when, the compiler was built Accepting an archive for the OCaml sources makes it easy to use any (alpha, beta, ... or custom) version of the compiler, even if no `ocaml-src` package is available for it

The specific toolchain allow the proper detection of the math library

Instead of removing the `ocaml` directory, invoke the `clean` and `distclean` rules of the compiler's Makefile, to play nicer with work done in there

Update the dependencies of the `all` target to cover everything that needs to be installed Move it to the end, to use variables Create a `default` target to make sure `all` is still the default target

`ocaml` is no longer a phony target Follow the OCaml's usage of declaring `.PHONY`-ness of targets at the place those targets are defined, to make maintenance easier

Add two scripts to create an .install file: - `gen_ocaml_install.sh` drives (bends...) OCaml's `make install` in order to generate two subfiles, namely `_build/ocaml.install.lib{,exec}`, containing the lines to install the compiler itself, into the `lib` and `libexec` sections - `gen_dot_install.sh` generates the complete `.install` file, including the content of the subfiles for the compiler The generated `.install` file diverges from the current installation process in that it tries to follow the standard organisation of the OPAM directory: the OCaml cross-compiler is installed in `%{_:lib}%` (ie `%{prefix}%/lib/ocaml-solo5`) instead of `%{prefix}%/solo5-sysroot`. Note that the paths fed to `configure.sh` must be consistent with that for the installed compiler to work as expected.

In the standard use case, namely installation through OPAM, those targets are no longer necessary, since a `.install` file is generated so that OPAM does the installation itself Remove install.sh and uninstall.sh WIP: Should those targets be completely removed?

WIP Should the dependency be stricter? As ocaml.5.2.0 accepts ocaml-base-compiler.5.2.0~rc1, which would be rejected by the configure script (maybe the configure script is overly conservative)

Co-authored-by: Fabrice Buoro <[email protected]>

Rephrase the comments to catch up with the evolutions of `signal.h` Co-authored-by: Fabrice Buoro <[email protected]>

Follow a suggestion by Christiano Haesbaert, as Solo5 doesn't provide signals, it might just be ignored As of OCaml 5.2.0 beta1, `sigfillset` is only used in functions creating threads, and so that will abort in any case. Ignoring the function may make it more future-proof, though.

Make extra sure that, if `pthread_create` is called, the caller will know it failed

Since the main Makefile doesn't know the dependencies for the nolibc and openlibm libraries, create intermediate phony targets. That scheme ensures, even when one library already exists, that: - when building a target that depend on that library, a recursive make is invoked to check that it is up-to-date, - if the recursive make doesn't update the library, the dependency on the library is not a reason to rebuild the target.

WIP: Should the test of version compatibility be relaxed, for instance to accept any version 5.2.0...?

OCaml calls mmap with a non-null address and with the `MAP_FIXED` flag only on already reserved memory to commit or decommit that memory block, ie to set its protection to `PROT_READ|PROT_WRITE` or to `PROT_NONE`, in the `caml_mem_commit` and `caml_mem_decommit` functions So we accept this particular case without allocating memory that would leak since the OCaml code base simply ignores the returned value (as `MAP_FIXED` enforces the returned value to be either `addr` or `MAP_FAILED`) Accordingly, remove the man page extract that says that `addr` is just a hint since OCaml always sets `MAP_FIXED` when `addr` isn't null

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support OCaml 5.2 #134

Support OCaml 5.2 #134

Commits on May 31, 2024

Commits on Jul 19, 2024

Support OCaml 5.2 #134

Are you sure you want to change the base?

Support OCaml 5.2 #134

Commits on May 31, 2024

Commits on Jul 19, 2024