On Feb 4, 2008, at 8:52 PM, Alain Frisch wrote:

> Hi,
>
> Joel Stanley wrote:
>> The short question is: can I currently generate a shared library  
>> containing natively-compiled ocaml code together with arbitrary C  
>> code under Mac OS X?
>
> I'll reply assuming you want to build a plugin that can be loaded  
> with Dynlink, not a stand-alone shared library that includes the  
> OCaml runtime. Otherwise let me know.

Actually, I do want a stand-alone shared library that includes the  
OCaml runtime, but I don't think that changes the parameters of the  
problem much.  Basically, I have an OCaml application that I'd like to  
wrap up (together with some C glue code) into a shared library for use  
by other applications.

In particular, I think I need shared library versions (bundles or  
dylibs) for things like libasmrun.a, etc., so that I can link against  
them properly, which means all of that code (including asmrun/i386.S)  
must be able to be compiled and/or linked in  a position-independent  
fashion.

>> To wit, should I be doing something other than:
>> $ gcc -c wrapper.c
>> $ ocamlopt -dlcode -c simple.ml
>> ...
>> $ ocamlopt -shared -o test simple.cmx wrapper.o
>> or perhaps just ocamlopt -shared -o test simple.ml wrapper.c?
>
> Both should work under Mac OS X < 10.5 on Intel. PowerPC versions  
> are not supported and for 10.5, there are some issues (see below).  
> What are your OS version and cpu?

10.5, Intel.
>
>> The immediate problem is that this seems to be passing the wrong  
>> arguments to ld:
>> + ld -bundle -flat_namespace -undefined suppress -read_only_relocs  
>> suppress -o 'test'  -I'/Users/jstanley/hbin/lib/ocaml' '-L/Users/ 
>> jstanley/hbin/lib/ocaml' 'test.startup.o' 'simple.o' 'wrapper.o'
>> (I'd expect to see gcc -dynamiclib (instead of bundle) here if Mac  
>> OS X is supported, and without the -I switch).
>
> I'm not very familiar with the linker of Mac OS X. In particular, I  
> don't really know the differences between bundles and shared  
> libraries.
> OCaml used to produce bundles (not shared libs) for stub libraries  
> (dll*.so), and I think I just decided to use the same approach.
>
> What's wrong with the above linker invocation? Do the errors you  
> mention appear with it, or only if you change the command-line to  
> "gcc -dynamiclib ..."?

The only real problem with the linker invocation above was the -I  
switch, as the linker doesn't support it.  Bundle is actually the  
expected switch here, I was getting the two confused (dylibs can't be  
unloaded IIRC).  I'm getting the errors regardless of whether -bundle  
or -dynamiclib is supplied.

>> which lead me to believe that simple.o is not correctly being  
>> generated with position independence.
>
> Indeed. The code generators don't produce PIC code. The Mac OS X  
> linker is supposed to be able to build bundle with position- 
> dependent code, using the -read_only_relocs suppress flag. This flag  
> has been removed from the new linker in Leopard. Apple provides a  
> ld_classic with the old behavior, but unfortunately, some libraries  
> (like X11) seems to require the new linker. I think we have no good  
> solution for Mac OS X 10.5 on Intel currently. Any help is welcome,  
> of course.

Hmm, -read_only_relocs still looks supported in the man page for ld  
under 10.5.  The description is "enables the use of relocations which  
will cuase dyld to modify (copy-on-write) read-only pages.  The  
compiler will normally never generate such code."  Does that sound  
like it's still the right switch?

Anyone have any ideas as to how I could remedy the situation?  At this  
point it looks like I might have to switch the platform the  
application I'm working on is used with, due to this linking problem  
alone.  There shouldn't be a need for the code generators to produce  
PIC as long as the linker does the right thing, correct?

Thanks for the help,
Joel