What to do about "Files [...] both define module Base64"?

I’m trying to upgrade a project to use base64 v3.0, but I’m running into errors where Core_extended also defines a module named base64, and apparently that’s confusing some part of the build system:

Files /home/opam/.opam/4.06.1/lib/core_extended/base64/base64.cmxa
97	       and /home/opam/.opam/4.06.1/lib/base64/base64.cmxa
98	       both define a module named Base64

Is there anything I can do about this, or can I just not use these two libraries in the same project? :\

I think it is just a matter of not using the ocamlfind package core_extended.base64. How you do this depends on your build system.

Cheers,
Nicolás

Ah, yes … This update was done by an issue which points an inconsistency between B64 (name of the module) and base64 (name of the library). This problem exists about the extlib library (which we added a constraint on it - but delete it just after) too.

We did several patches (like in infer or wodan) to update them to the last version of base64. Of course, we can not update the world about this update unfortunately.

Specially about your problem, I did a little program which use base64 and core_extended.find_files. You just need to avoid a link with core_extended.base64:

(executable
 (name main)
 (libraries base64 core_extended core_extended.find_files))

For example. However, if, by transitivity, one of your packages use core_extended.base64, you should have a problem - and in this case, both can not exists in the same world.

I see… so because of a change in a different library, we either need to stop using anything that uses core_extended.base64 or hope that Jane Street renames it (or stop using cohttp…). This is frustrating.

In the long term, there is a plan for namespaces that we are incrementally implementing to avoid this problem.

In the short term, I’m discussing with Jane Street how the Mirage base64 package and the core_extended one could be merged. Surprisingly complicated, Base64 is

3 Likes