Browse thread
undefined symbol `caml_tuplify2' in dynamic rocaml extension
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Gordon Henriksen <gordonhenriksen@m...> |
| Subject: | Re: [Caml-list] undefined symbol `caml_tuplify2' in dynamic rocaml extension |
On Aug 1, 2007, at 03:44, 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. > > HTH. I wonder if there's a reason ocamlopt doesn't simply emit these glue functions alongside their uses as linkonce symbols. This is the same technique that a C++ compiler uses for template instantiations to avoid problems of this nature. — Gordon