From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 9510C801CD for ; Tue, 29 Aug 2017 15:55:17 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=kennethadammiller@gmail.com; spf=Pass smtp.mailfrom=kennethadammiller@gmail.com; spf=None smtp.helo=postmaster@mail-lf0-f52.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.215.52; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.215.52 as permitted sender) identity=mailfrom; client-ip=209.85.215.52; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-lf0-f52.google.com) identity=helo; client-ip=209.85.215.52; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-lf0-f52.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AAyaLFx8BaEr0Mv9uRHKM819IXTAuvvDOBiVQ1KB9?= =?us-ascii?q?0u4cTK2v8tzYMVDF4r011RmSAtWdtqoMotGVmp6jcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47WLmffqXyq7DMUBg63dU8s?= =?us-ascii?q?fry0ScbuiJGexeG//tX4YwxXiDq0e6I6eBykrAjUnsIWiJRuKq8r213CpT1VeL?= =?us-ascii?q?IF63lvIAewkhD669uwtLdv+iEYnvMl88NaGfH5cqI+QKBYBTgvNmU04MnmrzHM?= =?us-ascii?q?SAKO4j0XVWBAwUkAOBTM8ByvBsS5iSD9rOconXDCZcA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAgB0caVZhjTXVdFeGwEBAQMBAQEJA?= =?us-ascii?q?QEBFQEBAQECAQEBAQgBAQEBhBOBFQeDcIE2mQKBcXeBeY15hUyCBCyFGwKECQd?= =?us-ascii?q?DFAEBAQEBAQEBAQEBEgEBAQgLCwgoL4IzBQEeAQWCOwEBAQECASMdARsdAQMBC?= =?us-ascii?q?wYDAgsNKgICIQEBEQEFARwGE4oYAQMNCBCTFJEbQIwLggUFARyDCQWDXwoZJw1?= =?us-ascii?q?Xg0QBAQEBBgEBAQEBARoCBhKDGIICgzGCczWCV4FrARIBTIJmgmEFiVUlhymBZ?= =?us-ascii?q?40iPIdZh32EdoISWokKhnWMTIgtFR+BFTaBIwsyISReGoI1ghAqH4IPJDaIb1+?= =?us-ascii?q?BUwEBAQ?= X-IPAS-Result: =?us-ascii?q?A0DUAgB0caVZhjTXVdFeGwEBAQMBAQEJAQEBFQEBAQECAQE?= =?us-ascii?q?BAQgBAQEBhBOBFQeDcIE2mQKBcXeBeY15hUyCBCyFGwKECQdDFAEBAQEBAQEBA?= =?us-ascii?q?QEBEgEBAQgLCwgoL4IzBQEeAQWCOwEBAQECASMdARsdAQMBCwYDAgsNKgICIQE?= =?us-ascii?q?BEQEFARwGE4oYAQMNCBCTFJEbQIwLggUFARyDCQWDXwoZJw1Xg0QBAQEBBgEBA?= =?us-ascii?q?QEBARoCBhKDGIICgzGCczWCV4FrARIBTIJmgmEFiVUlhymBZ40iPIdZh32EdoI?= =?us-ascii?q?SWokKhnWMTIgtFR+BFTaBIwsyISReGoI1ghAqH4IPJDaIb1+BUwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,445,1498514400"; d="scan'208,217";a="235633094" Received: from mail-lf0-f52.google.com ([209.85.215.52]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 29 Aug 2017 15:55:15 +0200 Received: by mail-lf0-f52.google.com with SMTP id z12so13645170lfd.3 for ; Tue, 29 Aug 2017 06:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ikvXHrpcXsXF7s1Nt9/df/vGGWY86oyDYMGHqwkL7Ag=; b=k6SWQziy06KFQJtn1NsziCY4vYxg1sa+MrnnKdOpvmXpfj3yvkCt72bi+59TwHSK/m hCZCPHp+mmQVjSizrEHOV92CZNdJNMLRjMk3CQWQ0LLiFpTTnYs00b/qfoUOIpvnQRQX pPOAQnImnjIflCJ0ooveBAm4FPjHz72KyTtGf6Z6RyxoMdQ4eMwKVZdSP+7J0muXgn0T bblMja+lEn4FeI7ynHi8yu3ILiceGQk4Y7QlUKYLoHL9aYMKQFUSCOeZ+xLjr40RmTV3 wmbmEgWXpKPPODb7pJROoTc3QQLiixLXqBZ178LhVZ8pDGjpQJ04XvvGadMlYhb4OWWi hAFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ikvXHrpcXsXF7s1Nt9/df/vGGWY86oyDYMGHqwkL7Ag=; b=OCoeBvC6bxIqIuPB7Pa5BKp5S+V2LrMgGLZzNu2ft58EhtV7ZnunKbYl8+CaIuMmBm s8KuRLUmeOzRDfy9ttnQ7LWxaz6+N6ArET1RVCDwfNKhZbaxpP378W+HPjCBWbNC+rWX C5blhAYGsCboTQIPyUxSFmo78n57mP3JNc3Cq+fWGx1BLtDqjK0Oc5bjvB6JScDCTlH5 YOQwD8RyFVY4RjFHEu3oVH+ULsL/CgsDDZaW1QvnURhWtwTPfwwTkGbNoUERk16M8z+V appkL+S+CUzb9MZXl2iZdBOKYr/AbbcMhayXIOOdOyBWgsGmGAwKmXEBADMw1VXzxDsZ SDIQ== X-Gm-Message-State: AHYfb5jdn5QSfmaS49Ff6vjf5x16nYjRQS7v7Qn1sTHhacf3phSmG+BN JiFs0RMBpQDSeBNoUg6NTKk/s7xRFZR1 X-Received: by 10.25.203.149 with SMTP id b143mr111267lfg.200.1504014915031; Tue, 29 Aug 2017 06:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.18 with HTTP; Tue, 29 Aug 2017 06:55:13 -0700 (PDT) Received: by 10.46.81.18 with HTTP; Tue, 29 Aug 2017 06:55:13 -0700 (PDT) In-Reply-To: References: From: Kenneth Adam Miller Date: Tue, 29 Aug 2017 09:55:13 -0400 Message-ID: To: Aziem Chawdhary Cc: caml users Content-Type: multipart/alternative; boundary="94eb2c19b63abf5a700557e4c26b" Subject: Re: [Caml-list] oasis and C wrapper --94eb2c19b63abf5a700557e4c26b Content-Type: text/plain; charset="UTF-8" I was able to resolve it only just late yesterday. It was really frustrating because I had several examples already working but mine wouldnt. I think it turned out that I needed to have the oasis project and library name match up with the folder it was all under. Once I stopped trying to build it under libdai/swig, it worked just fine. But I also was pretty much forced to stop working toward having all fully working across target types, since byte code and utop wouldn't leave me alone with missing symbol issues. I would go into the _build directory where the .cma was left, and do #load on it, and I never could get it to resolve symbols there I had even manually checked were already present in the .a files I had specified in my _oasis. Thank you so much for the help! I will look at what you have while I roll my updates into a set of pull requests and docker build files. On Aug 29, 2017 9:31 AM, "Aziem Chawdhary" wrote: > > Hi Kenneth, > > I don't know if you have solved this problem yet, but I have a small > example of building a static C lib and statically linking with OCaml > using Oasis and OCamlbuild. > > The repository is here: > > https://github.com/aziem/ctypes-static-lib-ocamlbuild > > and I think the most relevant example for you is under the oasis-lib > branch. This example uses ocamlbuild to do most of the work rather than > trying to get options set correctly in the _oasis file. So I use > ocamlbuild tags and a small myocamlbuild plugin and get everything built > correctly. > > This example uses information from various sources, including those you > linked to in your first email, as well as information from the > OCaml-Ctypes issue tracker. The repository is mainly for my own > documentation purposes but may be of use to you. > > Hope this helps, > Aziem > > > > Kenneth Adam Miller writes: > > > Ok I think I found the source of the error - this was in the _build/_log: > > > > ### Starting build. > > Backtrace: > > - Failed to build the target libdai_stubs.a > > - Building libdai_stubs.a: > > - Failed to build all of these: > > - Building libdai_stubs.cmx: > > - Failed to build all of these: > > - Building libdai_stubs.ml: > > - Failed to build all of > > these: > > - Building > > libdai_stubs.mly > > - Building > > libdai_stubs.mll > > - Building libdai_stubs.mlpack > > - Building libdai_stubs.mllib > > - Building libdai_stubs.clib > > # Compilation unsuccessful. > > > > The problem is that libdai_stubs.a is already built, and ocamlbuild is > > trying to build it again! Also, I followed the with-c oasis example to a > T, > > and theirs never tried to build .cmx/mllib/mlpack/mly/mli suffixed > > auto-generated C source file targets. So why would it try and do that > with > > mine?? I found that changing the library name of mine in my _oasis causes > > oasis/ocamlbuild to search for an appropriately named .ml file. But that > > doesn't happen in the with-c example, and not only that, the with-c > example > > doesn't have a with-c.ml file anyway?! Also my issue has been > replicated in > > two different dockers, stale mated on a Mac, and then also within an > ubuntu > > vm. > > > > I can't make this opam package until I get oasis and ocamlbuild to work > > together. > > > > On Sun, Aug 27, 2017 at 3:56 PM, Kenneth Adam Miller < > > kennethadammiller@gmail.com> wrote: > > > >> Ok, so I got the with-c example to build by running -configure before I > >> built with ocaml setup.ml -build, and that worked. But then there's a > >> part in there where ocamlbuild is passed a libwith-c_stubs.a target and > it > >> knows what to do with it. I've tried to copy that example line by line > in > >> my _oasis and command line steps, and I have know what calls ocamlbuild > >> should be making to get the .cma and .cmxa targets. But I can't get my > >> _oasis to work. > >> > >> On Sun, Aug 27, 2017 at 1:19 AM, Kenneth Adam Miller < > >> kennethadammiller@gmail.com> wrote: > >> > >>> Actually, I think it's that ocamlbuild should be told to link > >>> libdai_stubs.a, and not try and build it. But also, I wanted to > reference > >>> an existing work that links with C libraries, and I found ocamlbuild's > >>> example, with-c. I tried to build it, and I found that it isn't built > by > >>> the harness default. Also, if you just try and build within just that > raw > >>> directory in isolation, that it fails with a similar error I had been > >>> getting earlier. I looked around and found these: > >>> > >>> https://stackoverflow.com/questions/19644451/how-to-make- > >>> ocamlbuild-compile-and-link-a-c-file-into-an-ocaml-project > >>> https://l-lang.blogspot.com/2012/08/incorporating-c-code-in- > >>> ocaml-project.html > >>> https://ocaml.org/learn/tutorials/ocamlbuild/Using_an_extern > >>> al_library.html > >>> > >>> And I'm trying to follow, but they each give unique directions, each > seem > >>> to not work for me. > >>> > >>> On Sat, Aug 26, 2017 at 9:12 PM, Kenneth Adam Miller < > >>> kennethadammiller@gmail.com> wrote: > >>> > >>>> Hello, > >>>> > >>>> > >>>> I'm building a pair of companion oasis build spec and opam package > setup > >>>> for a C library. libdai I figured out how to get swig and oasis to > build > >>>> most things I need, but I'm having trouble getting oasis to not > generate > >>>> _stubs targets that aren't found. There is a static C/++ libdai.a > file that > >>>> is the product of the project I'm trying to wrap. I can't convince > oasis to > >>>> use that instead. Here's my _oasis target: > >>>> > >>>> > >>>> Library "dai" > >>>> Path: ./ > >>>> Install: false > >>>> Modules: Swig, Dai > >>>> CompiledObject: best > >>>> CSources: dai_wrap.cxx.c > >>>> CCOpt: -g -xc++ "-I../../include" > >>>> > >>>> > >>>> With a fresh clone of libdai, I get dai_wrap.cxx.c by doing the > >>>> following in ./swig after building libdai: > >>>> > >>>> $(SWIG) -ocaml -c++ dai.i > >>>> mv dai_wrap.cxx dai_wrap.cxx.c > >>>> sed -i -e 's/caml_array_length/caml_array_len/g' dai_wrap.cxx.c > >>>> > >>>> I got my swig and dai ml files by doing the following: > >>>> > >>>> swig2.0 -ocaml -co dai.ml > >>>> swig2.0 -ocaml -co swig.ml > >>>> swig2.0 -ocaml -co swig.mli > >>>> > >>>> I build by doing the following: > >>>> > >>>> ocaml setup.ml -configure > >>>> ocaml setup.ml -build > >>>> > >>>> > >>>> I get the following error: > >>>> > >>>> > >>>> Solver failed: > >>>> Ocamlbuild knows of no rules that apply to a target named > >>>> ./libdai_stubs.a. This can happen if you ask Ocamlbuild to build a > target > >>>> with the wrong extension (e.g. .opt instead of .native) or if the > source > >>>> files live in directories that have not been specified as include > >>>> directories. > >>>> Compilation unsuccessful after building 8 targets (8 cached) in > 00:00:00. > >>>> E: Failure("Command ''/usr/bin/ocamlbuild' ./libdai_stubs.a > >>>> ./dlldai_stubs.so ./dai.cma ./dai.cmxa ./dai.a ./dai.cmxs -j 5 -tag > debug' > >>>> terminated with error code 6") > >>>> > >>>> I want to make sure that the actual target shared library that was > >>>> produced by the libdai build file itself is linked against. But oasis > is > >>>> assuming I have a _stubs target. I read in the documentation here > that: "The > >>>> usual idiom is to append _stubs to the name." > >>>> https://ocaml.org/learn/tutorials/setting_up_with_oasis.html > >>>> #Interfacing-with-C-code > >>>> > >>>> And I think that that is the source of the error, but it isn't well > >>>> explained. The ultimate things I originally wanted was to be able to > use > >>>> libdai with both the utop or the bytecode interpreter and with fully > >>>> compiled targets. I was going to make libdai a library and then > publicize > >>>> it. > >>>> > >>>> If anybody needs to replicate my issue, I have a docker container with > >>>> this already. > >>>> > >>> > >>> > >> > > > -- > --94eb2c19b63abf5a700557e4c26b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was able to resolve it only just late yesterday. It was= really frustrating because I had several examples already working but mine= wouldnt. I think it turned out that I needed to have the oasis project and= library name match up with the folder it was all under. Once I stopped try= ing to build it under libdai/swig, it worked just fine. But I also was pret= ty much forced to stop working toward having all fully working across targe= t types, since byte code and utop wouldn't leave me alone with missing = symbol issues. I would go into the _build directory where the .cma was left= , and do #load on it, and I never could get it to resolve symbols there I h= ad even manually checked were already present in the .a files I had specifi= ed in my _oasis.

