OCAML and Dynamic Libraries

["Alexander Bottema" <Alexander.Bottema@mathworks.com>]

[-- Attachment #1: Type: text/plain, Size: 2485 bytes --]

Hi all OCAML users,

 

Our group is considering using OCAML 3.08.3 (i.e. the currently latest
version) for a project on the MathWorks, but we have run into some
problems.

Currently, the platforms that we need to support are: Linux (I386),
Linux (AMD64), Windows 2000 (and XP), Solaris 2 and Mac OS X.

I've been able to successfully build and run OCAML on all platforms and
there are no problems in creating standalone executables (via ocamlopt)
on all mentioned platforms.

 

We need to create a dynamic link library (containing OCAML code) because
the execution context needs to share data on the same heap as the main
process (MATLAB in our case). I've been able to successfully do this for
Windows and Linux I386. I think that Solaris 2 should work as well,
although this is currently under investigation.

 

However, on the Linux AMD64 and Mac OS X platforms I consistently get
the following errors:

(Although this is not the actual steps for us, it produces the same
error):

 

Linux AMD64:

==========

 

ocamlopt -output-obj -o test_obj.o test.ml

ocamlmklib -o test test_obj.o

 

/usr/bin/ld: test_obj.o: relocation R_X86_64_32S against `caml_curry2_1'
can not be used when making a shared object; recompile with -fPIC

test_obj.o: could not read symbols: Bad value

collect2: ld returned 1 exit status

 

Mac OS X:

========

 

ld: test_obj.o has external relocation entries in non-writable section
(__TEXT,__text) for symbols:

_caml_call_gc

_caml_globals_inited

_caml_c_call

ld: test_obj.o has local relocation entries in non-writable section
(__TEXT,__text)

 

-----

 

The test.ml just contains:

print_string "Hello World\n";;

 

Although this is a meaningless DLL it shouldn't fail to build (and it
successfully builds on Linux I386 and Windows). I've been able to write
a program that calls ocaml_startup and get the right answer by calling a
registered ocaml function in such a DLL (successfully proven for Solaris
2, Linux I386, and Win32).

 

The questions are:

 

What's going on?

Is the OCAML compiler emitting some kind of object code that is not
recognized by the linkers on these two platforms? 

Can I easily fix this?

Have others have had the same experience?

If it is currently unsupported, will/when it be supported?

 

Thanks,

 

Alexander Bottema

Senior Software Developer

Embedded MATLAB, The MathWorks

 


[-- Attachment #2: Type: text/html, Size: 10236 bytes --]