Re: [Caml-list] undefined symbol `caml_tuplify2' in dynamic rocaml extension

[Mauricio Fernandez <mfp@acm.org>]

On Wed, Aug 01, 2007 at 09:44:22AM +0200, Julien Moutinho wrote:
> On Tue, Jul 31, 2007 at 09:01:02PM -0700, Jos Backus wrote:
> > Hi. I'm trying to use rocaml to wrap an Ocaml library so it can be accessed
> > from a dynamic Ruby extension (using Callback.register). Everything works,
> > except when I try to access the Ocaml type from Ruby the following Ruby
> > LoadError is emitted:
> > 
> >     undefined symbol: caml_tuplify2
> > 
> > So my question is: what do I need to do in order to satisfy this symbol? It
> > doesn't appear in any library. ocaml version is 3.09.2.
> 
> AFAICS, when needed, caml_tuplifyN end up within the /tmp/camlstartup*.s file
> mechanically generated at link time.
> You can keep this file with -dstartup.
> 
> Unfortunately, due to its quasi-random name,
> it is not easy to retrieve it mechanically.
> 
> Personally I have patched ocamlopt in order to have a -startup option
> keeping camlstartup_<name_of_the_output>.o in the current directory.
> 
> Anyway, maybe there is a better way for your own concern.
> Have a glance at -output-obj perhaps.

rocaml already uses -output-obj; these are the steps it follows when building an
extension:

gcc -I. -Ipath/to/lib/ruby/1.8/i686-linux -I.  -fPIC -g -O2  -c oo_rocaml_wrapper.c
ocamlopt.opt -c   oo.ml
ocamlopt.opt -c   rubyOCamlUtil.ml
ocamlopt.opt  -output-obj -o oo_rocaml_runtime.o nums.cmxa oo.cmx \ 
              rubyOCamlUtil.cmx oo.o rubyOCamlUtil.o 
gcc -shared  -L'path/to/usr/lib' -Wl,-R'path/to/usr/lib' -o oo.so \
  oo_rocaml_wrapper.o oo_rocaml_runtime.o /usr/lib/ocaml/3.09.2/libasmrun.a \
  /usr/lib/ocaml/3.09.2/libunix.a /usr/lib/ocaml/3.09.2/libnums.a \
  -ldl -lcrypt -lm   -lc

oo_rocaml_wrapper.c and rubyOCamlUtil.ml are generated by rocaml, the actual
OCaml code is in oo.ml.

Under which circumstances would something like the above oo.so not be
self-contained as far as the OCaml code is concerned?

PS: I realize that the above only works as is on x86, Linux + Windows (maybe
elsewhere), but will fail on x86_64, whose linker cannot handle non-PIC code.
This is described in http://caml.inria.fr/mantis/view.php?id=3924
I believed it was fixed in 3.10 since the changelog indicates:
  - Intel/AMD 64 bits: generate position-independent code by default.
but I've had no success with 3.10 and -fPIC (I have to try again though, I
just realized that this could refer only to (2) in the bug report).

-- 
Mauricio Fernandez  -   http://eigenclass.org