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