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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id CBB66BC6C for ; Tue, 5 Feb 2008 17:40:50 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKYgqEdFHnvD/2dsb2JhbACtag X-IronPort-AV: E=Sophos;i="4.25,308,1199660400"; d="scan'208";a="6931908" Received: from galois.com (HELO mail.galois.com) ([69.30.123.195]) by mail2-smtp-roc.national.inria.fr with ESMTP; 05 Feb 2008 17:40:49 +0100 Received: from [10.0.1.197] (c-24-21-193-248.hsd1.mn.comcast.net [24.21.193.248]) (authenticated bits=0) by mail.galois.com (8.13.8/8.13.8) with ESMTP id m15GdXAd013842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Feb 2008 08:39:47 -0800 Cc: caml-list@yquem.inria.fr Message-Id: From: Joel Stanley To: Alain Frisch In-Reply-To: <47A7EB9E.3050808@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 08:39:32 -0800 References: <11970BA6-EC2F-47FD-A194-BFD204057F06@galois.com> <47A7EB9E.3050808@frisch.fr> X-Mailer: Apple Mail (2.915) X-Virus-Scanned: ClamAV 0.92/5693/Tue Feb 5 07:13:00 2008 on liouville.galois.com X-Virus-Status: Clean X-Spam: no; 0.00; libs:01 ocaml:01 frisch:01 ocaml:01 dynlink:01 runtime:01 runtime:01 libasmrun:01 asmrun:01 gcc:01 ocamlopt:01 ocamlopt:01 -shared:01 cmx:01 -shared:01 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