Skip to content

Attempt to guess correct libdir from current exe#3

Closed
ElectreAAS wants to merge 4 commits intodra27:relocatablefrom
ElectreAAS:relocatable
Closed

Attempt to guess correct libdir from current exe#3
ElectreAAS wants to merge 4 commits intodra27:relocatablefrom
ElectreAAS:relocatable

Conversation

@ElectreAAS
Copy link
Copy Markdown

This PR aims to merge the changes that have been made on Steve's repo (and which are linked to by dune's overlay repo), and the relocatable changes made on this repo.

More context can be found here: ocaml/dune#13467

Pulling as draft as I'm not totally sure the issue is fixed

dra27 and others added 4 commits March 9, 2025 16:28
Makefile.config contains copies of PREFIX, BINDIR, LIBDIR and MANDIR
from OCaml's Makefile.config. These values were not actually being used,
and they become much less reliable with Relocatable OCaml. They've
therefore been removed.

OCAML_LIBDIR was previously a copy of LIBDIR from OCaml's
Makefile.config. However, this file is found by running `ocamlc -where`,
which itself _gives_ the value for OCAML_LIBDIR. For Relocatable OCaml,
`ocamlc -where` is guaranteed to be correct, where the LIBDIR value may
not be, so tweak the generation of Makefile.config to use this value
instead.
In configure.make, specifying a path beginning ./ or ../ or
OCAMLBUILD_LIBDIR enabled Relocatable ocamlbuild, as long as the
ocamlbuild binary is being installed in the same directory as the
compiler and the compiler itself is Relocatable OCaml. The relative path
given for OCAMLBUILD_LIBDIR describes how to get from OCaml's Standard
Library to the directory containing the "ocamlbuild" package directory
(in opam, this is just "..").

In this mode, `ocamlbuild -where` is determined relative to the Standard
Library.
In cases where the libdir computed by `ocamlbuild -where` doesn't
contain the expected ocamlbuild library files, attempt to guess an
alternative libdir relative to the currently running executable's path
(using `Sys.executable_name`). If the resulting libdir does contain the
expected ocamlbuild library files then a warning is printed and the
guessed libdir is used.

The motivation for this change is to allow the ocamlbuild (opam) package
to be built by dune's package management features. Dune builds opam
packages by executing their build and install commands in a temporary
sandbox environment, and then copying the resulting artifacts to a final
installation path. This creates a problem for ocamlbuild as the
`OCAMLBUILD_LIBDIR` variable set at build time will be a path inside the
temporary sandbox. That path is then used to compute the value printed
by `ocamlbuild -where` which consequently reports a non-existant path.

Signed-off-by: Stephen Sherratt <stephen@sherra.tt>
@ElectreAAS
Copy link
Copy Markdown
Author

ElectreAAS commented Feb 24, 2026

I've run exhaustive experiments on the 464 packages that depend on ocamlbuild, here are the details:

I've run this fish script to try and sort out how many packages can be built with dune package management with the appropriate relocatable patches.

Out of the 464 packages

  • 5 fail to lock entirely (joolog riak riak-pb starterkit statmemprof-emacs)
  • 208 build with David's patches but don't with the added patches of this PR
  • Every other package (251) builds (or fails¹) the same with either patches.

That doesn't look good, but if instead of using stock dune.3.21.1, I use Ali's relocatable branch, the results are very different:

  • The same 5 still fail to lock
  • 1 singular package (bisect_ppx) that did not build with David's patches now builds correctly
  • Every other package (458) builds (or fails¹) the same with either patches.

All in all this means that this PR should not be merged before Ali's relocatable patches on dune land in main, but after that they should help a bit.

1: I did not record how many packages failed to buil in both scenarios, just the difference in build outcomes

@ElectreAAS
Copy link
Copy Markdown
Author

Tried to reproduce it, and bisect_ppx built fine either way, so the error was transient (probably the one linked above).

The takeaways from all this are the following:

  • This repo's patches are enough to build almost everything on their own, the added changes in this PR are not necessary (hence I'm closing it)
  • Ali's patches on his relocatable branch are orthogonal to this, and help only with the compiler, not ocamlbuild
  • there's a lot of packages that depend on ocamlbuild, wow!

Cheers :)

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.

4 participants