Bug 1516556
| Summary: | ocaml-tplib fails to build from source with OCaml 4.06 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Richard W.M. Jones <rjones> |
| Component: | ocaml-tplib | Assignee: | Jerry James <loganjerry> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 28 | CC: | c.david86, gemi, loganjerry, rjones |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-11-02 20:24:45 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Richard W.M. Jones
2017-11-22 22:31:09 UTC
Please note that you won't be able to build this in Rawhide until https://pagure.io/releng/issue/7143 is closed. The problem is that the configure test for libasmrun is now failing. I see this is config.log on an x86_64 box:
configure:4690: checking for caml_startup in -lasmrun
configure:4715: gcc -o conftest -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -I/usr/lib64/ocaml -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld conftest.c -lasmrun conftest_ml.o -L/usr/lib64/ocaml -lm -ldl >&5
/usr/bin/ld: /usr/lib64/ocaml/libasmrun.a(startup.o): relocation R_X86_64_32S against symbol `caml_data_segments' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib64/ocaml/libasmrun.a(roots.o): relocation R_X86_64_32 against symbol `caml_frametable' can not be used when making a shared object; recompile with -fPIC
...
This leads to HAVE_BINDINGS being set to false, and the stupid Makefile assumes that it is true. Can we get libasmrun recompiled with -fPIC, or is there some reason why that is a bad idea?
I checked ocaml 4.04.0 in Fedora 26, and libasmrun was built with -fPIC in that version. However, ocamlbuild appears to need a rebuild:
+ ocamlfind ocamlopt unix.cmxa -I /usr/lib64/ocaml/ocamlbuild /usr/lib64/ocaml/ocamlbuild/ocamlbuildlib.cmxa -g -linkpkg myocamlbuild.ml /usr/lib64/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild
File "myocamlbuild.ml", line 1:
Error: Files /usr/lib64/ocaml/ocamlbuild/ocamlbuildlib.cmxa
and /usr/lib64/ocaml/unix.cmxa
make inconsistent assumptions over implementation Unix
Command exited with code 2.
make: *** [Makefile:133: ocaml-all] Error 10
Reassigning this to ocaml. If a PIC libasmrun is wrong or infeasible, then please assign back to ocaml-tplib and I'll see if I can work around the issue.
Oh, heck, I just noticed that there are now separate libasmrun.a and libasmrun_pic.a files. Assigning back to ocaml-tplib.... There are various reasons why libasmrun is not compiled with -fPIC, mainly down to speed/efficiency. However you can link to -lasmrun_pic which is the PIC version, and there are other runtimes too: -rw-r--r--. 1 root root 449428 Nov 7 18:09 /usr/lib64/ocaml/libasmrun.a -rw-r--r--. 1 root root 480924 Nov 7 18:09 /usr/lib64/ocaml/libasmrunp.a -rw-r--r--. 1 root root 449788 Nov 7 18:09 /usr/lib64/ocaml/libasmrun_pic.a -rwxr-xr-x. 1 root root 240736 Nov 7 18:09 /usr/lib64/ocaml/libasmrun_shared.so Use ‘ocamlopt -runtime-variant _pic’ to use the PIC version. Actually making the tplib Makefile pick up the right version might be difficult, but probably adding ‘-runtime-variant _pic’ to every invocation should fix it. Okay, I think I've got it fixed in Rawhide. I also built a newer version of ocaml-mlgmpidl to bring back the cmxs, which this package, apron, and frama-c all seem to need. That's kind of weird, considering that upstream hasn't supported building a cmxs until this newest version... This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'. I don't know why this is in the release pending state. Closing, as it was fixed long ago. |