OS: Windows 7
Compiler: MinGW
IDE: Code::Blocks
I just installed Gtkmm on my computer in the folder C:/gtkmm/ and set up an example program. When I compiled it, it gave the error "gtkmm.h: No such file or directory"
I tried setting the PATH variable to C:/gtkmm/include and C:/gtkmm/gtkmm-2.4, but neither worked. Then I tried using #include "C:/gtkmm/include/gtkmm-2.4/gtkmm.h" and that just gave a ton of errors saying that it doesn't know where a few dozen files are.
I've also heard that you need to put pkg-config gtkmm-2.4 --cflags --libs in the compiler options, but that didn't work either.
What am I doing wrong and how do I fix it?
pkg-config is a helper function for adding cflags and lib paths to the compiler line.
What you will need to do is add the libraries and cflags path to the compiler line. I am not 100% sure how to do that in code::blocks., though
In ubuntu 11.04, you need all these to compile even a simple gtkmm program:
Libs (pkg-config --libs gtkmm-2.4:
-pthread -lgtkmm-2.4 -latkmm-1.6 -lgdkmm-2.4 -lgiomm-2.4 -lpangomm-1.4 -lgtk-x11-2.0 -lglibmm-2.4 -lcairomm-1.0 -lsigc-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lm -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0
cflags paths (pkg-config --clfags gtkmm-2.4):
-I/usr/include/atk-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gio-unix-2.0/ -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/atkmm-1.6 -I/usr/include/giomm-2.4 -I/usr/lib/giomm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/lib/pangomm-1.4/include -I/usr/include/gtk-2.0 -I/usr/include/gtk-unix-print-2.0 -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/cairomm-1.0 -I/usr/lib/cairomm-1.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/lib/gtk-2.0/include -I/usr/include/gdk-pixbuf-2.0
Basically you would have to change every instance of /usr/include/ and /usr/lib/ to c:\path-to-library\
I am not sure how much of the above you need with MinGW, but with GCC on Linux, dropping any of them makes gtkmm programs not compile. Hope that at least puts you on the right path.
What do you mean with PATH variable? The global windows search PATH for executables? That would be wrong.
You need to look in your IDE for Include search path or header search path or something like that.
Does that pkg-config command work for you when you execute it on the command line? Such a pkg-config when used on a unix system is enclosed in backticks ` which causes it to be substituted by it's output. Don't know if your IDE can do that but if it works from the command line you have at least a list of all includes needed.
Use autotools C++ project. You need only edit two files configure.ac and Makefile.am.
Add this line to configure.ac
PKG_CHECK_MODULES([GTKMM], [gtkmm-3.0])
and these lines to Makefile.am
program_CPPFLAGS = $(GTKMM_CFLAGS)
program_LDADD = $(GTKMM_LIBS)
Related
I am having some big headaches linking statically libcurl in MSYS2 mingw.
I installed libcurl and all the listed dependencies from here
https://packages.msys2.org/package/mingw-w64-x86_64-curl
Since I am using CodeBlocks as IDE I need to supply a whole list of libs in form of lib#?.a, please keep in mind that I know nothing of Linux world and gcc tools and command line, otherwise I wouldn't be using an IDE!
Also I am not skilled enough to compile lib packages. I just need to write some portable code to do a https post request in cpp, so I need libcurl.
Can you tell me a complete list of all the needed libs to link against ? I tried all my best but I keep getting an infinity of unresolved symbols
UPDATE
After having checked what the package config for libcurl says, I have installed all the missing libs and used the following command line:
g++.exe -o MyProg.exe obj\Release\main.o -static-libstdc++ -static-libgcc -static -m64 -lcurl -lnghttp2 -lidn2 -lssh2 -lpsl -ladvapi32 -lcrypt32 -lssl -lcrypto -lssl -lcrypto -lgdi32 -lwldap32 -lzstd -lbrotlidec -lz -lws2_32 -s
Despite that I am still getting tons of undefined references:
d:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: d:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/lib/../lib\libcurl.a(gsasl.o):(.text+0x14): undefined reference to `gsasl_init'
[plus many other 'gsasl...' referrences]
d:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: d:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../lib\libbrotlidec.a(decode.c.o):(.text+0x2d28): undefined reference to `BrotliTransformDictionaryWord'
[plus many other 'brotli...' references]
pkg-config will tell you the necessary flags. Install it from the package mingw-w64-x86_64-pkg-config.
Run it as pkg-config --libs --static libcurl.
Copy the output into "linker flags -> other". For me the output is -L/mingw64/lib -lcurl -lnghttp2 -lidn2 -lssh2 -lpsl -ladvapi32 -lcrypt32 -lssl -lcrypto -lssl -lcrypto -lgdi32 -lwldap32 -lzstd -lbrotlidec -lz -lws2_32. Don't forget to add the --static flag, if you're not already doing so.
I have been trying to get wxWidgets working on Cygwin. So far I have had success by using a mingw compiler available through the cygwin installer.
The build seemed to work fine. The configure message I used was:
configure --host=i686-w64-mingw32 --build=i686-pc-cygwin --enable-static --disable-shared
After that I ran a make and make install and got no errors.
Next I grabbed an example from a tutorial and ran:
i686-w64-mingw32-g++ -c -o hello_world.o hello_world.cpp CXX_FLAGS
i686-w64-mingw32-g++ -o a hello_world.o CXX_FLAGS LIBS
where CXX_FLAGS and LIBS are generated from wx-config -cxxflags and wx-config --libs. This works fine, but when I try to run the executable I get this error:
C:/Users/sam/Documents/cpp/wxwidgets_tutorial/a.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory
The libraries I build should be static, so I'm not sure what to do with this message. Any help is greatly appreciated!
Some more info:
wx-config --cxxflags gives the output:
-I/usr/local/lib/wx/include/i686-w64-mingw32-msw-unicode-static-3.0 -I/usr/local/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -D__WXMSW__ -mthreads
wx-config --libs give the output:
-L/usr/local/lib -Wl,--subsystem,windows -mwindows /usr/local/lib/libwx_mswu_xrc-3.0-i686-w64-mingw32.a /usr/local/lib/libwx_mswu_webview-3.0-i686-w64-mingw32.a /usr/local/lib/libwx_mswu_qa-3.0-i686-w64-mingw32.a /usr/local/lib/libwx_baseu_net-3.0-i686-w64-mingw32.a /usr/local/lib/libwx_mswu_html-3.0-i686-w64-mingw32.a /usr/local/lib/libwx_mswu_adv-3.0-i686-w64-mingw32.a /usr/local/lib/libwx_mswu_core-3.0-i686-w64-mingw32.a /usr/local/lib/libwx_baseu_xml-3.0-i686-w64-mingw32.a /usr/local/lib/libwx_baseu-3.0-i686-w64-mingw32.a -lpng -ljpeg -ltiff -lexpat -lwxregexu-3.0-i686-w64-mingw32 -lz -lrpcrt4 -loleaut32 -lole32 -luuid -lwinspool -lwinmm -lshell32 -lcomctl32 -lcomdlg32 -ladvapi32 -lwsock32 -lgdi32
ls /usr/local/lib:
libwx_baseu_net-3.0-i686-w64-mingw32.a
libwx_baseu_xml-3.0-i686-w64-mingw32.a
libwx_baseu-3.0-i686-w64-mingw32.a
libwx_mswu_adv-3.0-i686-w64-mingw32.a
libwx_mswu_aui-3.0-i686-w64-mingw32.a
libwx_mswu_core-3.0-i686-w64-mingw32.a
libwx_mswu_gl-3.0-i686-w64-mingw32.a
libwx_mswu_html-3.0-i686-w64-mingw32.a
libwx_mswu_media-3.0-i686-w64-mingw32.a
libwx_mswu_propgrid-3.0-i686-w64-mingw32.a
libwx_mswu_qa-3.0-i686-w64-mingw32.a
libwx_mswu_ribbon-3.0-i686-w64-mingw32.a
libwx_mswu_richtext-3.0-i686-w64-mingw32.a
libwx_mswu_stc-3.0-i686-w64-mingw32.a
libwx_mswu_webview-3.0-i686-w64-mingw32.a
libwx_mswu_xrc-3.0-i686-w64-mingw32.a
libwxregexu-3.0-i686-w64-mingw32.a
libwxscintilla-3.0-i686-w64-mingw32.a
wx
EDIT:
Following VZ's advise, I added /usr/i686-w64-mingw32/sys-root/mingw/bin to my path... It compiles!
However when run, the program does not open any window, just exits immediately. Is this still a library problem?
You need to copy the required DLLs (at least libstdc++-6.dll and libgcc_s_sjlj-1.dll) from /usr/i686-w64-mingw32/sys-root/mingw/bin to a directory in your PATH or the application directory (or add this directory itself to your PATH, of course).
You can use cygcheck or (native) dependency walker tool to find which DLL is actually missing.
I'm trying to install a C++ library (gtkmm) for my project and to test this installation with a simple test file (the main from wikipedia page about gtkmm).
I did brew install gtkmm3, it installed it but when I compile with clang++ -Wall -Werror -Wextra -o test test.cpp it doesn't find my header :
test.cpp:15:10: fatal error: 'gtkmm-3.0/gtkmm.h' file not found
#include <gtkmm-3.0/gtkmm.h>
The header is located at ~/homebrew/include/gtkmm-3.0/gtkmm.h.
I tried :
adding $HOME"/homebrew/include" to $PATH and using #include <gtkmm-3.0/gtkmm.h> in my source file.
adding $HOME"/homebrew/include/gtkmm-3.0" to my $PATH and using #include <gtkmm.h> in my source file.
But I still can't compile.
How could I do?
Yes, use pkgconfig like this and it will tell you all the include paths and the link paths you need:
pkg-config --libs --cflags /usr/local/Cellar/gtkmm3/*/lib/pkgconfig/gdkmm-3.0.pc
Output
-D_REENTRANT -I/usr/local/Cellar/gtkmm3/3.18.0/include/gdkmm-3.0
-I/usr/local/Cellar/gtkmm3/3.18.0/lib/gdkmm-3.0/include
-I/usr/local/Cellar/glibmm/2.46.3/include/giomm-2.4
-I/usr/local/Cellar/glibmm/2.46.3/lib/giomm-2.4/include
-I/usr/local/Cellar/pangomm/2.38.1/include/pangomm-1.4
-I/usr/local/Cellar/pangomm/2.38.1/lib/pangomm-1.4/include
-I/usr/local/Cellar/glibmm/2.46.3/include/glibmm-2.4
-I/usr/local/Cellar/glibmm/2.46.3/lib/glibmm-2.4/include
-I/usr/local/Cellar/gtk+3/3.18.6/include/gtk-3.0
-I/usr/local/Cellar/glib/2.46.2/include/gio-unix-2.0/
-I/usr/local/Cellar/cairo/1.14.6/include/cairo
-I/usr/local/Cellar/libepoxy/1.3.1/include
-I/usr/local/Cellar/pango/1.38.1/include/pango-1.0
-I/usr/local/Cellar/harfbuzz/1.1.3/include/harfbuzz
-I/usr/local/Cellar/pango/1.38.1/include/pango-1.0
-I/usr/local/Cellar/atk/2.18.0/include/atk-1.0
-I/usr/local/Cellar/cairo/1.14.6/include/cairo
-I/usr/local/Cellar/cairomm/1.12.0/include/cairomm-1.0
-I/usr/local/Cellar/cairomm/1.12.0/lib/cairomm-1.0/include
-I/usr/local/Cellar/cairo/1.14.6/include/cairo
-I/usr/local/Cellar/pixman/0.32.8/include/pixman-1
-I/usr/local/Cellar/fontconfig/2.11.1/include
-I/usr/local/Cellar/freetype/2.6_1/include/freetype2
-I/usr/local/Cellar/libpng/1.6.20/include/libpng16
-I/usr/local/Cellar/libsigc++/2.6.2/include/sigc++-2.0
-I/usr/local/Cellar/libsigc++/2.6.2/lib/sigc++-2.0/include
-I/usr/local/Cellar/gdk-pixbuf/2.32.3/include/gdk-pixbuf-2.0
-I/usr/local/Cellar/libpng/1.6.20/include/libpng16
-I/usr/local/Cellar/glib/2.46.2/include/glib-2.0
-I/usr/local/Cellar/glib/2.46.2/lib/glib-2.0/include
-I/usr/local/opt/gettext/include
-L/usr/local/Cellar/gtkmm3/3.18.0/lib
-L/usr/local/Cellar/glibmm/2.46.3/lib
-L/usr/local/Cellar/pangomm/2.38.1/lib
-L/usr/local/Cellar/glibmm/2.46.3/lib
-L/usr/local/Cellar/gtk+3/3.18.6/lib
-L/usr/local/Cellar/pango/1.38.1/lib
-L/usr/local/Cellar/atk/2.18.0/lib
-L/usr/local/Cellar/cairo/1.14.6/lib
-L/usr/local/Cellar/glib/2.46.2/lib
-L/usr/local/Cellar/cairomm/1.12.0/lib
-L/usr/local/Cellar/cairo/1.14.6/lib
-L/usr/local/Cellar/libsigc++/2.6.2/lib
-L/usr/local/Cellar/gdk-pixbuf/2.32.3/lib
-L/usr/local/Cellar/glib/2.46.2/lib
-L/usr/local/opt/gettext/lib
-lgdkmm-3.0 -lgiomm-2.4 -lpangomm-1.4 -lglibmm-2.4 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lgio-2.0 -lcairomm-1.0 -lcairo -lsigc-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lintl
Then you can compile with:
clang++ $(pkg-config --libs --cflags /usr/local/Cellar/gtkmm3/*/lib/pkgconfig/gdkmm-3.0.pc) someFile.cpp -o someFile
The context is the following: I am trying to compile InkscapeLite from sources in Linux Mint. At the end of the compilation, the last command is (some .o and .a files are replaced with "...", because the command is very long):
gcc -g -O2 -o inkscape --export-dynamic inkscape.o inkscape-stock.o ... ./.libs/libinkscape.al dialogs/libspdialogs.a ... -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 /usr/lib/i386-linux-gnu/libcairo.so -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 /usr/lib/i386-linux-gnu/libart_lgpl_2.so /usr/lib/i386-linux-gnu/libxml2.so /usr/lib/i386-linux-gnu/libpopt.so -lpng -lXft -L/usr/lib/i386-linux-gnu /usr/lib/i386-linux-gnu/libfreetype.so -lz -Wl,--rpath -Wl,/usr/lib/i386-linux-gnu -Wl,--rpath -Wl,/usr/lib/i386-linux-gnu
It fails with error: gcc: error: unrecognized option '--export-dynamic'
What I have done is to replace --export-dynamic with -export-dynamic, just for test (notice, I am not C/C++ programmer and know nothing about GCC or any other C compiler) and executed the command manually in the console. The compilation ended without errors and the program works, but it misses almost all toolbar and menu icons (only some common icons are there as open/save/copy/paste...)
Is it because of this problem option --export-dynamic or there is some different problem in the sources?
BTW, the same program works normally in the Puppy Linux distributions.
It seems the building scripts issue. --export-dynamic is a linker (ld in Unixes) option which could be useful in your case but it isn't gcc frontend option. All GCC versions I see have -rdynamic flag which causes passing of --export-dynamic to linker. So you can fix this with your own means (e.g. simply try to rename the option in makefile/etc.) and/or report the issue to maintainers.
Use gcc -rdynamic or -Wl,--export-dynamic (the -Wl tells to send the next suboption to ld ...)
I'm trying to link to a static library, libcovis.a. Everything looks fine but I still have
undefined reference to `CoViG_PublicDemo::MoInS::reset()'
I checked that the name exists in the library
$nm libcovis.a | grep reset
...
_ZN16CoViG_PublicDemo5MoInS5resetEv
...
I'm using linking arguments -L/path/to/libcovis.a -lcovis
What am I doing wrong ?
Edit:
The error might be something else, if do
gcc main.cpp -I/usr/include/opencv -I/usr/include/cairo -I../../Source -o slam -rdynamic -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXi -lxml2 -lboost_filesystem-mt -llapack -lblas -lcv -lcxcore -lcvaux -lhighgui -lcairo ../../Source/libcovis.a ../../Source/contrib/gnuplot_i/libcovis_contrib_gnuplot_i.a -lgl2ps
It works !
But when I'm in KDevelop using cmake, I doesn't work anymore. I use
CMAKE_EXE_LINKER_FLAGS:STRING=-rdynamic -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXi -lxml2 -lboost_filesystem-mt -llapack -lblas -lcv -lcxcore -lcvaux -lhighgui -lcairo /usr/local/src/CoViS-0.0.0-1/Source/libcovis.a /usr/local/src/CoViS-0.0.0-1/Source/contrib/gnuplot_i/libcovis_contrib_gnuplot_i.a -lgl2ps
CMAKE_CXX_FLAGS:STRING=-I/usr/local/src/CoViS-0.0.0-1/Source -I/usr/include/opencv -I/usr/include/cairo
The only difference I can see is that the paths are absolute and not relative, but if he couldn't find the libs, he would say it...
There are two different issues there, the first of which is the simplest, you have used the wrong compiler options. The -L option tells the linker to also look in the directory when looking for a library. The -l tells it to link the specific library. To link you would then use:
g++ -o test test.o -L/path/to -lcovis
or
g++ -o test test.o -l/path/to/libcovis.a
To force static linking if the same library is present as a dynamic library in the same directory.
The second potential issue is that the order of static libraries in the linker command line does matter, so that might also be an issue if there is a dependency on different static libs.
g++ -o test tests.o -ldependent -lprovider
The linker will process the libraries in order as they are in the command line, and from each static lib it will only pull those symbols that are required (with as much information as the linker has at that time). In the command line above, the linker will extract from dependent the symbols it needs for test.o, and that might in turn add new undefined symbols to the program (the dependencies of dependent). When it processes provider it will fill in those symbols. If the order was reversed in the command line, the symbols that are required by dependent but not by test.o would not be added to the executable, as the linker does not know that those symbols will be needed when processing provider.
Should the arguments be like -L/path/to/ -lcovis?
Besides, object files should be placed before libs, for example
g++ obj1.o obj2.o -L/path/to/ -lcovis.
If you see the link succeeding in one context but not another, I suspect the problem may be caused by the order in which the link operation is executed as the linker will discard symbols in a library if they're not needed at the point in which the library is referenced.
Here is a link explaining: http://www.network-theory.co.uk/docs/gccintro/gccintro_18.html
I've run into similar situations in the past the linking order was found to be the cause of the problem.