Description of problem: link failure due to wrong LTO version used in library Version-Release number of selected component (if applicable): Name : ocaml-ocamlnet-devel Version : 4.1.6 Release : 18.fc33.1 How reproducible: Build an OCAML program Steps to Reproduce: 1. 2. 3. Actual results: + dune build --release @install ocamlopt bin/gdfuse.exe (exit 2) (cd _build/default && /usr/bin/ocamlopt.opt -w -40 -w -3-27-58 -g -o bin/gdfuse.exe /usr/lib64/ocaml/unix.cmxa -I /usr/lib64/ocaml /usr/lib64/ocaml/threads/threads.cmxa -I /usr/lib64/ocaml /usr/lib64/ocaml/zarith/zarith.cmxa -I /usr/lib64/ocaml/zarith /usr/lib64/ocaml/cryptokit/cryptokit.cmxa -I /usr/lib64/ocaml/cryptokit /usr/lib64/ocaml/extlib/extLib.cmxa /usr/lib64/ocaml/bigarray.cmxa -I /usr/lib64/ocaml /usr/lib64/ocaml/netsys/netsys_oothr_mt.cmxa /usr/lib64/ocaml/netsys/netsys_oothr_mt_init.cmx /usr/lib64/ocaml/netsys/netsys.cmxa -I /usr/lib64/ocaml/netsys /usr/lib64/ocaml/str.cmxa -I /usr/lib64/ocaml /usr/lib64/ocaml/netstring/netstring.cmxa -I /usr/lib64/ocaml/netstring /usr/lib64/ocaml/curl/curl.cmxa -I /usr/lib64/ocaml/curl /usr/lib64/ocaml/easy-format/easy_format.cmxa /usr/lib64/ocaml/biniou/biniou.cmxa /usr/lib64/ocaml/yojson/yojson.cmxa /usr/lib64/ocaml/gapi-ocaml/gapi_ocaml.cmxa /usr/lib64/ocaml/com.cmxa -I /usr/lib64/ocaml /usr/lib64/ocaml/ocamlfuse/fuse.cmxa -I /usr/lib64/ocaml/ocamlfuse /usr/lib64/ocaml/sqlite3/sqlite3.cmxa -I /usr/lib64/ocaml/sqlite3 src/google_drive_ocamlfuse.cmxa bin/.gdfuse.eobjs/native/gdfuse.cmx) lto1: fatal error: bytecode stream in file '/usr/lib64/ocaml/netsys/libnetsys.a' generated with LTO version 9.0 instead of the expected 9.2 compilation terminated. lto-wrapper: fatal error: gcc returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status File "caml_startup", line 1: Error: Error during linking (exit code 1) Done: 147/151 (jobs: 1)error: Bad exit status from /var/tmp/rpm-tmp.yFAM03 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.yFAM03 (%build) Expected results: no linking error Additional info:
The problem here is there shouldn't be an LTO stream in any file shipped in an RPM. I've kicked off another build to see if this is reproducible.
$ eu-readelf -S /usr/lib64/ocaml/netsys/libnetsys.a | grep .gnu.lto shows lots of stuff, and it's my understanding that it should not show anything. This applies to both ocaml-ocamlnet-4.1.6-18.fc33.1 and ocaml-ocamlnet-4.1.6-18.fc34
Rebuilding in Rawhide did not help. I have disabled LTO in the build for now so hopefully that gets around the issue. Also upgraded to 4.1.8.
FEDORA-2021-33eeb46671 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-33eeb46671
The problem is resolved for me with the updated packages from: https://koji.fedoraproject.org/koji/buildinfo?buildID=1668656 I can build and use google-drive-ocamlfuse again for fedora 33, thanks!
I'm not completely certain that the problem is really resolved, since the .a file still has .gnu.lto_* sections. It may be that we have only "fixed" the LTO version incompatibility. However I don't know how/whether to remove the .gnu.lto sections.
Richard is right there should be no LTO sections/symbols in the installed .o/.a files and they should have been removed by brp-strip-lto. I'll dig into the build logs and see what I can find. Thanks,
This is because of the %global __strip /bin/true Which overrides the definition of "strip" used by brp-strip-lto and turns it into a NOP. I see similar overrides in cross-gcc, golang, nex, and supermin as well. I think the most sensible way forward here is to not allow "strip" to be overridden for brp-strip-lto. We're never supposed to allow LTO bytecodes in the distro, so from a policy standpoint it makes sense. It also still allows overriding "strip" in the other brp- scripts. Alternate approaches would be to have packages override "brp-strip" rather than "strip" which should work, but I think that's less desirable and more work.
I've opened a pull request to fix redhat-rpm-config to disallow overriding __strip for brp-strip-lto.
FEDORA-2021-33eeb46671 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-33eeb46671` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-33eeb46671 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Jeff Law from comment #8) > This is because of the > > %global __strip /bin/true > > > Which overrides the definition of "strip" used by brp-strip-lto and turns it > into a NOP. Ah, this is a leftover from olden times. Back in the day when we were (a) building OCaml bytecode packages and (b) OCaml used to append the bytecode to the end of the binary, we had to stop "strip" from deleting the bytecode. However none of this is true any more so we should remove these %globals. > I see similar overrides in cross-gcc, golang, nex, and supermin as well. I can only comment about ocaml-ocamlnet and supermin. I will remove the strip global from those now. No idea about the other packages you mention.
supermin fix: https://koji.fedoraproject.org/koji/buildinfo?buildID=1669287 ocaml-ocamlnet fix: https://koji.fedoraproject.org/koji/taskinfo?taskID=59688726
FEDORA-2021-6c2c191df2 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-6c2c191df2
FEDORA-2021-6c2c191df2 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-6c2c191df2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-6c2c191df2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-6c2c191df2 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.