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
-fPIC error with x86_64 #4795
Comments
Comment author: zinid The bug still exists even if compile libasmrun with -fPIC flag set: $ ./configure -cc "gcc -fPIC" -aspp "gcc -fPIC -c" $ /home/xram/ocaml/bin/ocamlopt -output-obj -o lib.so lib.ml It seems like asmrun/amd64.S doesn't produce position-independent code. |
Comment author: paul_stravers I have uploaded amd64-pic.S which is a drop-in replacement for amd64.S. The new assembly file creates position independent code if you define the macro EMIT_PIC=1. With EMIT_PIC=0 it behaves exactly like the stock amd64.S that comes with ocaml-3.11.1. So there is no need for Xavier to worry about performance. Only if you actually need PIC you take the performance hit. |
Comment author: @xavierleroy Thanks for the replacement amd64.S. Much appreciated. You're definitely on the right track, but I noticed a potential If you have ideas, please do let me know; otherwise, I'll try to |
Comment author: paul_stravers I addressed the %r11 issue in the amd64-pic.v2.S that I just attached to this issue. I tried this new amd64.S (EMIT_PIC=1) by regressing through some 120,000 lines of ocaml code that I have here, and regression passes. Actually, it also passed yesterday when register %r11 was still clobbered on some occasions, I guess I was lucky then ... |
Comment author: @xavierleroy Thanks for the second version of the patch. I merged it in the development sources, to be released as 3.12.0. I made a tiny simplification in caml_allocN, and also used "#if PIC" instead of "#if EMIT_PIC", so that assembling with "gcc -c -fPIC" selects the PIC version. Let me know if you see a problem with that. |
Comment author: @alainfrisch I still cannot succeed to link code generated by ocamlopt in a shared library under Linux x86_64. I'm using the amd64.S from the trunk (after looking at #4795) and take care to compile everything with -fPIC. I get this error: /usr/bin/ld: /home/afrisch/branches/v4/mlfi/mlfi-ins/lib/libasmrun.a(amd64.o): relocation R_X86_64_PC32 against symbol `caml_alloc1' can not be used when making a shared object; recompile with -fPIC Any help will be appreciated! |
Comment author: @xavierleroy To my surprise, the assembler does not resolve a "jmp" to a global symbol defined in the same file, leaving an absolute reference to the symbol instead of putting a relative displacement :-( One learns something new every day. I just commited a fix to asmrun/amd64.S. The relocs look good and gcc -shared no longer complains. |
Original bug ID: 4795
Reporter: paolo
Assigned to: @xavierleroy
Status: closed (set by @xavierleroy on 2011-05-29T10:19:51Z)
Resolution: fixed
Priority: normal
Severity: major
Version: 3.11.0
Fixed in version: 3.12.0+dev
Category: ~DO NOT USE (was: OCaml general)
Monitored by: edvald mwvh mfp zinid paul_stravers jm zack
Bug description
ocamlc and ocamlopt fail to compile to dynamic libraries on linux x86_64.
Reproducible as follows:
$ echo "let x = 5" > lib.ml
$ ocamlc -output-obj -o lib.so lib.ml
/usr/bin/ld: /usr/lib/ocaml/libcamlrun.a(stacks.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/lib/ocaml/libcamlrun.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
File "lib.ml", line 1, characters 0-1:
Error: Error while building custom runtime system
File attachments
The text was updated successfully, but these errors were encountered: