Conan: [question] What does "ERROR: There are 4 binaries with name libxml2" mean?

[sztomi]

Conan version: 1.20.2

I'm running into this error message when building our tree with most (but not all) of our profiles. There are many similar messages with different packages. I'm calling conan create with a lockfile to build the package.

The message comes from here:

https://github.com/conan-io/conan/blob/1.20.2/conans/model/graph_lock.py#L324

The wording "binary" is probably misleading here, but I assume this means that somehow there are multiple nodes in the dependency tree with the same name. We probably have overlap in the tree (i.e. not always just the minimal needed packages are required explicitly, sometimes things that are transitive deps of the top-level dependencies are also required explicitly). But we don't have name collisions in our packages. So what does this error mean exactly and what can I do to resolve it?

---

• [x] I've read the CONTRIBUTING guide.

[sztomi]

1.20.3 produces the same.

[danimtb]

I think we will require here the help of @memsharded. I don't know what is the case to show that message 😕

[radonish]

I actually just ran into this myself; I believe for me it's related to a package being a build requirement for 1 package and a requirement for another in the dependency tree.

[uilianries]

Probably you have both Bincrafters and Conan Center Index packages installed.

$ conan search -r conan-center libxml2
Existing package recipes:

libxml2/2.9.3@bincrafters/stable
libxml2/2.9.8@bincrafters/stable
libxml2/2.9.9
libxml2/2.9.9@bincrafters/stable

[sztomi]

@uilianries no, that's not the reason for this error, that would surface earlier. @radonish is right. The root cause of the problem is that when a requirement exists both as a normal requires and build_requires, conan doesn't treat them as equals while computing the graph. But when at the end it sanity checks the final computed graph, it finds that there are two nodes for the same name which shouldn't happen. The primary use-case for (ab)using build_requires for deps is to hide them (and avoid private requires, which has a bunch of issues - and this was recommended by the conan devs way back).

There is no good workaround at this time. We briefly considered creating "facade" packages that repackage builds without their build_requires, but that's really difficult to get right; it involves parsing the conanfile and emitting another package in the build or package step of the real package. A quite brittle setup.

For now, we just bit bullet and removed build_requires usage from our codebase. 2.0 wants to include a solution for this, I hear.

[radonish]

@sztomi, forgot to follow up but I did confirm that a package existing as both a requirement and build requirement was the issue. I was able to switch them all to one category and it worked fine.

Thanks

[danimtb]

Definitely this is something we have to take a look too. Thanks a lot for the feedback, we will investigate it.

[jgsogo]

I'm reproducing this error in this PR https://github.com/conan-io/conan/pull/7144/files (second test with the protobuf package)

Thanks for reporting it

[memsharded]

7243 fixes this issue, will be released in Conan 1.28, together with many other changes of lockfiles.