Dynamic libs w/ Ocaml + C code under Mac OS X

Dynamic libs w/ Ocaml + C code under Mac OS X

[Joel Stanley]

Hi folks,

mfp from #ocaml suggested I send this off to the mailing list to see  
if anyone knows the answer.

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?  Alain Frisch's natdynlink info page at http://alain.frisch.fr/natdynlink.html 
  seems to indicate that I can, but I'm not currently having much luck.

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?

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).

However, even attempting to use what I'd consider to be the "correct"  
linker invocation, I'm getting errors of the form:

ld: atom sorting error for _caml_shared_startup__code_begin and  
_caml_shared_startup__code_end in test.startup.o
ld: atom sorting error for _caml_shared_startup__code_begin and  
_caml_shared_startup__code_end in test.startup.o
ld: atom sorting error for _caml_shared_startup__code_begin and  
_caml_shared_startup__code_end in test.startup.o
ld: atom sorting error for _caml_shared_startup__code_begin and  
_caml_shared_startup__code_end in test.startup.o
ld: warning codegen in _camlSimple__f_58 (offset 0x00000008) prevents  
image from loading in dyld shared cache
ld: warning codegen in _camlSimple__entry (offset 0x00000004) prevents  
image from loading in dyld shared cache
ld: warning codegen in _camlSimple__entry (offset 0x00000009) prevents  
image from loading in dyld shared cache
ld: warning codegen in _camlSimple__entry (offset 0x0000000F) prevents  
image from loading in dyld shared cache
ld: warning codegen in _camlSimple__entry (offset 0x00000014) prevents  
image from loading in dyld shared cache
ld: warning codegen in _camlSimple__entry (offset 0x0000001E) prevents  
image from loading in dyld shared cache
ld: absolute addressing (perhaps -mdynamic-no-pic) used in  
_camlSimple__f_58 from simple.o not allowed in slidable image
collect2: ld returned 1 exit status

which lead me to believe that simple.o is not correctly being  
generated with position independence.

Thanks for any help you may be able to provide.

--
Joel Stanley

Re: [Caml-list] Dynamic libs w/ Ocaml + C code under Mac OS X

[Alain Frisch]

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.

> 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?

> 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 ..."?

> 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.


-- Alain

Re: [Caml-list] Dynamic libs w/ Ocaml + C code under Mac OS X

[Joel Stanley]

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

Re: [Caml-list] Dynamic libs w/ Ocaml + C code under Mac OS X

[Alain Frisch]

Joel Stanley wrote:
> 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.

Then, you should rather try something like:

   ocamlopt -output-obj -o foo.so simple.ml wrapper.c

In the CVS version, -output-obj has been extended to allow producing 
directly "standalone" .so/.dll libraries that can be loaded from C (or 
anything else).

> The only real problem with the linker invocation above was the -I 
> switch, as the linker doesn't support it.

If we simply remove the -I switch, then everything is ok?

> Hmm, -read_only_relocs still looks supported in the man page for ld 
> under 10.5.

But does the linker really accept "-read_only_relocs suppress"?

http://developer.apple.com/releasenotes/DeveloperTools/RN-Id/index.html
seems to indicate the opposite.

> 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?

Yes, correct.

00 Akaub

Re: [Caml-list] Dynamic libs w/ Ocaml + C code under Mac OS X

[Joel Stanley]

On Feb 5, 2008, at 1:00 PM, Alain Frisch wrote:

> Joel Stanley wrote:
>> 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.
>
> Then, you should rather try something like:
>
>  ocamlopt -output-obj -o foo.so simple.ml wrapper.c
>
> In the CVS version, -output-obj has been extended to allow producing  
> directly "standalone" .so/.dll libraries that can be loaded from C  
> (or anything else).

Well, to try this out I have to get around the -I problem we talked  
about before, but after doing so (and manually assembling the startup  
code), I get the same error.

$ ocamlopt -dstartup -verbose -output-obj -o foo.so simple.ml wrapper.c
$ as -o foo.so.startup.o foo.so.startup.s
ld -bundle -flat_namespace -undefined suppress -read_only_relocs  
suppress -o 'foo.so'  '-L/Users/jstanley/hbin/lib/ocaml'  
'foo.so.startup.o' 'simple.o' '/Users/jstanley/hbin/lib/ocaml/ 
stdlib.a' 'wrapper.o' '/Users/jstanley/hbin/lib/ocaml/libasmrun.a'

 > ld: absolute addressing (perhaps -mdynamic-no-pic) used in  
_caml_startup__code_begin from foo.so.startup.o not allowed in  
slidable image for inferred architecture i386
>
>> The only real problem with the linker invocation above was the -I  
>> switch, as the linker doesn't support it.
>
> If we simply remove the -I switch, then everything is ok?

Sorry, I meant to say that the -I just makes the linker invocation ill- 
formed; it doesn't work better with a correctly-formed invocation.   
That is, I am still getting the same error about absolute addresses in  
the generated code.  Here's a pared down version of what I'm witnessing:

