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@xxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue