Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Compiling a shared library with amd64
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-07-23 (08:24)
From: Alain Frisch <alain@f...>
Subject: Re: [Caml-list] Compiling a shared library with amd64
Jonathan Marchand wrote:
> I got rid of the complains with 3.10.2 version (for libasmrun.a only).
> In the CVS version, if I compile by adding -fPIC in *COMOPTS, I  still
> have some errors with libasmrun.a:
> Here is the complete build trace for rocaml (I use it as an exemple as
> it the same problem with the library I'm making and it is freely
> available):
> cc -I. -I/usr/lib/ruby/1.8/x86_64-linux
> -I/usr/lib/ruby/1.8/x86_64-linux -I.   -fPIC -fno-strict-aliasing -g
> -g -O2  -fPIC   -c foo_rocaml_wrapper.c
> ocamlc -c -I +camlp4 -pp "camlp4orf -loc _loc"
> ocamlopt.opt -c -pp 'camlp4o -I . pa_rocaml.cmo'
> ocamlopt.opt  -output-obj -o foo_rocaml_runtime.o nums.cmxa
> rubyOCamlUtil.cmx rubyOCamlUtil.o
> cc -shared -o foo_rocaml_wrapper.o -L. -L/usr/lib -L.
> -rdynamic -Wl,-export-dynamic   foo_rocaml_runtime.o
> /usr/local/lib/ocaml/libasmrun.a /usr/local/lib/ocaml/libunix.a
> /usr/local/lib/ocaml/libnums.a -lruby1.8  -lpthread -ldl -lcrypt -lm
> -lc
> /usr/bin/ld: /usr/local/lib/ocaml/libasmrun.a(amd64.o): relocation
> R_X86_64_PC32 against `caml_last_return_address' can not be used when
> making a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
> make: *** [] Erreur 1
> I don't know how to compile every libraries with -fPIC. I tried to add
> more or less randomly the -fPIC flag in the Makefiles, but they are a
> bit obscure to me.
> The best I achieved is printed above.

Now the error is in code written directly in assembler (asmrun/amd64.S).
Unfortunately, I don't think there is an easy solution here: this code 
should be adapted to be position-independent.

-- Alain