From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 8DD74BC6C for ; Tue, 5 Feb 2008 22:20:18 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEhiqEdFHnvD/2dsb2JhbACteQ X-IronPort-AV: E=Sophos;i="4.25,309,1199660400"; d="scan'208";a="7656660" Received: from galois.com (HELO mail.galois.com) ([69.30.123.195]) by mail1-smtp-roc.national.inria.fr with ESMTP; 05 Feb 2008 22:20:16 +0100 Received: from dyn-50-92.galois.com (dyn-50-92.galois.com [192.168.50.92]) (authenticated bits=0) by mail.galois.com (8.13.8/8.13.8) with ESMTP id m15LJWNJ025918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Feb 2008 13:19:37 -0800 Cc: caml-list@yquem.inria.fr Message-Id: <2E251B0B-EE9B-4F03-AA31-8924D554AB57@galois.com> From: Joel Stanley To: Alain Frisch In-Reply-To: <47A8CE53.40500@frisch.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Caml-list] Dynamic libs w/ Ocaml + C code under Mac OS X Date: Tue, 5 Feb 2008 13:19:32 -0800 References: <11970BA6-EC2F-47FD-A194-BFD204057F06@galois.com> <47A7EB9E.3050808@frisch.fr> <47A8CE53.40500@frisch.fr> X-Mailer: Apple Mail (2.915) X-Virus-Scanned: ClamAV 0.92/5700/Tue Feb 5 11:08:59 2008 on liouville.galois.com X-Virus-Status: Clean X-Spam: no; 0.00; libs:01 ocaml:01 frisch:01 ocaml:01 runtime:01 ocamlopt:01 -output-obj:01 foo:01 cvs:01 -output-obj:01 assembling:01 ocamlopt:01 -verbose:01 foo:01 'foo:01 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