I use C++ with Code::Blocks. I like Code::Block, but I can't make resource compiler get working... My test setup is very simple.
**in MoviesList.rc file:**
#include "MoviesList.h"
IDR_TEXT1 RCDATA "C:\\_C++\\PROJECTS\\test2\\MoviesList.txt"
**in MoviesList.h file:**
#define IDR_TEXT1 101
**in main()**
{
HRSRC resInfo = ::FindResource(0, MAKEINTRESOURCE(IDR_TEXT1), RT_RCDATA);
return 0;
}
I get this compile error all the time:
x86_64-w64-mingw32-windres.exe -J rc -O coff -i C:\_C__~1\PROJECTS\test2\MOVIES~1.RC -o obj\Debug\MoviesList.res
Execution of 'x86_64-w64-mingw32-windres.exe -J rc -O coff -i C:\_C__~1\PROJECTS\test2\MOVIES~1.RC -o obj\Debug\MoviesList.res' in 'C:\_C++\PROJECTS\test2' failed.
Nothing to be done (all items are up-to-date).
Compiler setup is the following:
C compiler: x86_64-w64-mingw32-gcc.exe
C++ compiler: x86_64-w64-mingw32-g++.exe
Linker for dynamic libs: x86_64-w64-mingw32-g++.exe
Linker for static libs : x86_64-w64-mingw32-ar.exe
Resource compiler: x86_64-w64-mingw32-windres.exe
Make program: mingw32-make.exe
When I go to project's Properties and then to Build Targets I see that main.cpp and MoviesList.rc are checked, which should be correct... I have Mingw version 4.8.1 and Code::Blocks version is 12.11. All things including Boost work fine, except for the resource compiler.
UPDATE
After changing from x86_64-w64-mingw32-windres.exe to windres.exe the build has produce no errors.
There is no x86_64-w64-mingw32-windres.exe in MinGW/bin, just windres.exe.... I
Entry for the resource compiler has been incorrect.
Code::Blocks is an IDE that invokes the compiler, linker and other tools like the resource compiler. The output of these tools is catched and displayed in the output window.
When you don't get any output from one of these tools you should take the build log and start the tools with the parameter you found in the build log. This might help to isolate the problem.
Additionally you could change the parameters. e.g tell the compiler to stop after preprocessing to look at the preprocessed output. Similar options may exist for the resorce compiler.
Related
I am currently using clang11 on ubuntu to compile any c/c++ code and it works fine but when I tried to compile any code (including any standard library) to assembly code for any specific target like x86_64 (even I have x86_64) riscv with giving a flag that --target=x86_64 or --target=riscv32 I got errors for any standard library that I included in my code. A simple example:
// ex.cpp
#include<iostream>
int main(){
int a = 5;
int b = 3;
std::cout << a - b;
}
Without giving flag for a spesific target works fine:
clang++-11 -S ex.cpp -o ex.s
With --target=riscv32 flag:
clang++-11 --target=riscv32 -S ex.cpp -o ex.s
gives this error:
ex.cpp:1:9: fatal error: 'iostream' file not found
also without standard libraries gives no error even I give a spesific target.
I am searching for a solution for days but I couldn't find any proper solution for this problem, most of them says try to include gnu libraries and subfolders like -I/usr/include/x86_64-linux-gnu/c++/ but it doesn't work for me.
Please don't say use g++ compiler, for adding an optimization I need clang.
Actually I am trying to compile my codes for riscv target, linking with g++ and running with spike (doesn't differ --target=... or -target ...):
clang++-11 -target riscv32-unknown-elf -march=rv32gc -fno-addrsig -S ex.cpp -o ex.s
~/riscv/bin/riscv32-unknown-elf-g++ ex.s -o ex
~/riscv/riscv-isa-sim/build/spike --isa=RV32GC ~/riscv/riscv-pk/build/pk ex
And it works fine without include a standard library.
Now, I want to ask that
Can I solve this problem simply?
or
Can I use clang directly from riscv bin utils like ~/riscv/bin/riscv32-unknown-elf-clang++ (I saw something like this on the net but couldn't find) adding and building a submodule to my riscv directory?
Edit: As #NateEldredge said, for x86_64 target triple should --target=x86_64-linux-gnu but for riscv as a target triple riscv32-unknown-elf I still have the same errors. Is there a proper target flag for riscv any other than --target=riscv32-unknown-elf? Maybe I am missing that point.
I solved my problem by linking compilations with riscv-gnu-toolchain built and also answered a similar question here in detailed: Using Clang to compile for RISC-V
Simply we need cross-compilation.
Further information you can also look here: https://github.com/lowRISC/riscv-llvm#how-can-i-build-upstream-llvmclang-and-use-it-to-cross-compile-for-a-riscv32-target
I am using Eclipse Luna in a Windows environment to write programs in C++. I compile with MinGW. I am also using OpenCV and libxml2.
My programs get compiled with these include paths:
g++ "-IC:\\MinGW\\include\\libxml2" ...
However, I need include paths for libxml, so what I want is:
g++ "-IC:\\MinGW\\include\\ibxml2" "-IC:\\opencv\\build\\include"
I tried to set this up under "project | Propterities | Tool Settings | GCC C++ Compiler" in the project properties:
-I"C:\opencv\build\include" -I"C:\MinGW\include\libxml2" -O0 -g3 -Wall -c -fmessage-length=0 -v
However, it only puts the first one in the actual compile command, according to the console.
It does work sometimes, though:
If I "Clean" the project and the build it, it will build without errors and even run from Windows Explorer or a prompt.
If I try to Run or Debug it from Eclipse, it will fail and have the problems described above.
If I "Clean" it and Run or Debug it, it will run fine in the Debug perspective, but will terminate without warning.
I wanted to use latest g++ compiler(4.9.1) on suse linux, but suse only supports an older g++ version. So, I took a latest source code from one of the gnu mirror sites and compiled it myself. Everything went fine. But when I tried to compile my test code using the built g++, the compilation fails with error,
"/root/home/include/c++/4.9.1/x86_64-unknown-linux-gnu/bits/os_defines.h:39:22: fatal error: features.h: No such file or directory".
I can find a "features.h" in "/root/home/include/c++/4.9.1/parallel", but I feel that it should be there in "/root/home/include/c++/4.9.1/" itself.
I copied "/root/home/include/c++/4.9.1/parallel/features.h" to "/root/home/include/c++/4.9.1/" just to see what happens. Now it complains with error "whcar.h" not found.
Have I missed something.
Here are the steps I followed to build g++.
1. /root/home/gcc_build/objdir# ../gcc-4.9.1/configure --prefix=/root/home/ --disable-multilib
2. /root/home/gcc_build/objdir# make -j16
3. /root/home/gcc_build/objdir# make install
4. /root/home/gcc_build/test# /root/home/bin/g++ --sysroot /root/home -m64 test.cpp
I resolved the issue by removing sysroot option and pointing c++ include and library path to my home directory. One thing I noticed was that the g++ source does not come with libc and c header files, and libc has to be installed seperately. But with sysroot option, g++ was trying to look all the header files in my home directory.
Below is the command I used to successfully compile the code.
/root/home/bin/g++ -I /root/home/include/c++/4.9.1 -L /root/home/lib64 -Wl,--rpath=/root/home/lib64 --std=c++0x -m64 test.cpp
Take a look at the GCC Directory Options. It is important to use the correct "specifier" as well (-isystem, -L, -B, -I etc)
I have a cpp file which I am able to compile from command line using:
clang++ main.cpp -O2 -larmadillo
or by using g++ compiler via
g++ main.cpp -O2 -larmadillo
My question is how can I compile main.cpp in Xcode 5.1.1?
Here is what I tried:
1) Project -> Build Settings -> Other C++ flags -> added '-O2 -larmadillo' there
2) Target -> Build Settings -> Other C++ flags -> added '-O2 -larmadillo' there
Neither helped.
I am new to this linking/compiling magic so I don't know where to go from here.
clang++ and g++ can act as both compilers and as compiler drivers. When you run them from the command line as a compiler driver they internally handle running all the steps for getting an executable, including compiling, assembling, and linking.
But when Xcode is doing the build it instead expects to run clang as a compiler and to handle linking separately. So passing a linker flag in 'Other C++ flags' is basically like doing:
// compile step (no linking)
clang++ main.cpp -O2 -larmadillo -c
// linking step (error, missing library)
clang++ main.o
So what you need to do is change the build settings so that Xcode knows that it needs to link in that library when it gets to the linking step. A quick and dirty way would be to add the linker flag to 'other linker flags' (and to set the library search paths appropriately), but it would be better to edit your target's 'Build Phases" and update the "Link Binary with Libraries" with the appropriate library. You may also need to change the SDK in the target's build settings to 'Current Mac OS', so that Xcode will use whatever libraries you've installed rather than strictly limiting it to what's available in a default OS X install.
Today i got the most generic compile error for Dev-C++ ever
Compiler: Default compiler
Building Makefile: "C:\projects\Makefile.win"
Executing make...
make.exe -f "C:\projects\Makefile.win" all
g++.exe -c test.cpp -o test.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include" -I"C:/SDL-1.2.15/include"
make.exe: *** [test.o] Error 255
Execution terminated
and that's it. I googled around online but usually you can see some other type of errors follow it within the compile log but no in my case. Anyone help. I am running this on window 8
Please update your IDE to the following version, which fixes an immense list of bugs, ships with GCC 4.6.1 or 4.7.0, and is fully portable: http://sourceforge.net/projects/orwelldevcpp/
That would be the number one fix to try and fix this problem regarding the automatically generated makefile. Chances are the updated version will fix your makefile problems.
You could also open up the auto generated makefile yourself and:
Go to Project >> Project Options >> Makefile and tick "use custom makefile".
Try to fix the makefile manually.
???
Rebuild.
Profit.
If this option was previously left unticked, you are sure either the old Dev-C++ made an error creating the makefile or the bundled compiler got broken for some reason.