caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Kenneth Adam Miller <kennethadammiller@gmail.com>
To: caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] Utop Difficulties with C callbacks
Date: Thu, 19 Mar 2015 15:33:40 -0400	[thread overview]
Message-ID: <CAK7rcp837bzcG6w1xOuRQvpn4VwF_DshdK28-TbkgFTyO4t8Yw@mail.gmail.com> (raw)
In-Reply-To: <CANhEzE6uSa8JF6mg3NBjrEh8A4c2oBn_mzTZjcRW4_QtVJRxyQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3722 bytes --]

Thanks! I appreciate this so much!

Gah, I skipped sleep in my determination to fix this.

I will hit it with -dllib iteration. I love oasis, and I'm an avid user.
Piqi doesn't use oasis :( sadness.

It does, however, already do the -custom approach, but only when compiling
the cma (I differentiate you said when building the executable). So I don't
know why it wouldn't work with that. In any case, I will take your advice
about the proper route. I'm all about quality and doing things right!

On Thu, Mar 19, 2015 at 3:01 PM, Jeremie Dimino <jdimino@janestreet.com>
wrote:

> I have to run, but think the problem is that piqilib is not building a
> shared library for its C stubs: if you want to be able to load a
> library with C stubs in the toplevel, the stubs must be packed into a
> shared library. You normally do this with ocamlmklib and pass a -dllib
> option when building the .cma. oasis does all that automatically.
>
> This other option is to build the bytecode executable with -custom,
> which will link the C libraries, the ocamlrun executable and the
> bytecode into a single native executable.
>
> So simply adding -custom when building a custom utop should work. But
> the proper fix is to update piqilib to build a .so for its C stubs.
>
>
>
> On Thu, Mar 19, 2015 at 6:19 PM, Kenneth Adam Miller
> <kennethadammiller@gmail.com> wrote:
> > So, I've been working for a while with a library and I've made a good
> > iteration. My code compiles and is nice, it does what is expected, but it
> > depends on a library, Piqi, that doesn't want to play nice in the
> > interpreter. I want to be a good citizen and do my homework and due
> > diligence, but nothing I do seems to make utop want to play nice with
> piqi.
> >
> > Here goes:
> >
> > When I execute utop -require mypackage repository with the newly built
> > package mypackage, but I get this error:
> >
> > File "_none_", line 1:
> > Error: The external function `camlidl_piqi_c_piqi_strtoull' is not
> available
> >
> > I checked out piqi locally, and pinned the package to my local build,
> where
> > I tried to ensure that the appropriate .c file is getting compiled and
> > linked into the cma and cmxa. They are without a shadow of a doubt. I
> then
> > thought maybe I would add an include directive to utop to tell it to
> pick up
> > the mli where the the external func : type = "name" is. Nope.
> >
> > I've done everything I can, from adding all combinations of additional
> > piqirun/piqilib/piqirun.pb/piqirun.ext combinations to the _oasis file
> that
> > specifies the serialization to trying to build my own utop to adding
> > additional require statements and include statements in the utop script.
> So
> > after trying to add the dependency to BuildDepends for myouterlib, I had
> > backed off to just adding the mylibrary to the specific binary that
> consumes
> > it, which is where my changes are (in that binary).
> >
> > I even went so far as to just try and get the changes compiled into a
> custom
> > utop. Nope. I got errors and errors; I built it with:
> > ocamlbuild -use-ocamlfind -pkg threads -pkg utop -pkg myouterlib -pkg
> camlp4
> > -pkg core_kernel customtop.top
> >
> > (At the time I ran this, I had bap package's _oasis updated with the
> > appropriate compile BuildDepends so that it would link mylibrary too)
> >
> > and I had the let () = Utop_main.main ();; in "utopmain.ml" and
> customary
> > customtop.mltop containing just "Utopmain". I got:
> >
> > (Unbound value <everything I need *and* that's contained in mylibrary
> which
> > is specified in -pkg!>)
> >
> > I don't know what else to do besides ship code that is watered down
> without
> > an interactive component. :/
>
>
>
> --
> Jeremie
>

[-- Attachment #2: Type: text/html, Size: 4710 bytes --]

  reply	other threads:[~2015-03-19 19:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-19 18:19 Kenneth Adam Miller
2015-03-19 19:01 ` Jeremie Dimino
2015-03-19 19:33   ` Kenneth Adam Miller [this message]
2015-03-19 21:36     ` Kenneth Adam Miller
2015-03-20  9:43       ` Jeremie Dimino
2015-03-20  9:57         ` Daniel Bünzli
2015-03-20 14:51           ` Kenneth Adam Miller
2015-03-20 15:02             ` Daniel Bünzli

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=CAK7rcp837bzcG6w1xOuRQvpn4VwF_DshdK28-TbkgFTyO4t8Yw@mail.gmail.com \
    --to=kennethadammiller@gmail.com \
    --cc=caml-list@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).