I have been using CodeBlocks with the Digital Mars D compiler and the LLVM Clang compiler for some time without any problems. Now I need to use the LDC D compiler and am having problems with the linker invocation.
I get the following output:
-------------- Build: Debug in test (compiler: LLVM D Compiler)---------------
ldc2.exe -g -I"C:\Program Files\LDC\ldc2-1.13.0-windows-x64\bin" -c hello.d -of=obj\Debug\hello.o
ldc2.exe -L-L"C:\Program Files\LDC\ldc2-1.13.0-windows-x64\lib" -of=bin\Debug\test.exe obj\Debug\hello.o
Error: unrecognized file extension o
Process terminated with status 1 (0 minute(s), 0 second(s))
0 error(s), 0 warning(s) (0 minute(s), 0 second(s))
The compile step seems to work fine, but specifying ldc2.exe as a linker clearly fails.
Similarly, using ldmd2.exe and lld-link.exe in CodeBlocks' linker specification produce similar errors.
Any suggestions?
Looks like Code::Blocks is using the .o extension for object files on Windows, while the linker driver in the compiler frontend is probably expecting object files to have the .obj extension, which is more common on Windows.
I'm not familiar with Code::Blocks or how it interfaces with D compilers, but you can try checking to see if it has a setting to control what extension is used for object files. This may be a bug (or, simply, lacking Windows support) in whatever code is responsible for building D compiler command lines in Code::Blocks.
Related
In order to make use of newer C++ 17 and 20 features, I want to switch from Apple clang to a homebrew installed vanilla clang. I installed it via brew install llvm.
When trying to build a minimal CMake based test project like
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=/usr/local/opt/llvm/bin/clang -DCMAKE_CXX_COMPILER=/usr/local/opt/llvm/bin/clang++ -G Ninja testProject
CMake fails with
-- The C compiler identification is Clang 13.0.0
-- The CXX compiler identification is Clang 13.0.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /usr/local/opt/llvm/bin/clang
-- Check for working C compiler: /usr/local/opt/llvm/bin/clang - broken
CMake Error at /Applications/CLion.app/Contents/bin/cmake/mac/share/cmake-3.20/Modules/CMakeTestCCompiler.cmake:66 (message):
The C compiler
"/usr/local/opt/llvm/bin/clang"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /Users/me/Projects/testProject/build/CLion/Debug/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/local/bin/ninja cmTC_d2d4b && [1/2] Building C object CMakeFiles/cmTC_d2d4b.dir/testCCompiler.c.o
[2/2] Linking C executable cmTC_d2d4b
FAILED: cmTC_d2d4b
: && /usr/local/opt/llvm/bin/clang -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/cmTC_d2d4b.dir/testCCompiler.c.o -o cmTC_d2d4b && :
ld: library not found for -lSystem
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
So it seems that it fails to locate the correct library search path out of the box.
When trying to build a simple hello world program from the command line like
/usr/local/opt/llvm/bin/clang++ main.cpp -isysroot /Library/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk
It fails with even not finding some headers.
Supplying the header and library search path explicitly to the build command like
/usr/local/opt/llvm/bin/clang++ main.cpp -I"/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include" -L"/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"
makes it work. However, both are no solutions to make the built-in CMake compiler check work and they don't seem like the correct way to go.
Once this is working correctly, I'm furthermore interested in being able to compile ObjectiveC++ code which currently fails with even more errors.
I think I understand the problem that the compiler does not know the correct search paths, but I'm lacking some understanding about how it would normally figure out those search paths in a CMake project.
I finally managed to get it working by supplying a few linker flags through the LDFLAGS environment variable:
-L/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/usr/lib
In order to find the system libraries needed by the C compiler check
-L/usr/local/opt/llvm/lib
In order to find the C++ libraries as needed by the C++ compiler check
In order to successfully compile Objective-C code that links to Apple frameworks, I furthermore needed to add
-F/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/System/Library/Frameworks -lobjc
With those flags, I now can successfully build my projects. Still, I'm not 100% sure if this is the right way, especially if the libraries linked from /usr/local/opt/llvm/lib can be expected to be present on all target systems?
I want to run MinGW as a C compiler. MinGW has been installed from Chocolatey. Invocation is from gitlab-runner through CMake. This fails with
$ cmake -G "MinGW Makefiles" -DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc -DLIB_MAN=OFF -DCMAKE_INSTALL_PREFIX=C:\opt\x64 -B. ..
-- The C compiler identification is unknown
-- Check for working C compiler: C:/ProgramData/chocolatey/bin/x86_64-w64-mingw32-gcc.exe
-- Check for working C compiler: C:/ProgramData/chocolatey/bin/x86_64-w64-mingw32-gcc.exe -- broken
CMake Error at C:/Program Files/CMake/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message):
The C compiler
"C:/ProgramData/chocolatey/bin/x86_64-w64-mingw32-gcc.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/gitlab-runner/builds/zjE1Mkfg/0/mlz/kww/build/CMakeFiles/CMakeTmp
Run Build Command(s):C:/ProgramData/chocolatey/bin/mingw32-make.exe cmTC_ffa53/fast && C:/ProgramData/chocolatey/lib/mingw/tools/install/mingw64/bin/mingw32-make -f CMakeFiles\cmTC_ffa53.dir\build.make CMakeFiles/cmTC_ffa53.dir/build
mingw32-make[1]: Entering directory 'C:/gitlab-runner/builds/zjE1Mkfg/0/mlz/kww/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_ffa53.dir/testCCompiler.c.obj
C:\ProgramData\chocolatey\bin\x86_64-w64-mingw32-gcc.exe -o CMakeFiles\cmTC_ffa53.dir\testCCompiler.c.obj -c C:\gitlab-runner\builds\zjE1Mkfg\0\mlz\kww\build\CMakeFiles\CMakeTmp\testCCompiler.c
mingw32-make[1]: *** [CMakeFiles\cmTC_ffa53.dir\build.make:65: CMakeFiles/cmTC_ffa53.dir/testCCompiler.c.obj] Error 1
mingw32-make[1]: Leaving directory 'C:/gitlab-runner/builds/zjE1Mkfg/0/mlz/kww/build/CMakeFiles/CMakeTmp'
mingw32-make: *** [Makefile:120: cmTC_ffa53/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:6 (project)
-- Configuring incomplete, errors occurred!
See also "C:/gitlab-runner/builds/zjE1Mkfg/0/mlz/kww/build/CMakeFiles/CMakeOutput.log".
See also "C:/gitlab-runner/builds/zjE1Mkfg/0/mlz/kww/build/CMakeFiles/CMakeError.log".
ERROR: Job failed: exit status 1
From various web sources I understand that MinGW is bound to fail if sh.exe is present on the system [1]. However, sh.exe comes with several applications, among them Git and Visual Studio, which I cannot remove. Somewhere it's suggested to add -DCMAKE_SH="CMAKE_SH-NOTFOUND", which, however, has no effect.
I've seen a related question from 2015 [2], which however involves CLion. The only upvoted answer contains several broken links - altogether, that thread isn't helpful.
How to proceed? Is there a chance to work around the sh.exe problem?
Other advice on the web suggests to use -G "MSYS Makefiles". However, the CMake documentation [3] seems to rule this out: "not compatible with a Windows command prompt. To build under a Windows command prompt, use the MinGW Makefiles generator."
[1] https://stackoverflow.com/a/7411982/1017348
[2] CLion: Error:The C compiler "C:/MinGW/bin/gcc.exe" is not able to compile a simple test program
[3] https://cmake.org/cmake/help/latest/generator/MSYS%20Makefiles.html#generator:MSYS%20Makefiles per CMake 3.16.1
After long experimentation, I conclude that the problem comes from Chocolatey's packaging of MinGW. The problem is gone after I
uninstalled the MinGW package from Chocolatey,
reinstalled MinGW using the original MinGW installer,
installed the Ninja Chocolatey package,
inserted C:\MinGW\bin on top of PATH.
$ cmake -G "Ninja" -DLIB_MAN=OFF -DCMAKE_INSTALL_PREFIX=C:\opt\x64 -B. ..
-- The C compiler identification is GNU 8.2.0
-- Check for working C compiler: C:/MinGW/bin/gcc.exe
-- Check for working C compiler: C:/MinGW/bin/gcc.exe -- works
Also note:
There is no need for -DCMAKE_C_COMPILER=...
I did not try hard to get -G "MinGW Makefile" working; -G Ninja works just fine.
The sh.exe is only a problem when you run CMake the first time when trying to generate the project. You can rerun CMake again and CMake will continue with normal processing to generate the project (tested in version 3.16). I saw a patch that removes this check and should be part of a future release of CMake.
It's already mentioned that gcc is installed incorrectly. That always seems to be the case when anyone mentions that gcc fails with an Error 1 message. It should be noted that Error 1 is not from CMake. CMake is just gathering the output from when it runs mingw32-make to build the sample project.
The first message in the output -- The C compiler identification is unknown is a pretty clear message that your compiler isn't working. All of the output for this step is in the log and error files that CMake generates in the build folder. You'll be able to see how it invoked the compiler and with which options and the output from the compiler.
I am trying to cross-compile the Azure IoT SDK C for a Mips processor. Cross-compiling an older version of the same SDK using an older version of CMake (2.8.12.2) works just fine, so I doubt it's the code itself. I am guessing it's the Mips GCC compiler.
Error message:
CMake Error at /usr/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:52 (message):
The C compiler
"/usr/local/mipsisa32r2el/r23/bin/mipsisa32r2el-axis-linux-gnu-gcc"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTC_2cc84/fast"
/usr/bin/make -f CMakeFiles/cmTC_2cc84.dir/build.make CMakeFiles/cmTC_2cc84.dir/build
make[1]: Entering directory '/home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_2cc84.dir/testCCompiler.c.o
/usr/local/mipsisa32r2el/r23/bin/mipsisa32r2el-axis-linux-gnu-gcc --sysroot=/usr/local/mipsisa32r2el/r23 -o CMakeFiles/cmTC_2cc84.dir/testCCompiler.c.o -c /home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTC_2cc84
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_2cc84.dir/link.txt --verbose=1
/usr/local/mipsisa32r2el/r23/bin/mipsisa32r2el-axis-linux-gnu-gcc --sysroot=/usr/local/mipsisa32r2el/r23 -rdynamic CMakeFiles/cmTC_2cc84.dir/testCCompiler.c.o -o cmTC_2cc84
/usr/local/mipsisa32r2el/r23/lib/gcc/mipsisa32r2el-axis-linux-gnu/4.7.2/../../../../mipsisa32r2el-axis-linux-gnu/bin/ld: this linker was not configured to use sysroots
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_2cc84.dir/build.make:97: recipe for target 'cmTC_2cc84' failed
make[1]: *** [cmTC_2cc84] Error 1
make[1]: Leaving directory '/home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_2cc84/fast' failed
make: *** [cmTC_2cc84/fast] Error 2
Unfortunately, I am stuck with the Mips GCC compiler I have. Is there a way to disable this test-program check?
Solution was to add these to the toolchain-file:
SET (CMAKE_C_COMPILER_WORKS 1)
SET (CMAKE_CXX_COMPILER_WORKS 1)
CMake tries to compile an executable using "standard" (as per what CMake thinks is standard) compiler options and tries to run that executable, so to see if the compiler is working. The executable is simple like int main(int argc, char *argv[]) { return argc - 1; }.
You can't do that when cross-compiling. Because usually you can't link with a proper C standard library, you don't have printf, or _start or _exit or similar, passing arguments to main is implementation-defined, or you need a special linker script, or there's no emulator for your architecture, so can't run cross-compiled source on the host, etc... Simply: you usually can't run the cross-compiled executable on the host, and most of the time even the compilation is hard enough to do.
The common solution is to set before project():
set(CMAKE_TRY_COMPILE_TARGET_TYPE "STATIC_LIBRARY")
So that CMake will try to compile a static library not an executable, as explained in cmake docs CMAKE_TRY_COMPILE_TARGET_TYPE. This avoids running the linker and is intended for cross-compiling.
You can set CMAKE_C_COMPILER_WORKS and it will omit the check in CMakeTestCCompiler.cmake, but CMAKE_TRY_COMPILE_TARGET_TYPE is a more proper solution.
Well this problem is really annoying, i faced this issue for 2 day now I got solution.
Let me explain my issue first
When I delete NDK and Cmake from Sdk folder and Run my application then grable install NDK and Cmake again.
Only that time Application run and when try to run again i get this error The C Compiler is not able to compile a simple test program.
Before i was using ndkVersion "22.0.7026061" then change to thisndkVersion "21.1.6352462" and IT WORKED.
I think this is NDK problem and most of answer are outdated try this i hope this will HELP.
If using CMake GUI, you can add a boolean entry named
CMAKE_CXX_COMPILER_FORCED
then set it to True.
This will skip checking process for this build.
Ran into the same problem while re-compiling a project. Turned out that the compiler had been updated in the meantime.
After removing the build directory and creating it again, the compilation completed without errors.
I've recently downloaded CUDA 7 and set it up to work with my project. On Mac, CUDA 7 requires clang to be the host compiler.
Now, I'm using a number of C++11 features. I've enabled these with -std=c++11 passed to nvcc this works. However, if I pass -Xcompiler -std=c++11 to nvcc, I get the following error regardless of if I also passed -std=c++11 by itself. The error is:
"invalid argument '-std=c++11' not allowed with 'C/ObjC'"
It seems like this should work, it certainly does with GCC. Anyone have a workaround. Otherwise, I'll file a bug report with Nvidia.
nvcc -dryrun ... will show what commands nvcc will execute. I don't currently have access to CUDA 7, only 6.5, but mine issues, among other things, two commands that compiles generated C source. This code generated by cudafe and have to be compiled by C compiler, but -Xcompiler adds options for both C and C++ modes.
I guess difference with my gcc situation is that I'm getting a warning while you have an error (this is exactly how gcc and clang differs in that case). For both compilers I don't see any way to suppress it, so I guess you have to fix your .cmake files to omit -Xcompiler options. This options shouldn't be used for language standard, just some very compiler-specific things.
Of course it doesn't work. You are specifying C++ options while using a C or Objective-C compiler. The source files must be C++ or Objective-C++.
I am compiling a C file using the gcc flag -ffunction-sections, to move every function into it's own section. The assembler is throwing the error:
job_queue.s:2395: Error: operation combines symbols in different segments
The compiler's assembly output at line 2395 is given here:
.section .debug_ranges,info
.Ldebug_ranges0:
.4byte .LBB7-.Ltext0
The symbol LBB7 is in the function (and thus the section) named ".text.add_event_handler"
The symbol Ltext0 is in the (otherwise empty) section named: ".text"
GCC --version gives:
pic30-elf-gcc.exe (GCC) 4.0.3 (dsPIC30, Microchip v3_30) (B) Build date: Jun 29 2011
If I use the compiler flag -g0 (to turn off debug info) everything compiles and runs perfectly.
My question:
Is this GCC output clearly wrong? It seems to me that GCC should have calculated the symbol LBB7's offset from the beginning of the .add_even_handler section instead of the .text section.
I suspect I am misunderstanding something because I cannot find anyone having the same difficulty on the Google.
The GCC output is definitely wrong. Perhaps it's fixed in newer GCC versions. If you can't upgrade you compiler, try compiling with -gdwarf-2 or, failing that, with -gdwarf-2 -gstrict-dwarf (for -gstrict-dwarf you'll have to upgrade the compiler too).
What this option does is to instruct GCC to generate (strict) DWARF2, which does not include non-contiguous address ranges support, introduced in DWARF3.
Of course, this may degrade the debugging information quality somewhat, YMMV.