Thank you so = much for the help! I will look at what you have while I roll my updates int= o a set of pull requests and docker build files.

On Aug 29, 2017 9:31 AM, "A= ziem Chawdhary" <aziem@cha= wdhary.co.uk> wrote:

Hi Kenneth,

I don't know if you have solved this problem yet, but I have a small
example of building a static C lib and statically linking with OCaml
using Oasis and OCamlbuild.

The repository is here:

https://github.com/aziem/ctypes-static-lib= -ocamlbuild

and I think the most relevant example for you is under the oasis-lib
branch. This example uses ocamlbuild to do most of the work rather than
trying to get options set correctly in the _oasis file. So I use
ocamlbuild tags and a small myocamlbuild plugin and get everything built
correctly.

This example uses information from various sources, including those you
linked to in your first email, as well as information from the
OCaml-Ctypes issue tracker. The repository is mainly for my own
documentation purposes but may be of use to you.

Hope this helps,
Aziem



Kenneth Adam Miller <kenn= ethadammiller@gmail.com> writes:

> Ok I think I found the source of the error - this was in the _build/_l= og:
>
> ### Starting build.
> Backtrace:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0- Failed to build the target libdai_stubs.a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0- Building libdai_stubs.a:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Failed to build all of these:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Building libdai_st= ubs.cmx:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Fail= ed to build all of these:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0- Building libdai_stubs.ml:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0- Failed to build all of
> these:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Building
> libdai_stubs.mly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Building
> libdai_stubs.mll
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0- Building libdai_stubs.mlpack
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Building libdai_st= ubs.mllib
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Building libdai_st= ubs.clib
> # Compilation unsuccessful.
>
> The problem is that libdai_stubs.a is already built, and ocamlbuild is=
> trying to build it again! Also, I followed the with-c oasis example to= a T,
> and theirs never tried to build .cmx/mllib/mlpack/mly/mli suffixed
> auto-generated C source file targets. So why would it try and do that = with
> mine?? I found that changing the library name of mine in my _oasis cau= ses
> oasis/ocamlbuild to search for an appropriately named .ml file. But th= at
> doesn't happen in the with-c example, and not only that, the with-= c example
> doesn't have a with-c.ml file anyway?! Also my issue has been replicate= d in
> two different dockers, stale mated on a Mac, and then also within an u= buntu
> vm.
>
> I can't make this opam package until I get oasis and ocamlbuild to= work
> together.
>
> On Sun, Aug 27, 2017 at 3:56 PM, Kenneth Adam Miller <
> kennethadammiller@gmail= .com> wrote:
>
>> Ok, so I got the with-c example to build by running -configure bef= ore I
>> built with ocaml setup.ml -build, and that worked. But then there's = a
>> part in there where ocamlbuild is passed a libwith-c_stubs.a targe= t and it
>> knows what to do with it. I've tried to copy that example line= by line in
>> my _oasis and command line steps, and I have know what calls ocaml= build
>> should be making to get the .cma and .cmxa targets. But I can'= t get my
>> _oasis to work.
>>
>> On Sun, Aug 27, 2017 at 1:19 AM, Kenneth Adam Miller <
>> kennethadammiller@g= mail.com> wrote:
>>
>>> Actually, I think it's that ocamlbuild should be told to l= ink
>>> libdai_stubs.a, and not try and build it. But also, I wanted t= o reference
>>> an existing work that links with C libraries, and I found ocam= lbuild's
>>> example, with-c. I tried to build it, and I found that it isn&= #39;t built by
>>> the harness default. Also, if you just try and build within ju= st that raw
>>> directory in isolation, that it fails with a similar error I h= ad been
>>> getting earlier. I looked around and found these:
>>>
>>> https://stackoverflow.com/questions/19644451/how-to-make-
>>> ocamlbuild-compile-and-link-a-c-file-into-an-ocaml-projec= t
>>> https://l-lang.blogspot.com= /2012/08/incorporating-c-code-in-
>>> ocaml-project.html
>>> https://ocaml.org/learn/tutorials/ocamlbuild/Using_an_extern
>>> al_library.html
>>>
>>> And I'm trying to follow, but they each give unique direct= ions, each seem
>>> to not work for me.
>>>
>>> On Sat, Aug 26, 2017 at 9:12 PM, Kenneth Adam Miller <
>>> kennethadammill= er@gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>>
>>>> I'm building a pair of companion oasis build spec and = opam package setup
>>>> for a C library. libdai I figured out how to get swig and = oasis to build
>>>> most things I need, but I'm having trouble getting oas= is to not generate
>>>> _stubs targets that aren't found. There is a static C/= ++ libdai.a file that
>>>> is the product of the project I'm trying to wrap. I ca= n't convince oasis to
>>>> use that instead. Here's my _oasis target:
>>>>
>>>>
>>>> Library "dai"
>>>>=C2=A0 =C2=A0Path:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0./
>>>>=C2=A0 =C2=A0Install:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 false
>>>>=C2=A0 =C2=A0Modules:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Swig, Dai
>>>>=C2=A0 =C2=A0CompiledObject:=C2=A0 =C2=A0 =C2=A0 =C2=A0best=
>>>>=C2=A0 =C2=A0CSources:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0dai_wrap.cxx.c
>>>>=C2=A0 =C2=A0CCOpt:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -g -xc++ "-I../../include"
>>>>
>>>>
>>>> With a fresh clone of libdai, I get dai_wrap.cxx.c by doin= g the
>>>> following in ./swig after building libdai:
>>>>
>>>> $(SWIG) -ocaml -c++=C2=A0 dai.i
>>>> mv dai_wrap.cxx dai_wrap.cxx.c
>>>> sed -i -e 's/caml_array_length/caml_array_len/g&#= 39; dai_wrap.cxx.c
>>>>
>>>> I got my swig and dai ml files by doing the following:
>>>>
>>>> swig2.0 -ocaml -co dai.ml
>>>> swig2.0 -ocaml -co swig.ml
>>>> swig2.0 -ocaml -co swig.mli
>>>>
>>>> I build by doing the following:
>>>>
>>>> ocaml setup.ml -configure
>>>> ocaml setup.ml -build
>>>>
>>>>
>>>> I get the following error:
>>>>
>>>>
>>>> Solver failed:
>>>>=C2=A0 =C2=A0Ocamlbuild knows of no rules that apply to a t= arget named
>>>> ./libdai_stubs.a. This can happen if you ask Ocamlbuild to= build a target
>>>> with the wrong extension (e.g. .opt instead of .native) or= if the source
>>>> files live in directories that have not been specified as = include
>>>> directories.
>>>> Compilation unsuccessful after building 8 targets (8 cache= d) in 00:00:00.
>>>> E: Failure("Command ''/usr/bin/ocamlbuild'= ; ./libdai_stubs.a
>>>> ./dlldai_stubs.so ./dai.cma ./dai.cmxa ./dai.a ./dai.cmxs = -j 5 -tag debug'
>>>> terminated with error code 6")
>>>>
>>>> I want to make sure that the actual target shared library = that was
>>>> produced by the libdai build file itself is linked against= . But oasis is
>>>> assuming I have a _stubs target. I read in the documentati= on here that: "The
>>>> usual idiom is to append _stubs to the name."
>>>> https://ocaml.org/learn= /tutorials/setting_up_with_oasis.html
>>>> #Interfacing-with-C-code
>>>>
>>>> And I think that that is the source of the error, but it i= sn't well
>>>> explained. The ultimate things I originally wanted was to = be able to use
>>>> libdai with both the utop or the bytecode interpreter and = with fully
>>>> compiled targets. I was going to make libdai a library and= then publicize
>>>> it.
>>>>
>>>> If anybody needs to replicate my issue, I have a docker co= ntainer with
>>>> this already.
>>>>
>>>
>>>
>>


--
--94eb2c19b63abf5a700557e4c26b--