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
[Caml-list] Problem with using oo in dynamically loaded bytecode ocaml runtime
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Gerd Stolpmann <info@g...>
Subject: Re: [Caml-list] Problem with using oo in dynamically loaded bytecode ocaml runtime
On 2002.01.27 02:35 Tomasz Zielonka wrote:
> Hi
> Situation: 
> I'm doing some integration of OCaml and PostgreSQL. PostgreSQL loads a
> DSO which implements so called "procedural language call handler". 
> I've built this DSO by ld-shared'ing libcamlrun.a with some additional C
> .o files, .o with wrappers for callback'ed ocaml funs, .o with new
> primitives and .o with ocaml bytecode. I also removed main.o from
> libcamlrun.
> I linked bytecode files into .o with following command:
>   ocamlc -g -custom -output-obj -o plocamlb_bytecode.o plocamlb_spi.cmo \
>   plocamlb_mlfuns.cmo
> Problem: Everything worked fine until I wanted to define a class.

I did this kind of linking, too, but I did not have any problems. (I am
not loading into Postgresql, but into a Perl interpreter, but I think
this does not make any difference.) I have used -output-obj for a long
time, but recently (with the availability of O'Caml 3.04) I switched
to loading the bytecode directly. The debug sections are not lost, 
and the Dynlink library works.

I can quickly describe what I am doing:

- build by compiling the code in the "byterun"
  directory with -fPIC, and linking everything with ld -shared
  (but not main.o)

- build some special libraries as DSOs. With O'Caml 3.04, you
  can load them dynamically. 

- build This is the entry point, i.e. the Perl interpreter
  does ldopen(""), and it depends on some libraries:, and the libraries of the embedding application
  so their symbols are visible here.

  The entry point creates the argv array, and puts into argv[0] the
  absolute path of the bytecode file. (argv[1] is NULL.) Finally,
  I am calling caml_main(argv). This will load the bytecode file,
  and start executing it.

  In O'Caml I only initialize everything, and register a lot of
  callbacks, so that caml_main will quickly return to its caller.

- Compiling the ocaml part is tricky:
  * Create a bytecode executable
  * Name all required libraries
  ==> ocamlc -o bytecode lib1.cma lib2.cma ... main.cma

  This will fail, because ocamlc looks up all primitives of the
  libraries, but the symbols of the embedding application are missing!
  (IMHO, there should be a command-line switch for ocamlc turning
  this off.) As a workaround, I create a fake library
  containing all missing symbols, and I call ocamlc this way: ocamlc ...

> When I define a class with _no methods_, it works, but there is little
> use of such class.
> When I define any method in this class (but still don't use a single
> instance of the class) it stops working. After loading the DSO, ocaml
> raises Not_found exception and quits.
> I wanted to use CAMLRUNPARAM b (stack backtrace) option, but apparently
> it doesn't work with such a library/DSO (Program not linked with -g,
> cannot print stack backtrace).
> I couldn't force ocamlc to keep DBUG section. I'm not sure it would
> help, because read_debug_info tries to open executable file, not the
> loaded DSO. I tried several caml_main_param[0] (different files), no
> luck.
> When I make native/opt library _and_ define a method, I get corrupted
> memory in the postgresql backend.

The generated code is not PIC, so it won't work.
> So:
> 1) There is a bug, but where? In my program, in OCaml?

It is more likely that the bug is in your program.

> 2) How to get stack backtrace in this situation?

See my method. Stack backtraces work, even the debugger works if
you name the socket explicitly.

Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:
Bug reports:  FAQ:
To unsubscribe, mail  Archives: