I just installed Code::Blocks (version 20.03) on my computer (Windows) , with Mingw.
I created a new project ==> Console application ==> with C++ ==> Compiler GNU GCC Compiler
In my main.cpp I have a simple program :
#include <iostream>
using namespace std;
int main()
{
cout << "Hello world!" << endl;
return 0;
}
When I try to compile and run it , I have this error :
c:\mingw\lib\gcc\mingw32\8.2.0\include\c++\cwchar:44:10: fatal error: wchar.h: No such file or directory
I don't understand it because I have installed Code Blocks with Mingw.
Please can you help me ? How can I resolve this issue ?
Thank you in advance.
I stay available if you need more information.
I resolved the issue by removing C:\MinGW folder
then I modified the path to MinGW in
Settings ==> Compiler ==> Global Compiler Settings ==> Toolchain executables ==> Compiler's installation directory
Then I put the MinGW of Code::Blocks
C:\CodeBlocks installation directory\CodeBlocks\MinGW
Then it worked
Maybe it can help others
Related
I have a test cmake C++ app, that I can compile successfully with clang++-10 on Ubuntu 20.04 (with all that CMAKE_USER_MAKE_RULES_OVERRIDE machinery).
The layout of the cmake project is:
./test.cpp
./CMakeLists.txt
./build
I also create the build database json file with CMAKE_EXPORT_COMPILE_COMMANDS inside ./build (this json file is necessary for the clang-check operation AFAIU).
Now, launched from the build dir, the check invocation fails:
clang-check-10 --analyze ../test.cpp
<projDir>/test.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
^~~~~~~~~~
1 error generated.
Error while processing <projDir>/test.cpp.
Any ideas how to fix this?
Edit: Have also tried specifying -p=$(pwd) to clang-check, but it still could not find the header.
clang-check is not a compiler. It's used for checking error in AST, and in this case it can't find the system header in your code. Add '--' in the end of line to ignore it.
clang-check-10 --analyze ../test.cpp
For more information: ClangCheck on LLVM
So I installed MINGW which is now present in C:\MinGW\bin and contains the g++ files and make file. I also added into Properties-> Advanced setting -> Environment path -> Path -> "C:\MinGW\bin". When I open the prompt to execute g++ with the following file:
#include <iostream>
using namespace std;
int main() {
cout << "!!!Hello World!!!" << endl; // prints !!!Hello World!!!
return 0;
}
The message is the following:
"g++ has stopped working"
I am using windows10. And even when I try to get the version of the compiler, the same error message appears.
Your help is fully appreciated.
Regards,
Cyril
I solved the issue doing the following: After creating a project with MinGW compiler, go find the real folder of MinGW which was not C:\MinGW\bin for me but rather C:\Program Files (x86)\mingw-w64\i686-6.3.0-posix-dwarf-rt_v5-rev1\mingw32\bin.
Then click right on your project in Eclipse -> Properties -> C++ Build -> Environment -> Change the path of MinGW and MinGW home with the appropriate folder. And voila!
I'm performing the (terrifying) task of building LLVM 3.3 on windows and I have got to the stage where I have a load of LLVM*.lib files. I want to link them together to one huge shared DLL but am struggling (this is my first time linking stuff on windows). I've tried:
link /DLL /MACHINE:X64 /OUT:LLVM3.3.dll LLVM*.lib
but to no avail. It errors with:
LINK : warning LNK4001: no object files specified; libraries used
LINK : error LNK2001: unresolved external symbol _DllMainCRTStartup
LLVM3.3.dll : fatal error LNK1120: 1 unresolved externals
The internet suggested adding the /DEFAULTLIB:corelib switch, so I did that but again it has problems:
> link /DLL /MACHINE:X64 /DEFAULTLIB:corelibc /OUT:LLVM3.3.dll LLVM*.lib
LINK : warning LNK4001: no object files specified; libraries used
LINK : fatal error LNK1104: cannot open file 'corelibc.lib'
How do I do this?
EDIT: I managed to fix the above problem, by implementing an empty DllMain and making an EmptyDllMain.obj from it:
#include <windows.h>
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
return TRUE;
}
and then trying:
link /DLL /OUT:LLVM3.3.dll LLVM*.lib EmptyDllMain.obj
but the DLL I get out is just 8kb - it seems to have missed out the many megabytes of LLVM libraries! How do I get them included?
EDIT2: I solved the LLVM compilation on Windows problem, take a look at this document on github.
I had this once while linking one lib with a wrong platform set together (X86 to X64). Make sure all the LLVM*.lib are build and linked with the correct toolchain:
[...]\Microsoft visual Studio 10.0\VC\bin\amd64\ cl.exe and link.exe
which you get by calling
"%PROGRAMFILES(X86)%\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" amd64
Also I had similar problems when mixing MT and MD CRTs, I recommend you stick to
/MD (or /MDd for debug)
when compiling the objects for any of the LLVM*.lib (and any other objects from other external libraries you link into these).
[edit]
And kick out that ugly EmptyDllMain.obj !
[/edit]
If you manually entered the _DllMainCRTStartup, be sure you spelled it (watch case) correctly. I had _DLLMainCRTStartup and took a while to catch why I still received the linker error. For Windows CE, the required link lib is corelibc.lib.
remove lib files from "ignore specific default libraries" from "Linker->Input" on project properties
I want to have local installation (in my home-folder (Linux), say $HOME/boost) of the boost C++ libraries in addition to a system-wide installed default of the boost libs. I built them from sorce and that worked fine.
After that, I set the environment variables CPLUS_INCLUDE_PATH and LD_LIBRARY_PATH to match the destination of the local installation, so both pointing to $HOME/boost/include and $HOME/boost/lib/, respectively.
In order to test that, I used the following code for testing the correct usage of CPLUS_INCLUDE_PATH for the headers:
#include <boost/version.hpp>
#include <iostream>
#include <iomanip>
int main()
{
std::cout << "Boost version: " << BOOST_LIB_VERSION << std::endl;
return 0;
}
Compiling it with g++ -o Test_boost_version test_boost_version.cpp works as expected, reporting the expected (local) version. Having CPLUS_INCLUDE_PATH empty gives me the boost-version of the default, system-wide installation. So far so good.
In order to test the linking, I used the following code (taken from the boost homepage:
#include <boost/regex.hpp>
#include <iostream>
#include <string>
int main()
{
std::string line;
boost::regex pat( "^Subject: (Re: |Aw: )*(.*)" );
while (std::cin)
{
std::getline(std::cin, line);
boost::smatch matches;
if (boost::regex_match(line, matches, pat))
std::cout << matches[2] << std::endl;
}
}
and built it with g++ -o Test_boost_linking test_boost_linking.cpp -lboost_regex.
Calling ldd Test_boost_linking however does NOT make use of the local installation (provided via LD_LIBRARY_PATH) but gives me: libboost_regex.so.1.42.0 => /usr/lib/libboost_regex.so.1.42.0 (0x00007f9264612000)
When I use g++ -o Test_boost_linking test_boost_linking.cpp -lboost_regex -L$HOME/boost/lib, ldd is reporting the correct library (libboost_regex.so.1.50.0 => $HOME/boost/lib/libboost_regex.so.1.50.0 (0x00007f6947d2a000)).
This is actually a problem for me since I want to set up my local environment such that a compilation will ignore the system-default boost installation and only use the local installation and I thought this is exactly what is achieved when setting the CPLUS_INCLUDE_PATH and LD_LIBRARY_PATH, but for the latter, this seems not to hold true.
So how can I make sure that using g++ -o Test_boost_linking test_boost_linking.cpp -lboost_regex (without -L) uses the local libraries?
[EDIT] Thinking of it further, I am wondering IF it is actually absolutely mandatory to use "-L$HOME/boost/lib" in the command-line (using LDFLAGS as environment variable seems to have no effect, probably just in combination with a Makefile) when using libraries in a non-standard directory?? Is this the case?
(BTW I think this will hold true also for other libraries, not only boost...)
(I used: g++ (Debian 4.4.5-8) 4.4.5)
Thank you.
You need to use the environment variable LIBRARY_PATH to let gcc know where to find the libraries at link time. LD_LIBRARY_PATH lets the program know where to find the dynamic libraries at runtime. This answer has more details. These links from "An Introduction to GCC" may also be useful: Compilation options:Environment Variables and Shared and Static Libraries
If I compile this QT c++ program in SuSE Linux
#include <iostream>
using namespace std;
int main ()
{
cout << "Hello World!";
return 0;
}
When I type
i386-mingw32-g++ helloworld.cpp
I get the following error
i386-mingw32-g++: error trying to exec 'cc1plus': execvp: No such file or directory
Is this because MinGW package which i installed contains only gcc in it.. hence i downloaded gcc-g++-3.4.5.rpm package and just copy pasted i386-mingw32-g++ and cc1plus executable along with C++ include files.
Pls reply.
Thanking You
Ugh. The cc1plus in gcc-g++-3.4.5.rpm is not for mingw32. You need the one for your distro.
e.g. for Fedora 10, use http://sourceforge.net/projects/outmodedbonsai/files/Mingw%20Cross-compiler/mingw-1.10-1.fc10.x86_64.rpm
Quoting from here:
It means that your shell could find
the g++ frontend of the GNU compiler
but that frontend couldn't find
cc1plus, the actual C++ compiler; it
could find cpp, the preprocessor, it
already ran. Go to the directory where
the g++ frontend is stored (type:
"which g++") and look for the file
cc1plus in that same directory or a
sub- directory thereof. If it isn't
there your compiler installation is
broken; if it is there some
configuration of it went berzerk.
Also, have a look at this thread.
suse cross-compile toolchain is here.
http://download.opensuse.org/repositories/CrossToolchain:/mingw/