Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pic version of libasmrun not used #7595

Closed
vicuna opened this issue Jul 21, 2017 · 9 comments
Closed

pic version of libasmrun not used #7595

vicuna opened this issue Jul 21, 2017 · 9 comments

Comments

@vicuna
Copy link

vicuna commented Jul 21, 2017

Original bug ID: 7595
Reporter: olh
Status: resolved (set by @xavierleroy on 2017-10-24T07:54:18Z)
Resolution: unable to duplicate
Priority: normal
Severity: minor
Platform: Linux
OS: Tumbleweed
OS Version: rolling
Version: 4.03.0
Category: runtime system and C interface
Monitored by: @gasche

Bug description

As a followup to a discussion on the caml-list@inria.fr on 2017-05-31 I was asked to enter this feature request:

openSUSE Tumbleweed switched to gcc7, with the result that most ocaml related packages fail to build. The reason is that libasmrun.a instead of libasmrun_pic.a is used during linking:

ocamlfind ocamlopt unix.cmxa -I /usr/lib64/ocaml/ocamlbuild /usr/lib64/ocaml/ocamlbuild/ocamlbuildlib.cmxa -linkpkg myocamlbuild.ml /usr/lib64/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild

/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/ocaml/libasmrun.a(startup_aux.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC

Per the discussion there is apparently a knob 'runtime_variant(_pic)' for ocamlbuild. To my understanding this would need to be done for each package.

The workaround is to replace %{_libdir}/ocaml/libasmrun.a with libasmrun_pic.a to have this system-wide fixed.

It would be nice if there is a configure option to automatically select the "_pic" variant, unless otherwise specified by the project/package.

@vicuna
Copy link
Author

vicuna commented Oct 17, 2017

Comment author: @xavierleroy

I was finally able to investigate this issue in more details.

GCC 7 defaults to PIE mode (position-independent executables), unlike earlier versions of GCC. On some 32-bit ports of OCaml this causes problems because ocamlopt-generated code is not compatible with PIE.

However, OCaml for x86_64 is PIE-compatible to the best of my knowledge. Indeed it builds just fine with GCC 7 under Ubuntu 17-04, using Ubuntu's PPA to get GCC 7. The version is:
gcc-7 (Ubuntu 7-20170407-0ubuntu2) 7.0.1 20170407 (experimental) [trunk revision 246759]
I tried both the forthcoming 4.06 version of OCaml and the rather old 4.03 version mentioned in the bug report.

Since PIE is a subset of PIC, using a PIC version of libasmrun can help improve PIE compatibility. But this is the wrong answer to the question of understanding why libasmrun.a is not PIE-compatible at @olh's installation. Could it be that you have an old version of libasmrun.a lying around, which was compiled with GCC 6 in non-PIE mode?

@vicuna
Copy link
Author

vicuna commented Oct 17, 2017

Comment author: @xavierleroy

PS. The "scanelf" utility can help locate non-PIE libraries and executables, those that contain "text relocations"; see https://wiki.gentoo.org/wiki/Hardened/PaX_Utilities

@vicuna
Copy link
Author

vicuna commented Oct 19, 2017

Comment author: olh

All packages in the "openSUSE Build Service" are always consistent. Since the package "ocaml" was built successfully with gcc7, all files are built with gcc7.

@vicuna
Copy link
Author

vicuna commented Oct 19, 2017

Comment author: olh

I will see if I can reproduce it with the "4.06" branch in my dedicated ocaml-4.06 project.

@vicuna
Copy link
Author

vicuna commented Oct 19, 2017

Comment author: @xavierleroy

Thanks for the info, and let us know how it goes with 4.06.

In the meantime I could test 4.06 with Ubuntu 17.10 x86_64 and Fedora 26 x86_64. Both use GCC 7.2, Ubuntu has PIE by default, Fedora doesn't. Both builds went fine. So, I really think that GCC 7 is not the problem and that PIE on x86_64 is not the problem either.

@vicuna
Copy link
Author

vicuna commented Oct 20, 2017

Comment author: olh

Since 4.06 has very little coverage at this point, I reverted the relevant change in the project based on ocaml-4.05. There was not a single error. I will configure 4.04 and 4.03 based projects to see if it was eventually fixes after 4.03. It may have been a temporary toolchain flaw.

@vicuna
Copy link
Author

vicuna commented Oct 23, 2017

Comment author: olh

Using the ocaml.git#4.04 branch gives also no errors. For some reason the 4.03-based project does not behave, I will see how to fix it during this week.

@vicuna
Copy link
Author

vicuna commented Oct 24, 2017

Comment author: olh

And even with 4.03 there are no errors anymore. So I think it was a temporary issue with the toolchain.

@vicuna
Copy link
Author

vicuna commented Oct 24, 2017

Comment author: @xavierleroy

Thank you for having double-checked the issue. I'll mark it as resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant