We are doing a C++ project for our uni and its final phase is passing the whole thing into a graphical interface using Qt.
We use Qt5.4 and g++-5. These values have been set in the QtCreator project configuration by selecting the appropriate compiler, g++-5, and also adding options in the *.pro file such as -std=c++14 and so on.
Nevertheless we are being stumped by an important issue. No matter what we try, when running qmake so as to auto-generate the precompiled files, in any Makefile generated by it, the compiler is ALWAYS set to g++ and not g++-5. We are at the moment obliged to after using qmake having to change by hand the compiler in the Makefile on our own, even though we have told it EVERYWHERE that we are using g++-5 and not the normal g++.
We have tried solutions like in this question: Using c++14
And also changing the compiler in the mkspecs of the Qt SDK.
Both have been to no avail and we still can't get the auto-generated Makefile to use g++-5 unless we change it by hand.
Is this a Qt issue or are we doing a step incorrectly?
Thanks in advance.
Sorry for all the bother.
It is solved now, I had linked my g++ compiler to g++-5 when I installed it ages ago but had forgotten (both g++ and g++-5 work on my pc, but they are the same) so it wasn't being an error, just my pc configuration getting in the way, thanks for the help though.
Related
As the title says, I've been trying to cross compile a fairly large project with quite a few dependencies (both static and dynamic libraries). I've cross compiled every dependency successfully using MinGW-w64, set the include & library search paths to their MinGW counterparts (/usr/x86_64-w64-mingw32/lib & include), and yet on the linking step MinGW throws out an error for each call of printf (with stdio.h included, of course). The errors are as follows:
/usr/bin/x86_64-w64-mingw32-ld: ./obj/XXXX.o:/usr/share/mingw-w64/include/stdio.h:352: undefined reference to `__imp___acrt_iob_func'
(Where "XXXX" is a file name from my project)
This error is repeated the exact same (with the exception of the object file name). The command for linking looks like this:
/usr/bin/x86_64-w64-mingw32-g++ -o bin/ReleaseWin/Project #[file with object file names] -L. -L/usr/x86_64-w64-mingw32/lib/ [linking some dependencies (boost, openGL, SDL2, etc.)...] -m64 -flto
I've searched for a solution (or even someone with the same problem) to no avail. I've never been well-versed in linking any more than regular libraries, so if you need more information just ask.
Thanks in advance :)
Extra info:
This project has been cross compiled (from Linux to Windows) successfully before, and I haven't added/removed any dependencies since.
My MinGW-w64 version is 7.0.0
So, I apt-get purge'd mingw-w64 and mingw-w64-common, reinstalled just mingw-w64, and now it's working...
This might have something to do with the fact that I followed the issue that Richard Critten commented with (thanks!), which led me to try downloading and manually copy/pasting headers and CRT (mingw-w64-x86_64-headers-git-... & mingw-w64-x86_64-crt-git) from the MSYS2 repository. That didn't work right away (probably because I screwed up and used the 5.0.0 versions instead of my version), but it seems to have done something.
Therefore, for those who stumble upon this issue,
Try a re-install of MinGW (of course),
Try manually adding the CRT and headers from the link I supplied, and if that still doesn't work,
Try re-installing MinGW again. I'm not super familiar with apt, so I don't know if adding the CRT and headers actually changed how it installed MinGW, but it's worth a shot I guess.
Update: I had this exact same problem on another system. Simply reinstalling MinGW fixed it, so it seems like maybe there was some sort of issue with the files? It's possible that updating from an earlier version messed with things. Moral of the story: even if you think your files are good, a reinstall can't hurt.
I just installed YCM on CentOS 7. I am now at the step of generating a ".ycm_extra_conf.py" equivalent of the file for my project, which is a nested directory of c++ files, uses Scons build system and g++ (with -std=c++98) to compile the c++ files.
I have few questions:
Are the contents of the "flags" variable in ".ycm_extra_conf.py"
file the flags that are passed to the project compiler, in my case
the g++ compiler by the scons build system?
If answer to question 1 is yes, are these same flags then passed to
clang when YCM compiles the files? If so, is YCM compiling or more
technically processing the c++ files in the project to use for
semantic completion?
If answer to question 2 is yes, then I am guessing the flags I state in
the "flags" variable will not work for clang, as they are applicable to
g++. Should I do a conversion/mapping of the flags to clang?
Does YCM use clang to only front-end compile the files to produce the
AST to use for semantic completion?
Sorry about the naive questions, I am very new to YCM. Any help/guidance would be very appreciated.
Regards and thank you,
Ahmed.
The easiest way to get autocompletion working in vim with ycm is bear:
https://github.com/rizsotto/Bear
Install it and then just run:
bear scons
and you'll get your compilation database that makes ycm happy.
I've bumped into the following annoying issue. I installed g++ via macports on OSX, everything works fine. However, cmake still detects clang++ as the cpp compiler. Therefore, I end up putting
export CXX=/opt/local/bin/g++
in my profile. Now, cmake correctly detects g++ as the compiler. The problem is that all the system headers that I include with
INCLUDE_DIRECTORIES(SYSTEM "/path/to/system/header)
are included as regular headers. In other words, I am getting a whole bunch of warnings (-Wall) which I'd very much like to suppress, since I don't care about warnings in system headers like Boost or Eigen.
Any idea how to address this issue? It's driving me crazy, and I am completely puzzled why adding CXX in the profile results in this behaviour. If I remove the export CXX from my profile and manually set CMAKE_CXX_COMPILER to g++ in the CMakeLists.txt then everything is fine, no more warnings for system files.
I finally figured out a solution, from a somehow randomly found post: http://www.cmake.org/pipermail/cmake/2011-June/044769.html. For some reason, the SYSTEM directive was ignored. Setting
SET(CMAKE_INCLUDE_SYSTEM_FLAG_CXX "-isystem ")
solves it, no more warnings generated for system files.
This is a very peculiar issue that appears only on OS X. On all other systems I tested, INCLUDE_DIRECTORIES(SYSTEM "/path/to/system/header") adds the headers as system headers, without any need to use the SET above.
Using export CXX=/opt/local/bin/g++ with several other system variables not adapted seems a little bit unorthodox, so the weird behavior is maybe not surprising.
I suggest you configure from scratch (=from a clean build directory) your project from cmake-gui, the menu allows you to specify the path to the compiler(s) you want to use. You can also use a custom tool-chain file. I suggest you use cmake-gui, it offers a couple of choice that might solve your problem.
Once you get it right, you can document the equivalent command line instruction for other people building your project.
So I'm using Anaconda to run Python 2.7 32-bit on my company's server. That works dandy. Anaconda came with MinGW, so I'm attempting to use the g++ compiler in there. Everything works for me. I can compile c++ source, and then run the resulting executable. The issue comes when coworkers try to do the same. Apparently, the g++ compiler creates a dependency for the executable it makes on a particular dll located within Anaconda. I have a path variable to where this dll lives, my coworkers do not, thus, they cannot run any executable made by g++.
Is there a way to specify where this dll dependency is when I compile executable so that anyone can use them? Something like:
g++ someCode.cpp -o someCode.exe locationOfDll=path2dll
Just to be clear, everyone can successfully compile c++ source code, but only I can run the resulting executable. Thanks in advance
EDIT: I forgot to mention that simply giving everyone the path variable is not an option.
Does this help? It discusses updating the library search paths.
http://www.mingw.org/wiki/HOWTO_Specify_the_Location_of_Libraries_for_use_with_MinGW
I'm tired searching in internet.
I created a klient-serwer program, which shut down computer just by their IP's on specific port.I made whole thing in C, everything works perfectly, i'm compiling my project using gcc with -Wall option and I've got a clear results.
But I had to create GUI so i decided to use QT Creator IDE, I transfered code from C into C++ and i made GUI. Program works but I have to compile this using g++ with -Wall option.
Thing is, I cannot compile anything.
g++ my_project.cpp -o mypro -Wall
ERROR: fatal error: QMainWindow: directory don't exist (in my native language)
compilation terminated
(same with other source files)
Any ideas?
It's propably very easy, but believe me, I want to compile this and go to sleep. Cheers
Why don't you use qmake? First, you can edit your *.pro file and add any compiler flags you wish (see Mitch's comment). Then, if you execute qmake and then make, it will show you a sequence of compilation commands with proper flags, linker and include paths and so on. After that you can just reproduce that commands manually if your teacher wants so.
The error shows that the compiler is trying to open QMainWindow as if it was a directory (if the translation is correct) or at least failing to locate where the include files for Qt are. You probably need to provide some -I option to hint the compiler as to where the Qt headers are, and make sure that the #include directives are correct in your code.