ocamlopt -dlcode -output-obj -c simple.ml
gcc -c wrapper.c -I ...
gcc -bundle -flat_namespace -undefined suppress -o blah wrapper.o  
simple.o
ld: absolute addressing (perhaps -mdynamic-no-pic) used in  
_caml_startup__code_begin from simple.o not allowed in slidable image

Where the _caml_startup__code_begin comes from the assembled  
camlstartup file generated by ocamlopt.

>> Hmm, -read_only_relocs still looks supported in the man page for ld  
>> under 10.5.
>
> But does the linker really accept "-read_only_relocs suppress"?
>
> http://developer.apple.com/releasenotes/DeveloperTools/RN-Id/ 
> index.html
> seems to indicate the opposite.

You're right.  I dug into this a bit more and asked some more  
knowledgeable Mac OS X developers; this wasn't even officially  
supported under 10.4, but it happened to work (albeit likely with  
undefined behavior); now it is defunct, as per the page you referenced.

>> 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?
>
> Yes, correct.

 From the experiments that I've been doing, it really looks like PIC  
needs to be generated for the OS X linker to be happy.  Do you have  
any assessment as to how much work this is?  Keep in mind that I don't  
consider myself an x86 assembly hacker by any stretch of the  
imagination ;)  I'd really like to just run this natively on my main  
platform, but if I can't, I can't.

Thanks,
Joel

--
Joel Stanley
jstanley@galois.com

Re: [Caml-list] Dynamic libs w/ Ocaml + C code under Mac OS X

[Alain Frisch]

Joel Stanley wrote:
> ld -bundle -flat_namespace -undefined suppress -read_only_relocs 
> suppress -o 'foo.so'  '-L/Users/jstanley/hbin/lib/ocaml' 
> 'foo.so.startup.o' 'simple.o' '/Users/jstanley/hbin/lib/ocaml/stdlib.a' 
> 'wrapper.o' '/Users/jstanley/hbin/lib/ocaml/libasmrun.a'
> 
>  > ld: absolute addressing (perhaps -mdynamic-no-pic) used in 

Ok, it makes sense. Now, if you replace ld with ld_classic, does it work?

>  From the experiments that I've been doing, it really looks like PIC 
> needs to be generated for the OS X linker to be happy.  Do you have any 
> assessment as to how much work this is?  Keep in mind that I don't 
> consider myself an x86 assembly hacker by any stretch of the imagination 
> ;)  I'd really like to just run this natively on my main platform, but 
> if I can't, I can't.

Honestly, I don't know how hard it would be. You can look at what had to 
be done for AMD64 
(http://camlcvs.inria.fr/cgi-bin/cvsweb/ocaml/asmcomp/amd64/) and at how 
one is supposed to produce PIC for x86 (gcc -fPIC).

Or you can try to convince Apple to restore "-read_only_relocs
suppress" in the new linker (I could find no indication that Apple 
deliberately dropped this feature).

-- Alain

Re: [Caml-list] Dynamic libs w/ Ocaml + C code under Mac OS X

[Joel Stanley]

On Feb 5, 2008, at 1:49 PM, Alain Frisch wrote:

> Joel Stanley wrote:
>> ld -bundle -flat_namespace -undefined suppress -read_only_relocs  
>> suppress -o 'foo.so'  '-L/Users/jstanley/hbin/lib/ocaml'  
>> 'foo.so.startup.o' 'simple.o' '/Users/jstanley/hbin/lib/ocaml/ 
>> stdlib.a' 'wrapper.o' '/Users/jstanley/hbin/lib/ocaml/libasmrun.a'
>> > ld: absolute addressing (perhaps -mdynamic-no-pic) used in
>
> Ok, it makes sense. Now, if you replace ld with ld_classic, does it  
> work?

Yes, yes it does, thanks!  I had actually deferred trying this because  
I wanted a solution that would be more suitable going forward.  As you  
pointed out, Apple may not have intended to drop the '- 
read_only_relocs suppress' option, but there's also no telling whether  
or not it'll end up being officially unsupported.

>> From the experiments that I've been doing, it really looks like PIC  
>> needs to be generated for the OS X linker to be happy.  Do you have  
>> any assessment as to how much work this is?  Keep in mind that I  
>> don't consider myself an x86 assembly hacker by any stretch of the  
>> imagination ;)  I'd really like to just run this natively on my  
>> main platform, but if I can't, I can't.
>
> Honestly, I don't know how hard it would be. You can look at what  
> had to be done for AMD64 (http://camlcvs.inria.fr/cgi-bin/cvsweb/ocaml/asmcomp/amd64/ 
> ) and at how one is supposed to produce PIC for x86 (gcc -fPIC).

Alright, I might take a crack at it.  Thanks again for your help.

Cheers,
Joel