[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] inconsistent assumptions over interface error



The manual makefile probably doesn't pull in as many dependencies.  The real answer here is just to fix the upstream I think, as it'll block any non-trivial uses of the OCaml TLS stack.

-anil

On 3 Aug 2014, at 14:06, Gregory Tsipenyuk <gt303@xxxxxxxxx> wrote:

Anil,

Thanks, I understand the clash issue.

By regular Makefile I just mean a manually created Makefile that has "ocamlbuild -use-ocamlfind… app.native” This builds. 

I replaced Extlib.Base64 with Batteries.Base64, which doesn’t conflict with Nocrypto and builds, so I’m good.

The “Core” conflict in asn1-combinators is more annoying as I have a file used in both Async and Lwt and I wanted to use Core.Std.Io_channel that works in both, but I think I have a work around for this too.

Thanks,

Gregory

On Aug 3, 2014, at 12:18 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

Hi Gregory, [ccing mirageos-devel]

The root cause of this issue is a clash with top-level module names.  Somewhere in your library dependency chain, something has also defined a module called "Base64" that is different from the one that Nocrypto thinks its using.

One way to fix this is by not exposing a library's internal modules to the outside world by packing them inside a single top-level module.  Cohttp is one example of a library that does this.  (see https://realworldocaml.org/v1/en/html/the-compiler-frontend-parsing-and-type-checking.html#modules-and-separate-compilation for more information on packing).

It's difficult to workaround this without just fixing the libraries themselves -- although you will never get a segfault (as would happen in C if you mix up object files), the compiler will just reject inconsistent library checksums all the time.

I'm not sure which makefile you're referring to (vs oasis below), but perhaps David and Hannes can comment on whether they can pack the various crypto libraries for easier use.

Also, we could just pull Base64 into a separate OPAM package since it's very commonly cut-and-pasted.  I've taken a quick shot at this on https://github.com/mirage/ocaml-base64.  This is a different implementation (but possibly the same spec) as nocrypto's, so needs some review to see if they're compatible or not (padding is possibly slightly different).

-anil

On 2 Aug 2014, at 13:08, Gregory Tsipenyuk <gt303@xxxxxxxxx> wrote:

Hi Anil,

I got another “inconsistent assumptions” issue. It looks like it is similar to the one I opened a few days ago against asn1-combinators. Nocrypto does have its own Base64 module. What puzzles me though is that  it fails if I build with oasis generated stuff and if I build with the regular Makefile then it builds. Can you think of any flags that I can tweak to fix it?

Thanks,
Gregory 

File "_none_", line 1:
Error: Files utils.cmx
       and /Users/gregt/.opam/4.01.0+clang-fix/lib/nocrypto/nocrypto.cmxa
       make inconsistent assumptions over interface Base64
Command exited with code 2


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.