Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Mary Fernandez <mff@research.att.com>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] MacOS port and file formats
Date: Fri, 31 Dec 2004 10:08:04 -0500	[thread overview]
Message-ID: <1104505684.8834.851.camel@localhost.localdomain> (raw)
In-Reply-To: <20041231.182319.04680184.garrigue@math.nagoya-u.ac.jp>

Hi Jacques,

Thanks for your message.  Here is what I am trying to do.

My O'Caml application is an XQuery engine.  It has three
APIs: one for O'Caml, one for C, and one for Java applications.

We create a native-code, dynamically linked
C library that includes our O'Caml library, the O'Caml runtime,
and several other C libraries that our application depends upon
the unix, nums, str libraries plus an external PCRE library.
We actually do this by hand with ocamlopt (not ocamlmklib)
because in the past, we found ocamlmklib did not work consistently
on all platforms.

What I have found is that if the dll*.so libraries are Mac bundle
files, then I get a linking error of the form 
"...ld: /Users/mff/ocaml-3.08.2/lib/ocaml/stublibs/libstr.dylib is input
for the dynamic link editor, is not relocatable by the static link
editor again..."
(Note that the default name of dllstr.so is not recognized by the 
Darwin linker).  If I re-compile the otherlibs/ in stublibs/
to be dynamically linked libraries, then I have no problems.
Also, if I just use the archive files, that works too -- but
I typically use O'Caml with dynamic libs enabled which is how
I tripped over this problem.

We only create a dynamically linked library, because 
our Java library call the C library, and the Java JNI requires
dynamically linked C libraries.

So, in short, I have something that works, but still dont'
understand why bundles and dynamically linked libraries caused
me trouble.

Thanks,Mary

On Fri, 2004-12-31 at 04:23, Jacques Garrigue wrote:
> From: Mary Fernandez <mff@research.att.com>
> 
> > I have a question regarding the ./configure options for MacOS/Darwin.
> > 
> > ./configure selects the -bundle option for MKSHAREDLIB, which
> > has the effect of creating MacOS bundle type files for the dynamically
> > linked libraries in lib/ocaml/stublibs.  I have had trouble linking
> > these bundle files with the standard dynamically linked libraries
> > created with the -dynamiclib option.    As an experiment, I replaced
> > -bundle by -dynamiclib and attempted to rebuild the O'Caml compiler,
> > but got an error deep in compilation of the compiler.  Ultimately,
> > I just made the otherlibs/* libraries by hand with -dynamiclib and was
> > able
> > to link my application.
> > 
> > I will admit that I am overwhelmed by the Darwin documentation
> > that explains how to port a Linux application to MacOS. 
> > Can someone explain why the -bundle option is necessary to the compiler
> > compilation?
> > Is it because the O'Caml compiler a full-fledged Mac application?
> 
> Could you explain exactly what you are trying to do?
> The dlls in stublibs are only intended to be dynamically loaded by an
> ocaml application. The reason bundles are used rather than dynamic
> libraries is that the API for bundles is simpler, and that their
> explicit intent (plugins) seems close enough to the use of dlls in
> ocaml.
> Note that a bundle can depend on dynamic libraries, so this should not
> induce other limitations.
> 
> Jacques Garrigue
-- 
Mary Fernandez <mff@research.att.com>
AT&T Labs - Research


  reply	other threads:[~2004-12-31 15:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-31  2:02 Mary Fernandez
2004-12-31  9:23 ` [Caml-list] " Jacques Garrigue
2004-12-31 15:08   ` Mary Fernandez [this message]
2005-01-02  1:35     ` Jacques Garrigue
2005-01-02 12:23       ` Jacques GARRIGUE
2005-01-04  3:29         ` Mary Fernandez

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=1104505684.8834.851.camel@localhost.localdomain \
    --to=mff@research.att.com \
    --cc=caml-list@inria.fr \
    --cc=garrigue@math.nagoya-u.ac.jp \
    /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