[question] Why does lua/5.4.6 conflict with luajit/2.1.0-beta3 ?

[YesserLab]

Environment

OS: macOS (arm64)
Compiler: clang-18
Conan: v2.11.0

What is your question?

I'm building complex project with multiple libraries, where:

• all require sol2 (which depends on lua/5.4.6)
• Some require lua/5.4.6
• Some require luajit/2.1.0-beta3

When installing those packages using this conanfile:

[requires]
argparse/3.1
catch2/3.6.0
duckdb/1.1.3
fmt/11.0.2
lua/5.4.6
luajit/2.1.0-beta3
miniz/3.0.2
sol2/3.3.1
troldal-zippy/cci.20200622
xtensor/0.25.0

[options]
duckdb/1.1.3:shared=False
duckdb/1.1.3:with_threads=False

lua/5.4.6:with_tools=True
luajit/2.1.0-beta3:shared=False

I get the error:

[snip]
Requirements
    argparse/3.1#66e9e0a9efb7da710f8cc10efdf020a5 - Cache
    catch2/3.6.0#c25921b857112b605fa54b0906d6b474 - Cache
    duckdb/1.1.3#99495ff99f5bf65dd12d229def395b3a - Cache
    fmt/11.0.2#b4a24d70b93466b9b508ddb7b014643b - Cache
    lua/5.4.6#658d6089093cf01992c2737ab2e96763 - Cache
    luajit/2.1.0-beta3#e8ee964ad9fedb6ebd93b83ec3452a62 - Cache
    miniz/3.0.2#6e39a83b94a8951a57a0e29969960170 - Cache
    nlohmann_json/3.11.3#45828be26eb619a2e04ca517bb7b828d - Cache
    sol2/3.3.1#adbccd5e877fcd6cba861aa528c7b4cd - Cache
    troldal-zippy/cci.20200622#8f2826991219a706e9269c9d73e11ee5 - Cache
    xsimd/13.0.0#3e7543dc526b0f612fe291e0f198c9dc - Cache
    xtensor/0.25.0#9dc921ac9347796a913d1b3517d00372 - Cache
    xtl/0.7.5#09fbb7d54f9d50c029dbc73132d79cbc - Cache
ERROR: Provide Conflict: Both 'lua/5.4.6' and 'luajit/2.1.0-beta3' provide '['lua']'.

I don't quite understand why there should a conflict between lua and luajit.
They provide different libraries, headers, and binaries. I suppose that it's up-to the project to decide what to link against.
Additionally, sol2 is a header only library, with guards and macros to define which lua to use. So I'm guessing it shouldn't be the problem.

Am I missing something here ?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @YesserLab

Thanks for your question.
It seems this is related to the ConanCenter current recipes, not to the Conan client, so I have transferred the ticket to the conan-center-index repo.

[jcar87]

They provide different libraries, headers, and binaries.

• lua

|-- conaninfo.txt
|-- conanmanifest.txt
|-- include
|   |-- lauxlib.h
|   |-- lua.h
|   |-- lua.hpp
|   |-- luaconf.h
|   `-- lualib.h
|-- lib
|   `-- liblua.so
`-- licenses
    `-- COPYING.txt

• luajit

/root/.conan2/p/luaji2123ee65c5019/p
|-- bin
|   `-- luajit-2.1.0-beta3
|-- conaninfo.txt
|-- conanmanifest.txt
|-- include
|   `-- luajit-2.1
|       |-- lauxlib.h
|       |-- lua.h
|       |-- lua.hpp
|       |-- luaconf.h
|       |-- luajit.h
|       `-- lualib.h
|-- lib
|   |-- libluajit-5.1.so -> libluajit-5.1.so.2.1.0
|   |-- libluajit-5.1.so.2 -> libluajit-5.1.so.2.1.0
|   |-- libluajit-5.1.so.2.1.0
|   `-- lua
|       `-- 5.1
`-- licenses
    `-- COPYRIGHT

they seem to provide the exact same header files - by means of https://github.com/zarvox/conan-center-index/blob/677e5dc289f85d80c5d7fffd668a6c0b2167a0bb/recipes/luajit/all/conanfile.py#L141-L142, and the libraries have the same symbols, so if both are present in the dependency graph it will be undetermined which the compiler picks (in the sense that it will depend on the order of the -I flags)
if the same executable loads both shared libraries (or links against both), it's also undetermined which one the linker will consider, and may lead to duplicated symbol errors

[YesserLab]

Thank you guys for the speedy reply 🙏

@jcar87 The headers of the JIT live in a subdir, so inclusion is not going to be ambiguous, observing:
#include <lua.h> vs #include <luajit-2.1/lua.h>.
The -I flags typically point at the .../include dir, not the dirs below it.

That said, I see your point about the symbols.
I guess this changes the question slightly. Allow me to provide a bit more background.

In my project we build a whole root-filesystem tree, using conan to build and install the libraries used as dependencies.
This is done in a "staging environment", using the full_deploy functionality.
This basically creates something like the tree shown bellow.

This leaves the burden of correct choice of libraries to link to our build system, in which the user must name the shared/static libraries to be used for linking. In other words, our packages must explicitly choose Lua XOR LuaJIT to link against, and conan doesn't have to worry about it 🙂

Having said that, the only potential for collision is when two libraries produce files with the same name on the tree.
Which is not the case here.

So the "updated" question is: Is there a way to achieve what we are doing ? or workaround the conflict ?

EDIT: I forgot to mention that conan is configured to build everything into static libraries so linking is really not a problem for it

Example rootfs tree:

staging/...
├── bin/...
├── conan/...
│   └── full_deploy/...
│       └── host/...
├── include/...
│   ├── Zippy/...
│   ├── argparse/...
│   ├── catch2/...
│   ├── duckdb/...
│   │   ├── catalog/...
│   │   ├── common/...
│   │   ├── core_functions/...
│   │   ├── execution/...
│   │   ├── function/...
│   │   ├── logging/...
│   │   ├── main/...
│   │   ├── optimizer/...
│   │   ├── parallel/...
│   │   ├── parser/...
│   │   ├── planner/...
│   │   ├── storage/...
│   │   ├── transaction/...
│   │   └── verification/...
├── lib/...