I've a C GUI application (in GTK+2.0) that I used to link as follows :
gcc -O2 -std=gnu99 -pipe -Wall -lm `pkg-congig gtk+-2.0 `pkg-config --libs gtk+-2.0` -o exec a.o b.o c.o
which eventually converted into :
gcc -O2 -std=gnu99 -pipe -Wall -lm -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64 linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0 -lcairo -lgtk-x11-2.0 -lglib-2.0 -o exec a.o b.o c.o
It was until Ubuntu 12.04.
When I tried to link the files in the same way in Ubuntu 12.04 as well, it showed the following error :
/usr/bin/ld: b.o: undefined reference to symbol 'gdk_color_parse'
/usr/bin/ld: note: 'gdk_color_parse' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libgdk-x11-2.0.so so try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libgdk-x11-2.0.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
If anyone has any idea about this please share.
With newer versions of GCC/binutils, linker flags have to come last because the linker looks ahead only for undefined symbols. Try
gcc -O2 -std=gnu99 -pipe -Wall a.o b.o c.o -lm `pkg-config --libs gtk+-2.0` -o exec
instead.
Related
This question seems to have been asked a zillion times, but unfortunately, none of the answers helped me.
I believe I have installed gtk correctly. My pkg-config environment seems okay. I'm not so sure of gcc.
I removed all the mingw and cygwin folders from my path environment, as I am only going to be using msys2 packages. So I have my path environment this way:-
GTK_LIB_DIR
C:\msys64\mingw64\lib
PKG_CONFIG_PATH
C:\msys64\mingw64\lib\pkgconfig
Path - C:\msys64\usr\bin;C:\msys64\mingw64\bin;%GTK_LIB_DIR%
The problem I am having is with compilation. Running this...
gcc pkg-config --cflags gtk+-3.0 -o gtkTest C:\dev\test_gtk3.c pkg-config --libs gtk+-3.0
I get...
cc: error: `pkg-config: No such file or directory
gcc: error: gtk+-3.0`: No such file or directory
gcc: error: `pkg-config: No such file or directory
gcc: error: gtk+-3.0`: No such file or directory
gcc: error: unrecognized command line option '--cflags'
gcc: error: unrecognized command line option '--libs'
I can run the following commands separately, with expected results. e.g.
pkg-config --cflags gtk+-3.0
pkg-config --libs gtk+-3.0
gcc -o gtkTest C:\dev\test_gtk3.c
Of course the last command returns an error, since gtk is not referenced.
I tried various combinations, some of my own. Some recommended, but one error persists, on pkg-config.
e.g.
C:\WINDOWS\system32>gcc -o gtkTest C:\dev\test_gtk3.c "pkg-config --cflags gtk+-3.0 pkg-config --libs gtk+-3.0"
gcc: error: pkg-config --cflags gtk+-3.0 pkg-config --libs gtk+-3.0: No such file or directory
The last answer I found says "If pkg-config reports that it couldn't find the package, then you didn't install the Gtk development package as offered by your Linux distribution."
I'm using Windows, but I think I installed gtk correctly, since I followed the instructions, and I get what seems to be the expected results (please correct me if I am mistaken).
C:\WINDOWS\system32>pkg-config --cflags gtk+-3.0
-pthread -mms-bitfields -I/mingw64/include/gtk-3.0 -I/mingw64/include/cairo -I/m
ingw64/include -I/mingw64/include/pango-1.0 -I/mingw64/include/fribidi -I/mingw6
4/include -I/mingw64/include/atk-1.0 -I/mingw64/include/cairo -I/mingw64/include
/pixman-1 -I/mingw64/include -I/mingw64/include/freetype2 -I/mingw64/include -I/
mingw64/include/harfbuzz -I/mingw64/include -I/mingw64/include/libpng16 -I/mingw
64/include/gdk-pixbuf-2.0 -I/mingw64/include -I/mingw64/lib/libffi-3.2.1/include
-I/mingw64/include/glib-2.0 -I/mingw64/lib/glib-2.0/include -I/mingw64/include
C:\WINDOWS\system32>pkg-config --libs gtk+-3.0
-L/mingw64/lib -L/mingw64/lib/../lib -L/mingw64/lib -lgtk-3 -lgdk-3 -lz -lgdi32
-limm32 -lshell32 -lole32 -Wl,-luuid -lwinmm -ldwmapi -lsetupapi -lcfgmgr32 -lep
oxy -lopengl32 -lgdi32 -lpangocairo-1.0 -lm -lgdi32 -lpangoft2-1.0 -lm -lpangowi
n32-1.0 -lm -lusp10 -lgdi32 -lpango-1.0 -lm -lfribidi -lthai -ldatrie -latk-1.0
-lcairo-gobject -lcairo -lz -lpixman-1 -lm -pthread -lfontconfig -liconv -lexpat
-lfreetype -lbz2 -lharfbuzz -lm -lusp10 -lgdi32 -lrpcrt4 -lgraphite2 -lpng16 -l
z -lgdk_pixbuf-2.0 -lm -lgio-2.0 -pthread -lintl -lshlwapi -ldnsapi -liphlpapi -
lws2_32 -lgmodule-2.0 -pthread -lintl -lz -lgobject-2.0 -pthread -lintl -lffi -l
glib-2.0 -lintl -lws2_32 -lole32 -lwinmm -lshlwapi -pthread -lm -lpcre
C:\WINDOWS\system32>gcc -o gtkTest C:\dev\test_gtk3.c | pkg-config --cflags --libs gtk+-3.0
-pthread -mms-bitfields -I/mingw64/include/gtk-3.0 -I/mingw64/include/cairo -I/m
ingw64/include -I/mingw64/include/pango-1.0 -I/mingw64/include/fribidi -I/mingw6
4/include -I/mingw64/include/atk-1.0 -I/mingw64/include/cairo -I/mingw64/include
/pixman-1 -I/mingw64/include -I/mingw64/include/freetype2 -I/mingw64/include -I/
mingw64/include/harfbuzz -I/mingw64/include -I/mingw64/include/libpng16 -I/mingw
64/include/gdk-pixbuf-2.0 -I/mingw64/include -I/mingw64/lib/libffi-3.2.1/include
-I/mingw64/include/glib-2.0 -I/mingw64/lib/glib-2.0/include -I/mingw64/include
-L/mingw64/lib -L/mingw64/lib/../lib -L/mingw64/lib -lgtk-3 -lgdk-3 -lz -lgdi32
-limm32 -lshell32 -lole32 -Wl,-luuid -lwinmm -ldwmapi -lsetupapi -lcfgmgr32 -lep
oxy -lopengl32 -lgdi32 -lpangocairo-1.0 -lm -lgdi32 -lpangoft2-1.0 -lm -lpangowi
n32-1.0 -lm -lusp10 -lgdi32 -lpango-1.0 -lm -lfribidi -lthai -ldatrie -latk-1.0
-lcairo-gobject -lcairo -lz -lpixman-1 -lm -pthread -lfontconfig -liconv -lexpat
-lfreetype -lbz2 -lharfbuzz -lm -lusp10 -lgdi32 -lrpcrt4 -lgraphite2 -lpng16 -l
z -lgdk_pixbuf-2.0 -lm -lgio-2.0 -pthread -lintl -lshlwapi -ldnsapi -liphlpapi -
lws2_32 -lgmodule-2.0 -pthread -lintl -lz -lgobject-2.0 -pthread -lintl -lffi -l
glib-2.0 -lintl -lws2_32 -lole32 -lwinmm -lshlwapi -pthread -lm -lpcre
C:\dev\test_gtk3.c:1:10: fatal error: gtk/gtk.h: No such file or directory
1 | #include <gtk/gtk.h>
| ^~~~~~~~~~~
compilation terminated.
Has anyone here struggled with this for hours, like I have, and finally got to understand what the problem is.
Please share your solution. Thank you.
Using this Installing gtk and compiling using gcc under windows? helped me get past the errors.
I used the following suggestion.
"Instead of a batch file, you may find more convenient to create an
user environmental variable and store the flags in there, that way you
will be able to compile from within a normal command prompt."
So I created two new environment variables (e.g. GTK_FLAGS_VARS; GTK_LIBS_VARS), and pasted the outputs in the variable values. Then in path place %GTK_FLAGS_VARS%;%GTK_LIBS_VARS%
Afterward gcc -o gtkTest C:\dev\test_gtk3.c %GTK_FLAGS_VARS% %GTK_LIBS_VARS%
Trying to compile a C GTK gui + Prolog file using GPLC. I read that I can pass multiple flags to the gcc compiler from GPLC by using-C 'gcc flags here'
Ok so I can comiple my GUI alone with
gcc foo.c `pkg-config --cflags --libs gtk+-2.0` -o $(NAME)
However this will not work in GPLC because I would have
'`pkg-config --cflags --libs gtk+-2.0`'
This means I won't get the response from pkg-config as I am seeking because it is inside a "string". How can I fix that?
Lastly if I do something ugly like:
gplc -c foo1.c -C '-I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype'
gplc -c foo2.pl
gplc foo1.o foo2.o -o gyges
I get compilation failure during linking due to all references to GTK functions being undefined. why?
Use shell in a Makefile:
GTK_FLAGS = $(shell pkg-config --cflags --libs gtk+-2.0)
gplc -c foo1.c -C $(GTK_FLAGS)
EDIT:
CC = gplc
GTK_CFLAGS = $(shell pkg-config --cflags gtk+-2.0)
GTK_LIBS = $(shell pkg-config --libs gtk+-2.0)
OBJECTS = foo1.o foo2.o
all: gyges
foo1.o: foo1.c
$(CC) -c foo1.c -o foo1.o $(GTK_CFLAGS)
foo2.o: foo2.pl
$(CC) -c foo2.pl -o foo2.o
gyges: $(OBJECTS)
$(CC) $(OBJECTS) -o gyges $(GTK_LIBS)
Answer
To solve the first problem I just needed to use shell inside a Makefile as Alter Mann pointed out.
The second problem was occurring because GPLC was not seeing the gtk libs during linking. This is because I was using the -C flag to pass args to the gcc compiler during compilation AND linking, this is incorrect, the -L flag is the flag that must be used to pass args to gcc during linking according to the gplc man.
So my final working MAKE looks likes this:
CC = gplc
GTK_CFLAGS = $(shell pkg-config --cflags gtk+-2.0)
GTK_LIBS = $(shell pkg-config --libs gtk+-2.0)
OBJECTS = foo1.o foo2.o
all: name
foo1.o:
$(CC) -c foo1.c -o foo1.o -C '$(GTK_CFLAGS)'
foo2.o:
$(CC) -c foo2.pl -o foo2.o
name: $(OBJECTS)
$(CC) $(OBJECTS) -o name -L '$(GTK_LIBS)'
rm *.o
If you execute vim --version, it will show some information about how it was compiled. On my system, it looks like this:
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -L. -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/local/lib -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE -lm -lncurses -lelf -lnsl -lacl -lattr -lgpm -ldl -L/usr/lib -llua -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -L/usr/local/lib -L/usr/lib/perl5/core_perl/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -L/usr/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic -lruby -lpthread -lgmp -ldl -lcrypt -lm -L/usr/lib
```
I want to add similar information to the version output of an application that is built using CMake.
I know that there are variables like CMAKE_C_FLAGS, but it depends on other variables if these are actually used. For example, CMAKE_C_FLAGS_RELEASE is used if CMAKE_BUILD_TYPE=Release is specified. Thus it might be error-prone to try to piece this information together from individual CMake variables, and in the end you can't be sure that this is really what CMake uses to compile your sources.
Is there a way to get the actual command CMake uses to compile a source file, similar to the output from vim --version above?
moreover, CMAKE_C_FLAGS could vary for different source files, directories and targets… so your output can be far from accurate…
and using variables like CMAKE_BUILD_TYPE is pretty stable actually and may give you what you want:
string(TOUPPER "${CMAKE_BUILD_TYPE}" _type_upcase)
# Yeah! CMake can do double expand!
set(_cflags "${CMAKE_C_FLAGS_${_type_upcase}}")
little problem is: make sure CMAKE_BUILD_TYPE is set and valid before get the value!
advanced way:
one may use CMAKE_<lang>_COMPILE_OBJECT variable to get a "compile template". then use directory properties to collect COMPILE_DEFINITIONS and replace a pattern <DEFINES> in the template. then collect INCLUDE_DIRECTORIES and other options depending on build type.
You may look here for inspiration.
I'm compiled a GTK+ program using clang, rather than gcc. So far so good, except I can't have ld link correctly.
Original makefile called gcc to do the linking, like this:
gcc -g -O2 -export-dynamic -o my_application somefile.o another.o -pthread -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2 -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lORBit-2 -lart_lgpl_2 -lgconf-2 -lglade-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lxml2 -pthread -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lxml2 -lgthread-2.0 -lrt -lglib-2.0
If I simply substitute gcc with clang in the above command, I get this warning from the latter:
clang: warning: argument unused during compilation: '-e xport-dynamic'
Problem is: clang doesn't recognize "-export-dynamic" as a linker option, so it doesn't pass it off to ld. This causes the references to external functions to be scrapped: when final binary is executed, neither the menu options nor the buttons react.
If I do final linking step with gcc the binary works perfectly (even though it was really compiled with clang and gcc only does the linking). Since I'm trying to completely replace gcc with clang in my machine, this is not acceptable.
So I tried this:
ld /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtn.o -g -O2 -export-dynamic my_application somefile.o another.o -o -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2 -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lORBit-2 -lart_lgpl_2 -lgconf-2 -lglade-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lxml2 -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lxml2 -lgthread-2.0 -lrt -lglib-2.0
By adding first 3 objects I avoid the "can't find _start" message. But then I get the aforementioned two complaints:
/usr/lib/crt1.o: In function _start:
(.text+0x12): undefined reference to __libc_csu_fini
/usr/lib/crt1.o: In function _start:
(.text+0x19): undefined reference to __libc_csu_init
I tried adding crtbegin.o and crtend.o at the list, even before crt1.o , to no avail. What is the linker's correct invocation?
(Post Edit): If nothing else works, is there a way to catch what exact parameters gcc is passing to ld when gcc is used for the linking?
gcc automatically adds language support libraries and objects to your supplied list for link. You have to add them yourself if you want to invoke ld directly. Taking an example from man ld, it could be
ld -o <output> /lib/crt0.o hello.o -lc
Try adding -lc, the symbol you need should be in it (at least on my system, it is).
You can use -Wl,-export-dynamic to pass -export-dynamic to ld without clang knowing about it.
If I'm statically linking a GTK+ program under FreeBSD 8, gtk_builder_add_from_file() suddenly returns with an error:
Invalid object type `GtkWindow'
How to fix that? With dynamic linking everything works fine.
Update: linking is done by:
cc -o foobar foo.o bar.o main.o -Wall -pedantic -std=c99 D_THREAD_SAFE -DORBIT2=1 -D_REENTRANT -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/pango-1.0 -I/usr/local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/gconf/2 -I/usr/local/include/orbit-2.0 -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -DGTK_DISABLE_DEPRECATED=1 -DGDK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED=1 -DGTK_MULTIHEAD_SAFE=1 -export-dynamic -static -pthread -L/usr/local/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lgio-2.0 -lXinerama -lXi -lXcursor -lXcomposite -lXdamage -lpangoft2-1.0 -lXext -lXfixes -lcairo -lpixman-1 -lpng -lxcb-render-util -lXrender -lxcb-render -lX11 -lxcb -lXau -lXdmcp -lpango-1.0 -lfontconfig -lexpat -lfreetype -lz -lgconf-2 -lORBit-2 -lm -ldbus-1 -lgmodule-2.0 -lgthread-2.0 -lgobject-2.0 -lglib-2.0 -liconv -lintl -lpcre
or in another words, in Makefile I have:
CFLAGS := -Wall -pedantic -std=c99
LDFLAGS := -export-dynamic -static
CFLAGS += $(shell pkg-config --cflags gtk+-2.0 gconf-2.0) \
-DGTK_DISABLE_DEPRECATED=1 -DGDK_DISABLE_DEPRECATED \
-DGDK_PIXBUF_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED=1 \
-DGTK_MULTIHEAD_SAFE=1
LDFLAGS += $(shell pkg-config --libs --static gtk+-2.0 gconf-2.0) -lintl -lpcre
...
$(NAME): $(OBJ)
cc -o $# $^ $(CFLAGS) $(LDFLAGS)
First of all linking gtk+ against an application statically is not supported. You are likely to run into a lot of hairy problems.
GtkBuilder needs to be able to dlopen your library, you need to make sure that all he symbols from the related libraries are also exported by your binary. On ELF systems you'll have to pass in the -export-dynamic/-Wl,-export-dynamic to the linker/gcc.