caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Joel Stanley <jstanley@galois.com>
To: Alain Frisch <alain@frisch.fr>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Dynamic libs w/ Ocaml + C code under Mac OS X
Date: Tue, 5 Feb 2008 08:39:32 -0800	[thread overview]
Message-ID: <EC9F97A0-9252-48A4-B097-36A45E433BED@galois.com> (raw)
In-Reply-To: <47A7EB9E.3050808@frisch.fr>

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


  reply	other threads:[~2008-02-05 16:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-04 22:39 Joel Stanley
2008-02-05  4:52 ` [Caml-list] " Alain Frisch
2008-02-05 16:39   ` Joel Stanley [this message]
2008-02-05 21:00     ` Alain Frisch
2008-02-05 21:19       ` Joel Stanley
2008-02-05 21:49         ` Alain Frisch
2008-02-06  0:02           ` Joel Stanley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EC9F97A0-9252-48A4-B097-36A45E433BED@galois.com \
    --to=jstanley@galois.com \
    --cc=alain@frisch.fr \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).