Re: [Caml-list] oasis and C wrapper

[Kenneth Adam Miller <kennethadammiller@gmail.com>]

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

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" <aziem@chawdhary.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 <kennethadammiller@gmail.com> 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.
> >>>>
> >>>
> >>>
> >>
>
>
> --
>

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