There is a great community behind Conan with users helping each other in Cpplang Slack.
Please join us in the
ERROR: Missing prebuilt package¶
When installing packages (with conan install or conan create) it is possible that you get an error like the following one:
ERROR: Missing binary: zlib/1.2.11:b1d267f77ddd5d10d06d2ecf5a6bc433fbb7eeed zlib/1.2.11: WARN: Can't find a 'zlib/1.2.11' package binary 'b1d267f77ddd5d10d06d2ecf5a6bc433fbb7eeed' for the configuration: [settings] arch=x86_64 build_type=Release compiler=apple-clang compiler.cppstd=gnu11 compiler.libcxx=libc++ compiler.version=14 os=Macos [options] fPIC=True shared=False ERROR: Missing prebuilt package for 'zlib/1.2.11' Check the available packages using 'conan list zlib/1.2.11:* -r=remote' or try to build locally from sources using the '--build=zlib/1.2.11' argument More Info at 'https://docs.conan.io/en/2/knowledge/faq.html#error-missing-prebuilt-package'
This means that the package recipe
zlib/1.2.11 exists, but for some reason there is no
precompiled package for your current settings or options. Maybe the package creator didn’t build and
shared pre-built packages at all and only uploaded the package recipe, or they are only
providing packages for some platforms or compilers. E.g. the package creator built
packages from the recipe for apple-clang 11, but you are using apple-clang 14.
Also you may want to check your package ID mode as it may
have an influence on the packages available for it.
By default, Conan doesn’t build packages from sources. There are several possibilities to overcome this error:
- You can try to build the package for your settings from sources, indicating some build policy as argument, like --build zlib* or --build missing. If the package recipe and the source code work for your settings you will have your binaries built locally and ready for use.
- If building from sources fails, and you are using the conancenter remote, you can open an issue in the Conan Center Index repository
ERROR: Invalid setting¶
It might happen sometimes, when you specify a setting not present in the defaults that you receive a message like this:
$ conan install . -s compiler.version=4.19 ... ERROR: Invalid setting '4.19' is not a valid 'settings.compiler.version' value. Possible values are ['4.4', '4.5', '4.6', '4.7', '4.8', '4.9', '5.1', '5.2', '5.3', '5.4', '6.1', '6.2']
This doesn’t mean that such compiler version is not supported by Conan, it is just that it is not present in the actual
defaults settings. You can find in your user home folder
~/.conan2/settings.yml a settings file that you
can modify, edit, add any setting or any value, with any nesting if necessary. See settings.yml to learn
how you can customize your settings to model your binaries at your will.
As long as your team or users have the same settings (
settings_user.yml an be easily shared with the
conan config install command), everything will work. The settings.yml file is just a
mechanism so users agree on a common spelling for typical settings. Also, if you think that some settings would
be useful for many other conan users, please submit it as an issue or a pull request, so it is included in future
It is possible that some built-in helper or integrations, like
CMakeToolchain will not understand the new added settings,
don’t use them or even fail if you added some new unexpected value to existing settings.
Such helpers as
CMake are simple utilities to translate from conan settings to the respective
build system syntax and command line arguments, so they can be extended or replaced with your own
one that would handle your own private settings.
This error can happen, if there are no or false authentication credentials in the HTTP request from conan. To get more information try enabling the debug level for HTTP connections:
import http.client http.client.HTTPConnection.debuglevel = 1
One source of error can be the
.netrc file, which is honored by the requests library.
ERROR: Obtaining different revisions in Linux and Windows¶
Git will (by default) checkout files in Windows systems using
CRLF line endings, effectively producing different files than in Linux that files will use
LF line endings. As files are different, the Conan recipe revision will be different from the revisions computed in other platforms such as Linux, resulting in missing the respective binaries in the other revision.
Conan will not normalize or change in any way the source files, it is not its responsibility and there are risks of breaking things. The source control is the application changing the files, so that is a more correct place to handle this. It is necessary to instruct Git to do the checkout with the same line endings. This can be done several ways, for example, by adding a
.gitattributes file to the project repository:
[auto] crlf = false
Other approach would be to change the
.gitconfig to change it globally. Modern editors (even Notepad) in Windows can perfectly work with files with
LF, it is no longer necessary to change the line endings.