I am trying to report a bug for a project using Bazel. As part of the issue report I would like to include information about the used C++ compiler.
Which command can I use to do so?
bazel build -s //the_target shows me that external/local_config_cc/wrapped_clang seems to be the compiler. In bazel-<project>/... I can find that path, but running the executable wrapped_clang in there, just leads to an abort.
This answer only applies if you're using Bazel autoconfigured C++ toolchain. If you don't you'll have to modify it.
So for debugging the best would be to zip entire local_config_cc and also to provide version of the compiler ($CC --version). You get the local_config_cc at:
`bazel info output_base`/external/local_config_cc
Path to the compiler is written into the wrapped_clang script in case of the toolchain that supports both C++ and ObjC (this one gets enabled when Xcode is properly detected). C++ only toolchain invokes compiler directly (but the CROSSTOOL file can still be useful for debugging). And just in case, you can force C++ only toolchain by setting BAZEL_USE_CPP_ONLY_TOOLCHAIN=1 environment variable.
Related
I'm pretty new to C++ and I'm having a hard time trying to install external libraries. I want to get started with GUI programming and I have searched all over, but I cannot find a way to add wxWidgets to Code::Blocks. I've tried a few different guides and Stack Overflow responses but none of them have actually worked.
I'm using this 'Hello World!' test program to see if it works, every time I try to run it I just get this error: fatal error: wx/wxprec.h: No such file or directory. I can't seem to figure out how to tell Code::Blocks where the library is.
The most recent resource I have tried is this one, I followed it step by step, but still I got this error.
What linker/compiler settings do I need to use in Code::Blocks? What lib files do I need to add and where do I add them to? Do I need to build the .zip file? How do I do this?
Please could I get a step by step guide on exactly how to add wxWidgets (or indeed any external library) to Code::Blocks as well as some information on why certain things are required?
Here's what I tried
Following the steps in the link above, this is what I have in my build options:
I tried adding this in my global compiler settings...
I still have this error...
CodeBlocks seems to have some special wxWidgets integration, but it didn't always work for me, so I prefer to set up the project manually.
CB ships an outdated compiler. While it may work, updating it is a good idea.
Get rid of the MinGW version shipped with CB, or at least remove it from the PATH.
Install MSYS2. Use it to install a new GCC and GDB, as described in the link.
Configure CB to use MSYS2's GCC and GDB, by specifying the paths to them in the CB config (they're installed to C:\msys64\mingw64\bin).
wxWidgets seem to ship prebuilt libraries for MinGW, but since we're using MSYS2, we might as well use the version provided by MSYS2.
Use MSYS2 to install wxWidgets: pacman -S mingw-w64-x86_64-wxWidgets3.2-msw.
MSYS2 seems to ship several different versions of wxWidgets: 3.0, 3.1, 3.2, and each of them in two variants: -msw and -gtk. 3.2-msw looks like a reasonable choice to me, but I haven't used this library before.
wxWidgets doesn't seem to use the standard way of telling you what compiler flags to use (which would be pkg-config, or at least a CMake file). Instead they ship their own script to determine the flags, called wx-config.
Run wx-config --cflags to get the compiler flags, and run wx-config --libs to get the linker flags. Paste them into the project settings (compiler settings and linker settings respectively). Edit the project settings, not the global compiler settings.
Clion does not officially support Intel C++ compiler but I found the information that it suppose to work. I am just not sure how to correctly setup the toolchain. At the moment I am successfully using the clang compiler. Simply changing to icc compiler fails to compile a simple test program. Unfortunately I could not find any more guidance about setting up the icc compiler on Clion, could someone more experienced to share some insights?
Currently:
Want to use intel c++:
I am using cygwin compiler (make, gdb, gcc, g++) GNU Project. I am specifying Clion's path to cygwin (gcc, cmake, make, g++) in File -> Settings -> Build, Execution, Deployment -> Toolchain. Click me - image settings Clion
Update 2021-12-06
From 2021.3, you can use a System toolchain for this.
Set environment variable VS2019INSTALLDIR or VS2017INSTALLDIR
Create a System toolchain in CLion
Add environment from file %ONEAPI_ROOT%\compiler\latest\env\vars.bat
Set MKake as nmake, C Compiler and C++ Compiler as icx
Note that you can't use icl, as cmake will fail when getting compiler information.
Original answer
You need to edit some environment variables.
Add %ICPP_COMPILER20%bin\intel64 to PATH
Add %ICPP_COMPILER20%compiler\lib\intel64 to LIB; but mostly LIB does not exist, so create this variable
You may need to modify the 20 in %ICPP_COMPILER20% to match your installation.
With the above steps, you should be able to pass the compiler check. However, CLion will complain "Unexpected compiler output".
This means you can compile your program with no issue, but the IDE can't recognize any header file and simply marks them as "not found".
The existing code is calling some sort of wx header file and my DEV C++ compiler just says there's no such file.
Code:
#include<wx/wx.h>
Compiler error:
[Error] wx/wx.h: No such file or directory
So my question is -
What is wx.h
How do I install it in my compiler so that I can use it?
Do I need to change my compiler or DEV C++ would do fine?
What is wx.h
It is the header file of a library. The GitHub project should have some instructions on how to fetch the dependencies and how to install them.
How do I install it in my compiler so that I can use it?
Normally you have to download the dependency, build it (following some instructions), and then you need to use the header in your project and link the library. The exact steps depend on each library and each compiler.
Do I need to change my compiler or DEV C++ would do fine?
In principle, no. Some libraries only work with some compilers, though.
Note that Dev-C++ is not a compiler, it is an IDE that comes with a port of GCC (as far as I know).
It seems that you are using WxWidgets framework but your compiler doesn't know where to find its headers, and apparently also libs which you would face with on a next step.
You, need to add to your compiler flags the output of wx-config --cxxflags. And also to your linker flags the output of wx-config --libs.
Assumption is of course that WxWidgets is installed on your PC
How can you tell bazel to use a different C++ compiler on OS X?
bazel build --action_env CC=/path/to/compiler //:target
works on linux.
But -s shows that bazel always runs with external/local_config_cc/wrapped_clang (clang) on OSX regardless of what CC is.
CC correctly works only when you use the C++-only toolchain. If you have Xcode installed, bazel will detect this and automatically pick a different toolchain, the one that supports both C++ and ObjC. This toolchain can only use Xcode-provided clang.
This is unfortunate and I propose two solutions:
File a feature request for bazel to make it possible to select which toolchain is used. This will allow you to tell bazel that even though you have Xcode installed, you want to use C++ only toolchain with a custom compiler. This is quite simple and doable in a short time.
File a feature request for bazel to make it possible to select which compiler is used with C++/ObjC toolchain. I cannot comment on viability of this, I know next to nothing about osx, and I have no idea if it makes any sense to compile ObjC with a compiler that is not provided with Xcode...
Actually with the latest version of bazel specifying
BAZEL_USE_CPP_ONLY_TOOLCHAIN=1
build --action_env CC=/path/to/compiler [...]
does work, in the sense that the specified compiler is used. However there is still a problem with the compiler flags. If the compiler flags of the old compiler are incompatible with the new one, there is a problem. I still have to find out how to change compiler flags.
Use --crosstool_top.
See also --host_crosstool_top and --apple_crosstool_top.
I am building an open source project (kst, v2.0.8) that uses CMake. I am using CMake v2.8.12.2 and MSVC 2008 as a compiler and am generating NMake makefiles to build it on the command line. I can get it to build successfully with this setup. These versions are mandated so I cannot currently use a later version of CMake or MSVC.
I need to be able to perform a source code analysis of kst using HP's Fortify and to be able to use it from the command line it works in one of two ways:
Touchless mode where it creates it's own "cl.exe", sets the path to it before the path to the real cl.exe and therefore gets launched during build.
Set the compiler in the makefile to the Fortify command line, e.g. sourceanalyzer -b build_id cl instead of cl.
Either way I need to force the compiler that cmake generates into its makefiles to be something that cmake does not automatically detect.
I've tried setting the compiler when running cmake following the same method in this question but cmake still insists on putting the full path to the MSVC cl.exe in the makefiles.
cmake -DCMAKE_C_COMPILER=cl -DCMAKE_C_COMPILER_FORCED=ON -DCMAKE_CXX_COMPILER=cl -DCMAKE_CXX_COMPILER_FORCED=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=%CFITSIO_DIR% -G"NMake Makefiles" ..\cfit3250
I also tried setting the compiler to invoke Fortify but when cmake tests the compiler it fails saying that it cannot find the compiler. (I have also tried this without the FORCED=ON arguments and in that case it says the compiler fails.)
cmake -DCMAKE_C_COMPILER="sourceanalyzer -b %BUILDID% cl" -DCMAKE_C_COMPILER_FORCED=ON -DCMAKE_CXX_COMPILER="sourceanalyzer -b %BUILDID% cl" -DCMAKE_CXX_COMPILER_FORCED=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=%CFITSIO_DIR% -G"NMake Makefiles" ..\cfit3250
I could probably search and replace all the compiler invocations in the makefiles but I'd have to remember to do that after every cmake, and it would be tedious seeing as there are multiple projects / makefiles / calls to cl (rather than defining a CC variable in the makefile). I'd rather have a way to make cmake use the desired compiler right from the offset.
UPDATED: Testing showed the original suggested approach didn't work as expected on at least some platforms. It seems using a wrapper script is likely the way to go.
If you really want to force a particular compiler and by-pass CMake's compiler checks, the CMakeForceCompiler module may be what you are looking for. That link to the CMake docs contains a trivial toolchain file example which shows how to use a specific compiler invoked as a simple command with no path. Unfortunately, CMake still converts this to an absolute path, so on its own, this won't solve your problem. You could, however, use a toolchain file to point at a wrapper script and use CMakeForceCompiler to bypass the compiler checks. This combination should yield the behaviour you've asked for, but note that CMakeForceCompiler is now deprecated.
Note that when using the CMakeForceCompiler module, you take on a bit more responsibility for telling CMake information, notably the compiler ID of the particular compiler you want to force using, but from the CMake docs it seems pretty clear this will just be MSVC in your case.
To use a toolchain file, invoke CMake with a -DCMAKE_TOOLCHAIN_FILE=path/to/file option pointing at your own custom toolchain file. The CMake docs have a specific section covering the use of toolchains, although it does gloss over some of the important nitty gritty details.
As mentioned in #Tsyvarev's comment, the use of a wrapper script is likely to be your best way of dealing with this. That wrapper script just needs to forward the call to the usual compiler command without specifying a path. You then take responsibility for ensuring the command will be on your PATH when you do a build. Something as simple as the following should suffice as a wrapper batch file on Windows (untested):
cl %*
Now, you can control whether the Visual Studio compiler or Fortify gets invoked purely by the PATH the build sees. Personally, I think this is a bit fragile, but it's what you asked for. ;)
As a more robust alternative, is it possible to use two completely separate builds? If so, then I'd recommend that as a better alternative. Build one with the default Visual Studio compiler as normal and for the other build, use a toolchain file to point at the Fortify compiler to get CMake to bypass its compiler checks. That way you aren't relying on the build environment being set up a particular way.