Conan does not detect MinGW gcc - conan

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.

Related

clion wsl "CMake 3.20 or higher is required. You are running version 3.16.3"

so I just downloaded wslusing the wsl --install command using PowerShell
now I'm trying to connect it to Clion which works
i cant add images so here is a link to it
but when i'm tying to build the project i get this error
"CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
CMake 3.20 or higher is required. You are running version 3.16.3"
my cmake file:
cmake_minimum_required(VERSION 3.20)
project(ex2 C)
set(CMAKE_C_STANDARD 99)
add_executable(ex2
ex2.c ex2.h
main1.c
main2.c)
i tried updating wsl using wsl --update (in powershell)
The CMake installation inside the WSL is used. Unfortunately currently snap doesn't seem to be available in WSL, but installing the latest CMake version isn't too complicated nonetheless:
(optional) uninstall the old cmake installation in WSL; personally I don't see any benefit in multiple CMake installations, but there may be valid reasons for this. Most likely this will just makes the use of cmake more complex, since you need to remember which cmake version is used.
Download the appropriate cmake version from the cmake website ( https://cmake.org/download/ ). The version to choose is the tar.gz file under binary distributions for the x86_64 target. To get version 3.21.4 (currently the latest release), you can download the file from https://github.com/Kitware/CMake/releases/download/v3.21.4/cmake-3.21.4-linux-x86_64.tar.gz (Identical to the link on the CMake download page).
Unpack the archive from WSL. Navigate to the directory where you want the cmake installation to recide. This will add the cmake-3.21.4-linux-x86_64 directory containing all the files required to work with cmake to the current working directory. Let's assume you want to add the cmake files to the /opt directory. Furthermore let's assume the windows user name to be fabian, C: to be the primary hard drive and the download to be saved to the Downloads directory in the user directory:
cd /opt
tar -xf /mnt/c/Users/fabian/Downloads/cmake-3.21.4-linux-x86_64.tar.gz
(optional) make CMake available without specifying the path; this could be done as described here: https://unix.stackexchange.com/questions/3809/how-can-i-make-a-program-executable-from-everywhere ; don't do this, if an existing cmake installation is already available in the command line assuming you did install cmake to /opt, the cmake binary recides at /opt/cmake-3.21.4-linux-x86_64/bin
You should now be able to use cmake specifying either the full path to the executable (/opt/cmake-3.21.4-linux-x86_64/bin/cmake assuming you used the /opt directory) or directly via a command after opening the WLS commandline again (provided you followed step 4).
Now the only thing left to do should be telling CLion about the location of the cmake executable. Note that I haven't tested this, since I don't use this IDE. It's working fine using Visual Studio Code though...

How do I build a CMake project?

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.

How do I run "conan init" and disable the warning about GCC ABI (libstdc++11) compatibility?

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.

Why won't find_library find libgmp

I'm trying to build a cmake project, and the repo I have been given has the lines
find_library(gmp gmp)
if(NOT gmp)
message(FATAL_ERROR "gmp not found")
endif()
which cause CMake configuration to fail.
I have been told this CMake works on Redhat Enterprise Linux 7.3.
I have also been told this repo should build in any Linux environment with the correct libraries installed, and an Ubuntu environment has been specifically referenced.
I am building in Debian 9.4.0, I have installed gmp, libgmp.so is located at /usr/lib/x86_64-linux-gnu/openssl-1.0.2/engines/libgmp.so
and I also have a libgmp.so.10 at /usr/lib/x86_64-linux-gnu/libgmp.so.10.
So, to recap, I have been handed a repo I have been told builds, but it does not build, it fails at this specific step, and I can't get google to give me any relevant results on how to fix the issue/what I am doing wrong.
libgmp is installed, but the development libraries are not.
Cmake find_libraries looks for the files required for software development, and while the libgmp package is installed, the libgmp-dev package is not.
Install libgmp-dev.
CMake doesn't search "so-version" files:
If find_library is called for "gmp" library name, CMake searches libgmp.so file, but not libgmp.so.10 one.
Normally, the library file without so-version is just a soft link to the newest so-version file. If your Linux distro doesn't create such link, you may create it manually:
ln -s libgmp.so libgmp.so.10
If you want CMake to find /usr/lib/x86_64-linux-gnu/openssl-1.0.2/engines/libgmp.so file, which is not under directory normally searched by CMake, you need to hint CMake about it. E.g. with PATHS option:
find_library(gmp gmp PATHS "/usr/lib/x86_64-linux-gnu/openssl-1.0.2/engines")

How to compile objdump for the m32c architecture

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>"