Hi,
On Wed, Jul 12, 2023 at 09:54:49AM -0600, Jerry James wrote:
On Wed, Jul 12, 2023 at 4:38 AM Richard W.M. Jones rjones@redhat.com wrote:
During the OCaml 5 rebuild I found there's a generic problem on s390x & ppc64le (ie. the bytecode-only architectures) involving stripping of OCaml binaries. [...]
The binary is correct when built, but gets corrupted after one of these steps is applied (not sure which):
- /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
- /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
OK, that is later than I suspect. I believe these steps run after the debuginfo packages are created. And I don't know much about these steps, so if that is the case my advise might not be relevant.
Anyway this could potentially affect any s390x / ppc64le OCaml package that contains a binary so it's something to look out for ... For some reason dune doesn't seem to be affected.
[...] I encountered that with a couple of packages, ocaml-findlib and coccinelle. Sorry I missed the others. Yes, stripping those binaries removes the bytecode payload, leaving only the bytecode interpreter. I also noticed that dune isn't affected, which is interesting. I wonder if it is the difference between -output-complete-exe and -custom. Dune now uses the former instead of the latter.
It would be interesting to know what the difference between these methods is. Specifically if they create different names (or alloced/unalloced) ELF sections.
If the issue is with creating the debuginfo packages, then it likely is because there is an (unallocated) ELF section which is moved from the main executable to the .debug file (because debuginfo-find believes it isn't needed at runtime.
In that case, and you can find out how such sections are named, then you might be able to workaround it by adding someting like:
%define _find_debuginfo_opts --keep-section .special_ocaml_bytecode
Cheers,
Mark