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.
Related
I am asking here because I couldn't get any support elsewhere. Also consider that I am quite a beginner so bear patience.
I am using Winlibs (winlibs.com, a ready to use mingw gcc10+ distribution) to code under Windows because after having tried other alternatives I judged it the best to my purposes, easiest to install and the most functional. I never had any problems with it.
But recently I had the need of writing some simple code to send a POST request. I wanted to do it in a possibly portable and c++ friendly manner, so I was suggested to use Curl. No libcurl is included in winlibs so I tried to load one from here
https://curl.se/download.html
I chose the windows 64 binary of course (7.83.1) since I am working on windows 64 with winlibs 64. I installed everything in the right place and linked against libcurl.a.
Unfortunately the linker complains of unresolved symbols so I have to supppose the curl binaries I used are not suitable.
How can I use libcurl with winlibs then ? Before bothering here I really googled but could find no info!
The MinGW-w64 tools from https://winlibs.com/ are only a build toolchain, so they don't contain libraries for you to link with (yet).
You need a Windows build of libcurl and use that.
To use it you must include the location to the header files using the -I compiler flag, and then link with the library by pointing to the location of the .a file with the -L linker flag and then link with the library using the -l flag (-lcurl in this case). If you don't have .a files you can also try to link with the full path of the .dll file and gcc will know it's a shared library.
An easier way is to get libcurl via MSYS2's pacman package manager.
If you want to statically link you need to use the output of pkg-config --static --libs libcurl as link flags.
In practice though I noticed that sometomes pkg-config --static --libs libcurl is missing some dependencies and you still need to add some manually. An example of a project of mine that builds on Windows with winlibs MinGW-w64 (both 32-bit and 64-bit) can be found at https://github.com/brechtsanders/winlibs_tools/blob/main/Makefile (specifically look for the definition of CURL_LDFLAGS)
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
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.
Ok, so, I'm trying to build a third party library with msys2 and I've run into a problem with a few headers, such as gtk.h; the library I'm trying to build expects this to be located via #include <gtk/gtk.h>.
Now, experience on Linux tells me that would be correct under a normal linux environment; however, in the case of gtk, it seems it would have to be gtk-3.0/gtk/gtk.h, which seems like an error in msys to me - is there some sort of selection step I've missed in setting up my msys2 environment? Like the 'eselect' system under Gentoo, something like 'pselect gtk-3.0' that would create a linked directory to gtk-3.0/gtk just called gtk?
Assuming that you have installed the mingw-w64-i686-gtk3 package with pacman and that you are running in a MinGW 32-bit shell (MSYS2 has three different flavors of shell that use different toolchains), you can run this command to get the required compile flags for GTK3:
pkg-config gtk+-3.0 --cflags
Most build systems have some kind of support for calling pkg-config. It is basically the standard way to get information about your dependencies.
When it's time to link your program, you should replace --cflags in the comand above with --libs.
You simply need to tell the compiler where to find the include directory:
-I/some/path/to/gtk-3.0
I want to use a Qt app on a tiny210 device.
I installed Qt ( qt-everywhere-opensource-src.4.8.5 ) downloaded from here. I managed to compile a simple application for use on tiny210. The problem is that now when I try to run the app on the device, I get the following errors:
libc.so.6: version 'GLIBC_2.15' not found (required by libQtCore.so.4)
libc.so.6: version 'GLIBC_2.15' not found (required by libQtNetwork.so.4)
There is a libc.so.6 in /lib/ on the target device, but it is version 2.11.
I should mention that before getting those errors I also got errors for not having libQtCore.so.4, libQtNetwork.so.4 and libQtGui.so.4. I fixed those errors just by copying the compiled libraries from my host PC to the device.
First question is: Would there have been a better way to provide the needed libraries, or copying them is fine?
Second question is: How can I get over the errors mentioned above?
EDIT : I've read something about building it static, but I am not sure how, and what are the downsides of this.
EDIT2 : I managed to get over the above errors thanks to artless noise's answer, but now I get: error loading shared libraries: libQtGui.so.4: cannot open shared object file: No such file or directory.
The issue is the cross-compiler (apt-get install gcc-arm-linux-gnueabi) is ARM based and this cross compiler has a newer glibc than on the ARM device. You can copy the libc from the cross compiler directory to your ARM device. I suggest testing with LD_LIBRARY_PATH, before updating the main libraries. Use ls /var/lib/dpkg/info/*arm-linux*.list to see most packages related to the ARM compiler. You can use grep to figure out where the libraries are (or fancier things like apt-file, etc).
Crosstool-ng has a populate script, but I dont see it in the Ubuntu packages; it is perfect for your issue. If it is present on your Debian version, I would use it.
The glibc 2.15 is backwards compatible with the glibc 2.11 which is currently on your system. Issues may arise if the compiler was configured with different options (different ABI); however if this is the case, you will have many issues with your built Qt besides the library. In this case, you need to find a better compiler which fits your root filesystem.
So to be clear, on the target
mkdir /lib/staging
cp libc.so-2.15 /lib/staging
cd /lib/staging
ln -s libc.so-2.15 libc.so
LD_LIBRARY_PATH=/lib/staging ls # test the library
You may have to copy additional libraries, such as pthread, resolv, rt, crypt, etc. The files are probably in a directory like sysroot/lib. You can copy the whole directory to the /lib/staging to test it. If the above ls functions, then the compilers should be ABI compatible. If you have a crash or not an executable, then the compiler and rootfs may not be compatible.
Would there have been a better way to provide the needed libraries, or copying them is fine?
Copying may be fine as per above. If it is not fine, then either the compiler or the root filesystem must be updated.
How can I get over the errors mentioned above?
Try the above method. As well, you maybe able to leave your root filesystem alone. Set-up a shadow directory and use chroot to run the Qt application with the copied files as another solution. To test this, make a very simple program and put it along the compiler libraries in a test directory, say /lib/staging as above. Then the test code can be run like,
$ LD_LIBRARY_PATH=/lib/staging ./hello_world
If this doesn't work, your compiler and the ARM file system/OS are not compatible. No library magic will help.
I've read something about building it static, but I am not sure how, and what are the downsides of this.
See Linux static linking is dead. I understand this seems like a solution. However, if the compiler is wrong, this won't help. The calling convention between OS, libraries and what registers are saved by the OS will be implicit in the compiled code. You may have to rebuild Qt with -softfp, etc.