Every time I run conan init in a fresh docker container, I get the following warning:
************************* WARNING: GCC OLD ABI COMPATIBILITY ***********************
Conan detected a GCC version > 5 but has adjusted the 'compiler.libcxx' setting to
'libstdc++' for backwards compatibility.
Your compiler is likely using the new CXX11 ABI by default (libstdc++11).
If you want Conan to use the new ABI for the default profile, run:
$ conan profile update settings.compiler.libcxx=libstdc++11 default
Or edit '/home/smith/.conan/profiles/default' and set compiler.libcxx=libstdc++11
************************************************************************************
It's annoying, and distracting. Redundant, too, since the very next command I run in the script is the one for setting the ABI, as suggested in the warning.
conan profile update settings.compiler.libcxx=libstdc++11 default
Is there a way to disable the warning, to avoid seeing it?
This warning can be skipped when CONAN_V2_MODE is on: e.g.:
conan:~$ export CONAN_V2_MODE=1
conan:~$ conan config init
WARN: Remotes registry file missing, creating default one in /home/conan/.conan/remotes.json
Auto detecting your dev setup to initialize the default profile (/home/conan/.conan/profiles/default)
Found gcc 9.2
gcc>=5, using the major as version
gcc C++ standard library: libstdc++11
Default settings
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=9
compiler.libcxx=libstdc++11
build_type=Release
*** You can change them in /home/conan/.conan/profiles/default ***
*** Or override with -s compiler='other' -s ...s***
But that variable also activates some other conan v2 options. You can read more here: https://docs.conan.io/en/latest/reference/conan_v2_mode.html
The best I've been able to find is to use more commands, and manually specify the values. But then I lose the auto-detection of the compiler type and version.
Instead of just:
conan init
I have to create a profile fill in the values:
conan profile new default
conan profile update settings.os=Linux default
conan profile update settings.os_build=Linux default
conan profile update settings.arch=x86_64 default
conan profile update settings.arch_build=x86_64 default
conan profile update settings.compiler=gcc default
conan profile update settings.compiler.version=9 default
conan profile update settings.compiler.libcxx=libstdc++11 default
conan profile update settings.build_type=Release default
Which is a lot of commands to run. If you are looking at that and thinking it's a good idea, I'd suggest also looking at conan config install, to load the profile from another file.
Related
I have just acquired an arbitrary CMake project from the internet and I am not sure how to compile it. What commands do I need to run to build it from the command line?
Basic steps
If you're on a Unix-y operating system, like Linux or macOS, then you would run:
$ cmake -DCMAKE_BUILD_TYPE=Release -S /path/to/source-dir -B /path/to/build-dir
$ cmake --build /path/to/build-dir
Here, /path/to/source-dir is the directory containing the root-level CMakeLists.txt, this is most commonly the root of a source control repository. Meanwhile, /path/to/build-dir is a distinct directory (that does not need to exist yet) that CMake will use to store the generated build system and its outputs. This is called an out-of-tree build. You should never attempt an in-tree build with CMake because of the possibility of name clashes and difficulty involved with cleaning up the generated files.
When building with a single-config generator (like Make, which is the default on Unix), you specify the build type by setting the CMAKE_BUILD_TYPE variable in the first command, known as the configure step. You must always set this variable when working with a single-config generator. The built-in configs are Debug, Release, RelWithDebInfo, and MinSizeRel. See this answer for more detail on this.
After the configure step, you may build the project by either calling the underlying build tool (in this case, make) or by calling CMake's generic build launcher command (cmake --build), as I do here.
If you're on Windows, then the default generator is Visual Studio, which is a multi-config generator. This means the build type is chosen during the build step rather than the configure step, and the commands must be adjusted accordingly:
$ cmake -S /path/to/source-dir -B /path/to/build-dir
$ cmake --build /path/to/build-dir --config Release
These steps assume that the CMake build you are looking at is well behaved. If a project fails to build with the above steps and you have all of its dependencies installed to system locations (and they are well behaved), then you should open an issue with the upstream project. The most common source of bad behavior in mature CMake builds is dependency handling. Too often you will have to read the build or its documentation to determine which variables need to be set (via -D, like we did with CMAKE_BUILD_TYPE above) for the project to find its dependencies.
Advanced topics
Setting options and cache variables
Some projects offer options to enable/disable tests, components, features, etc. These are typically done by writing entries to the CMake cache during the configure step. For example, a common way to disable building tests is to set BUILD_TESTING to NO at the command line:
$ cmake -S /path/to/source-dir -B /path/to/binary-dir [...] -DBUILD_TESTING=NO
This particular variable is a convention, but is not guaranteed to be honored. Check the project's documentation to see which options are available.
Selecting a generator and toolchain
When using the Visual Studio generators specifically, you can tell CMake which platform you wish to target and which version of the compiler you would like to use. The full form of the CMake configure command for this is:
$ cmake -G "Visual Studio 16 2019" -A <ARCH> -T<TOOLSET> [...]
Valid values of <ARCH> include Win32, x64, ARM, and ARM64. If <TOOLSET> is not specified, then the 32-bit MSVC compiler will be used. Typically, you will want this to be host=x64 to ensure that 64-bit MSVC is used, which can allocate more memory for large linking steps. You can also set <TOOLSET> to ClangCL to use the Visual Studio provided ClangCL tools.
On all generators, CMake sniffs the environment for which compiler to use. It checks the CC and CXX environment variables for the C and C++ compilers, respectively. If those are empty, it will look for cc and c++ executables in the PATH. You can manually override the compilers by setting the CMAKE_C_COMPILER and CMAKE_CXX_COMPILER CMake cache (not environment) variables at the CMake command line (using -D again).
Installing & using dependencies
Once a CMake project has been built, you may install it either systemwide or (preferably) to a local prefix by running:
$ cmake --install /path/to/build-dir --prefix /path/to/install-dir [--config Release]
Where --config is only required if a multi-config generator was used. Once installed to a local prefix, a project that depends on it may be configured by setting CMAKE_PREFIX_PATH to /path/to/install-dir.
I try to create conan package of boost library.
I got the recipe from https://github.com/conan-io/conan-center-index/tree/master/recipes/boost
When I execute command:
conan create . conan/stable
next error will appeared:
ERROR: conanfile didn't specify version
I see, that in recipe no version member, but I don't understand how to specify it manually in that case. And no any hint from official docs on conan create page(
Indeed the version is not listed in the recipe, but why? Because the same recipe is re-used for any version, so Conan Center Index don't need to replicate the same recipe for each new version.
All versions supported by Boost are listed in conandata.yml, which is a file with the download link and the checksum, according the version.
Thus, to build the desired version, you have to pass it with the command like. For instance, to build Boost 1.73:
cd recipes/boost/all
conan create . 1.73.0#
Note that I only passed the version, not the namespace (username/channel), because it's an official recipe from Conan Center Index, any other recipe should contain the namespace to avoid any conflict. In this case, you can use your namespace too, if you want:
cd recipes/boost/all
conan create . 1.73.0#hdnn/stable
The version in recipe is not mandatory, even without conandata.yml. When any mandatory attribute is missing (name or version), you can pass them by command line.
Conan does not auto-detect MinGW compiler while creating package. Please refer below error:
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
ERROR: : 'settings.compiler' value not defined
SOLUTION 1
using the conan dev packages you can install msys2 or mingw64.
Conan has setup some bins you can clone via build requires. These work like pre-requisites meaning any machine that uses the conan profile with these will get them installed. This would mean you would get another self container mingw, and msys inside your conan packages (home/.conan/data/ blah blah).
[build_requires]
mingw_installer/1.0#conan/stable
msys2/20190524
[settings]
os_build=Windows
os=Windows
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=4.9
compiler.libcxx=libstdc++11
compiler.threads=posix
build_type=Release
Credits to AvadhanaSolutions
SOLUTION 2
The reason that it is not working is because not only does the toolchain need to be set for gcc,g++ but also the target and generator need to be defined. This needs to be clear to both conan, and cmake. In this case cmake cannot find these toolchains.
Given that the recommended install locations for mingw and msys binaries are to not place in "Program Files". The install location is variable from one person to the next. Given that variability we need to ensure two things to generate successful builds. The following would not only apply for gcc but also for other tools like clang
Steps
Find path for gcc,g++, and make for your machine.
(careful to ensure that you have the full names)
#!/bin/bash
echo "Find Gcc,G++ and mingw make then append these to a conan profile"
which gcc
which g++
which make
Which will return something like
/c/msys64/mingw64/bin/gcc
/c/msys64/mingw64/bin/g++
/c/msys64/usr/bin/make
Add environment variables to the conan install profile.
(ie my conan file has)
[env]
CC=C:/msys64/mingw64/bin/gcc
CXX=C:/msys64/mingw64/bin/g++
Define the Generator for Cmake. Here we need to setup the equivalent to the CMake command cmake .. -G "MinGW Makefiles. By default conan uses Unix Makefiles unless your running windows ;) then it just uses whatever cmake applies as the default generator. Therefore, if you want to use mingw make files that needs to be defined and passed to cmake manually. (found this in the conan documentation here. But note that the conanfile on that page is somewhat incomplete. In the end you have to add other elements from your default conan profile to the conan profile you will be using for building to target the MinGw platform using the mingw toolchain.
toolchain=C:/msys64/mingw64/bin
target_host=x86_64-w64-mingw32
cc_compiler=gcc
cxx_compiler=g++
[env]
CONAN_CMAKE_FIND_ROOT_PATH=$toolchain
CHOST=$target_host
AR=$target_host-ar
AS=$target_host-as
RANLIB=$target_host-ranlib
CC=$target_host-$cc_compiler
CXX=$target_host-$cxx_compiler
STRIP=$target_host-strip
RC=$target_host-windres
[settings]
#We are cross-building to Window
[settings]
os=Windows
os_build=Windows
arch=x86_64
arch_build=x86_64
compiler=gcc
build_type=Release
compiler.libcxx=libstdc++11
compiler.cppstd=20
compiler.version=10
[options]
[env]
CC=C:/msys64/mingw64/bin/gcc
CXX=C:/msys64/mingw64/bin/g++
Note that the CC, and CXX toolchain variables are duplicative, but I honestly don't care. I want to tell windows and cmake in as many ways as possible to use those.
In the end, it is probably easiest to think of this as "Cross Compiling" because the default installs of cmake, path variables, and the windows platform is not setup to compile using non-windows compilers. This page (newer) from conan describes how this can be defined on a windows machine. There is a bit of background at the top, but it is helpful to understand the landscape of what is going on between these tools.
In the end... after all of this, I am going to take a look at ninja because it appears that it will improve my quality of life. I am also going to switch to a conanfile.py instead of a conanfile.txt because the documentation is better for these.
The issue can be resolved by updating default profile or create a new profile for MinGW.
Update default profile:
conan profile update settings.compiler=gcc /path/to/profile
conan profile update settings.compiler.version=9.2 /path/to/profile
conan profile update settings.compiler.libcxx=libstdc++11 /path/to/profile
Create new propfile at path .conan/profile/
[build_requires]
mingw_installer/1.0#conan/stable
msys2/20190524
[settings]
os_build=Windows
os=Windows
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=4.9
compiler.libcxx=libstdc++11
compiler.threads=posix
build_type=Release
Note:
You need to add MinGW/bin path in windows environment.
Developer can choose compiler version as per their installation.
I'm trying to understand how I can use the CMake user package registry to support multiple builds, for example a Debug and a Release build.
I have a package1, which properly calls export(PACKAGE package1) so it registers the build directory with CMake's user package registry. I then proceed to creating 2 separate build directories, one for Debug and one for Release (note that I made the version for the Debug build 3.0.2000000, while the version for the Release build is 3.0.1000000, because I wanted CMake to prefer the Debug build in my use case). As expected, each of these builds registered an item in the registry:
> ls ~/.cmake/packages/package1/
212e973d0f1858e4bdf95b9d105bed5a 78094ed9b729d420c3f782cd8e668e64
Now in a different project, package2, I use find_package(package1 3.0.740) but it only ever finds the one in the Release build. I tried inspecting the package1_CONSIDERED_CONFIGS and package1_CONSIDERED_VERSIONS right after calling find_package but again only the Release build's config and version are there.
The code in package2's CMakeLists.txt file:
SET(CMAKE_FIND_PACKAGE_SORT_ORDER NATURAL)
SET(CMAKE_FIND_PACKAGE_SORT_DIRECTION DEC)
message("CMAKE_FIND_PACKAGE_SORT_ORDER="
"${CMAKE_FIND_PACKAGE_SORT_ORDER}")
message("CMAKE_FIND_PACKAGE_SORT_DIRECTION="
${CMAKE_FIND_PACKAGE_SORT_DIRECTION}")
find_package(package1 3.0.740)
message("Considered Configs: ${package1_CONSIDERED_CONFIGS}")
message("Considered Versions: ${package1_CONSIDERED_VERSIONS}")
Result of CMake running above code:
cmake ../..
-- Using link pool size - 16 jobs
CMAKE_FIND_PACKAGE_SORT_ORDER=NATURAL
CMAKE_FIND_PACKAGE_SORT_DIRECTION=DEC
Considered Configs: /path/to/package1/Release/package1Config.cmake
Considered Versions: 3.0.1000000
What am I doing wrong? How is the user registry supposed to be used?
I would like to use objdump to view binary m32c files. When I type in: objdump -i the architecture list returned is i386 based. Looking at the source code from binutils it appears that the m32c architecture is supported, just not compiled in by default.
I've also seen arm-none-eabi-objdump for the embedded ARM market. What I would like to create is a compiled version of objdump for the m32c architecture. Has anyone done something similar?
Building binutils for a specific target is pretty straightforward. If binutils is to be hosted on Windows, you will need to install MinGW/GCC and the Msys shell environment. Then from within a Linux bash shell or msys on Windows:
Create a directory to build the tools ()
Create a directory to which to install the tools ()
Extract the binutils package into , hereafter refers to the binutils verion you are building, and is indicated in the package name (binutils-.tar.bz2)
Working from , configure the package for the appropriate target and host:
../binutils-<version>/configure --target m32c-elf --prefix <installdir>
In Windows you can also add to the configure command line --enable-win32-registry=gnu_m32c to allow path lookup via the registry. The toolchain name gnu_m32c is arbitrary - you can call it what you like.
Run make to build the tools.
Run make install-strip to install the tools.
Note:
If you are installing on Windows and used the --enable-win32-registry option but subsequently choose to move the installation, or are installing your pre-build tools on a new host, you will need to modify the registry to match; this can be done in regedit editing the key HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\gnu_m32c, adding/modifying the item:"BINUTILS"="<installdir>" if you have installed GCC as well there are related keys:
"GCC"="<gccinstalldir>"
"G++"="<gppinstalldir>"