caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Markus Mottl <markus@oefai.at>
To: Yaron Minsky <yminsky@cs.cornell.edu>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Byte code and dynamic linking of C libraries
Date: Wed, 28 Apr 2004 21:38:19 +0200	[thread overview]
Message-ID: <20040428193819.GD11866@fichte.ai.univie.ac.at> (raw)
In-Reply-To: <40551.141.155.88.179.1083177798.squirrel@minsky-primus.homeip.net>

On Wed, 28 Apr 2004, Yaron Minsky wrote:
> I've got some code that dynamically links in a C library.  The code
> works just fine when I compile to native code, but blows up when I
> compile to bytecode.

Hm, this may indicate that one of your C-functions accessed from OCaml
takes more than five arguments.  In this case you'll have to write a
wrapper that uses argument vectors.  E.g.:

  CAMLprim value pcre_exec_stub_bc(value *argv, int argn)
  {
    return pcre_exec_stub(argv[0], argv[1], argv[2], argv[3],
                          argv[4], argv[5], argv[6]);
  }

The external declaration in OCaml then looks as follows (note the two
entry points for byte- and native code):

  external unsafe_pcre_exec :
    irflag -> regexp -> int -> string ->
    int -> int array -> callout option
    -> unit = "pcre_exec_stub_bc" "pcre_exec_stub"
              ------------------- ----------------

Earlier OCaml-releases didn't check the number of arguments, but I'm not
sure whether you'll have to grab a CVS-version to be warned about this
(if this is the cause of the problem)?

> Just to be clear, the dynamic linking I'm doing happens
> entirely on the C side:  I've got a c library that is linked in
> statically, and the dlopen and dlclose calls all happen within that C
> library.  When I try this trick in bytecode, I get a segfault.
> 
> So, any ideas as to what I need to do to make dynamic linking and byte
> code to play nicely together?

I can't imagine any good reason why dynamic linking performed at runtime
by C-code should have an effect on the byte code interpreter.  But maybe
there are bad ones?

Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


      parent reply	other threads:[~2004-04-28 19:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-28 18:43 Yaron Minsky
2004-04-28 19:31 ` Nicolas Cannasse
2004-04-28 19:38 ` Markus Mottl [this message]

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=20040428193819.GD11866@fichte.ai.univie.ac.at \
    --to=markus@oefai.at \
    --cc=caml-list@inria.fr \
    --cc=yminsky@cs.cornell.edu \
    /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).