compiler error gtk+3 undefined reference on windows - windows

I am trying to create a GUI program using gtk3 but I am unable to compile a program that utilize the gtk library! I am running windows 8 and I installed gtk using msys via the following method:
I have dowloaded and installed MSYS2 from msys2 website. I am running the msys2 mingw-w64 64 bits version. I updated everything using pacman -Syu and executed pacman -S mingw-w64-x86_64-gtk3 base-devel mingw-w64-toolchain.
Then I added ;C:\msys64\mingw64\bin to my path via Control Panel -> System and Security -> System -> Advanced system settings -> Environment Variables and under the System variables I modified the variable Path and appended ;C:\msys64\mingw64\bin at the end.
I then installed Code::Blocks mingw setup, 64 bit successfully
I created a console application -> c project -> GNU GCC compiler -> create project.
I pasted in the following code into the main.c file, overriding whatever was there as default, with this piece of code
#include <stdio.h>
#include <stdlib.h>
#include <gtk/gtk.h>
int main(int argc, char *argv[])
{
gtk_init(&argc, &argv);
printf("Hello world!\n");
return 0;
}
I opened the compiler settings via Settings -> Compiler... -> Other compiler options and appended pkg-config gtk+-3.0 --cflags with '`' on each side (cannot add this here because that is the format for code...
Then I added pkg-config gtk+-3.0 --libs (again with the ยด but in the other direction on each side of the argument) in Linker settings -> Other linker options:
When I try to compile and run the project I get this
Build messages
||=== Build: Debug in gtkdev (compiler: GNU GCC Compiler) ===|
c:\mingw\bin..\lib\gcc\mingw32\8.2.0........\mingw32\bin\ld.exe: obj\Debug\main.o||in function main':|
C:\Users\name\Documents\development\gtkdev\main.c|7|undefined reference togtk_init_abi_check'|
||error: ld returned 1 exit status|
||=== Build failed: 2 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|
error: ld returned 1 exit status
Build log
mingw32-g++.exe -o bin\Debug\gtkdev.exe obj\Debug\main.o -LC:/msys64/mingw64/lib -lgtk-3 -lgdk-3 -lz -lgdi32 -limm32 -lshell32 -lole32 -Wl,-luuid -lwinmm -ldwmapi -lsetupapi -lcfgmgr32 -lpangowin32-1.0 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lintl -lglib-2.0 -LC:/msys64/mingw64/lib -lgtk-3 -lgdk-3 -lz -lgdi32 -limm32 -lshell32 -lole32 -Wl,-luuid -lwinmm -ldwmapi -lsetupapi -lcfgmgr32 -lpangowin32-1.0 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lintl -lglib-2.0
c:/mingw/bin/../lib/gcc/mingw32/8.2.0/../../../../mingw32/bin/ld.exe: obj\Debug\main.o: in function main':
C:/Users/name/Documents/development/gtkdev/main.c:7: undefined reference togtk_init_abi_check'
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minute(s), 0 second(s))
2 error(s), 0 warning(s) (0 minute(s), 0 second(s))
Output of pkg-config gtk+-3.0 --cflags in msys
-pthread -mms-bitfields -IC:/msys64/mingw64/include/gtk-3.0 -IC:/msys64/mingw64/include/cairo -IC:/msys64/mingw64/include -IC:/msys64/mingw64/include/pango-1.0 -IC:/msys64/mingw64/include/fribidi -IC:/msys64/mingw64/include -IC:/msys64/mingw64/include/atk-1.0 -IC:/msys64/mingw64/include/cairo -IC:/msys64/mingw64/include/pixman-1 -IC:/msys64/mingw64/include -IC:/msys64/mingw64/include/freetype2 -IC:/msys64/mingw64/include -IC:/msys64/mingw64/include/harfbuzz -IC:/msys64/mingw64/include/libpng16 -IC:/msys64/mingw64/include/gdk-pixbuf-2.0 -IC:/msys64/mingw64/include/libpng16 -IC:/msys64/mingw64/include -IC:/msys64/mingw64/lib/libffi-3.2.1/include -IC:/msys64/mingw64/include/glib-2.0 -IC:/msys64/mingw64/lib/glib-2.0/include -IC:/msys64/mingw64/include
Output of pkg-config gtk+-3.0 --libs in msys
-LC:/msys64/mingw64/lib -lgtk-3 -lgdk-3 -lz -lgdi32 -limm32 -lshell32 -lole32 -Wl,-luuid -lwinmm -ldwmapi -lsetupapi -lcfgmgr32 -lpangowin32-1.0 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lintl -lglib-2.0
Using the flags instead of relying on pkg-config does not change anything. Compiling main.c from windows Command Propt using gcc and said flags results in the same error as in Code::Blocks. Moving the order of the options/flags in different ways does not change the error. For example having the libraries last and the cflags directly after gcc or main.c does not change the output, I have seen a "solutions" where there has to be a specific order to compile and link everything correctly, which does not work in the windows Command prompt nor in Code::Blocks apparently. Further more adding the compiler and linker options in Build Options for the project in Code::Blocks does not change anything either. Still the same error.
NOTE: When I compile the above program using msys2 console and compile it with gcc main.c -o run_me pkg-config --cflags --libs gtk+-3.0 I get errors about -ldwmapi but I get a run_me.exe file that works just as expected. I have pasted in some different example gtk c code into the main.c file and compiled it with the msys console and it compiles & links an exe file perfectly, even manages to create gtk windows flawlessly. This is not sustainable because it is awful to code in nano inside a console that does not have auto completion.

Related

What is the difference between -Wl,--export-dynamic and -Wl,-export-dynamic (single vs double-dash)?

A user of xnec2c was trying to build on OSX with clang and got this error:
gcc --pedantic -Wall -std=gnu11 -O2 -g -Wformat -Werror=format-security -fpie -Wno-overlength-strings -DGTK_DISABLE_SINGLE_INCLUDES -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGSEAL_ENABLE -DGDK_PIXBUF_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-honor-nans -fno-signed-zeros -fno-math-errno -Wl,--export-dynamic -Wl,--as-needed -o xnec2c main.o mathlib.o measurements.o interface.o callbacks.o console.o callback_func.o calculations.o cmnd_edit.o geom_edit.o gnuplot.o draw.o draw_structure.o draw_radiation.o fields.o fork.o geometry.o ground.o xnec2c.o input.o matrix.o utils.o nec2_model.o network.o optimize.o plot_freqdata.o radiation.o rc_config.o shared.o somnec.o xnec2c-resources.o -L/opt/local/lib -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl -lpthread -lm
ld: unknown option: --export-dynamic
clang: error: linker command failed with exit code 1 (use -v to see invocation)
(FYI: GTK Builder needs the export-dynamic linking flag.)
This discussion suggests making the double-dash a single dash:
-AM_LDFLAGS = -Wl,--export-dynamic
+AM_LDFLAGS = -Wl,-export-dynamic
However the user found that, actually, it needs a single dash and an underscore (maybe, still having trouble that could be related, but at least ld stopped barking about the option):
-AM_LDFLAGS = -Wl,--export-dynamic
+AM_LDFLAGS = -Wl,-export_dynamic
Questions:
Does single-dash -Wl,-export-dynamic work in both GCC and Clang?
Whats with the underscore version as -Wl,-export_dynamic?
How compatible is that option with older (and newer) versions of the GCC/Clang stacks?
Other considerations or best practice?
Both GNU ld and LLVM lld take --export-dynamic flag
ld that ships with OS X takes -export_dynamic flag
This has nothing to do with gcc or clang, these only pass the flag along to the linker

Does the order in which libraries appear on the gcc command line matter?

I always thought that libraries had to be listed after any object files that depended on them, but given this simple program:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <math.h>
int main(int argc, char **argv) {
double res;
res = acos(2);
printf("res = %f\n", res);
return 0;
}
If I build it without linking in libm, it fails as expected:
$ gcc -o mathtest mathtest.c
/tmp/cc9x6HZA.o: In function `main':
mathtest.c:(.text+0x23): undefined reference to `acos'
collect2: error: ld returned 1 exit status
But I can list -lm either before or after the source file and it links successfully:
gcc -o mathtest -lm mathtest.c
gcc -o mathtest mathtest.c -lm
And I get the same behavior if I compile the source to an object file first and then link it as above.
Did this behavior change at some point? Or was it always like this, and I was just confused?
I confirm the unexpected link-order behaviour that you observe with gcc 5.1 and
also that I have the traditional behaviour with gcc 4.9.2. I would infer that this
novelty comes in with gcc 5.x, and that your toolchain is gcc 5.x. Possibly it
is a distro-specific anomaly of the toolchain build. My toolchain is as per ubuntu 14.04.
The novel behaviour only affects dynamic libraries. I can see what is causing it
if I link in verbose mode (-v) with gcc 4.9.2 and also with gcc 5.1, placing -lm before it is needed,
and examine the differences in the verbose output.
From gcc 4.9.2 I have (with artifical line-wrapping):
/usr/lib/gcc/x86_64-linux-gnu/4.9/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/4.9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper -plugin-opt=-fresolution=/tmp/ccsHNLNB.res
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -z relro -o mathtest
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.9
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. -lm mathtest.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o
And from gcc 5.1 I have:
/usr/lib/gcc/x86_64-linux-gnu/5/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper -plugin-opt=-fresolution=/tmp/cc5hI8vd.res
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -z relro -o mathtest
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/5
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../.. -lm mathtest.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/5/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crtn.o
The relevant difference is that the gcc 4.9.2 linkage passes the option --as-needed
in 4 places whereas the gcc 5.1 linkage passes it in only 3. gcc 4.9.2 passes --as-needed
for the first time at the the 5th quoted "line":
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker
gcc 5.1 does not pass it there. Thereafter, both linkages pass this option at
the same 3 places, starting as the 13th "line":
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. -lm mathtest.o -lgcc --as-needed
This means that for gcc 4.9.2, the library option -lm on "line" 13 falls within the
scope of the first --as-needed. For gcc 5.1 it does not. The effect of this option
is to inform the linker that the dynamic library libm (or any dynamic library that
is encountered in the option's scope) shall be linked only if it is encountered
at a point in the linkage at which it can satisfy some unresolved symbols. In the
absence of this option, at a given point in the linkage, a dynamic library is by
default deemed to be needed for the linkage regardless of whether there are yet any
unresolved symbols that it can satisfy. See the documentation of --as-needed
Thus the gcc 4.9.2 linkage will not link libm, although it appears on the
commandline, because at the point where it appears - before mathtest.o - --as-needed is
in force and there are as yet no unresolved references that libm satisfies. The gcc 5.1
linkage will link libm because it appears on the commandline at a point where --as-needed
is not in force.

FLTK compile error with gcc

I am trying to compile my first FLTK file. First I compiled it by gcc with -lfltk option, and I got this error:
/usr/bin/ld: /tmp/ccX7sPxQ.o: undefined reference to symbol '__gxx_personality_v0##CXXABI_1.3'
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Why do I get this error message? If I use g++ instead, it just compiles it.
edit.
fltk-config --cxxflags returns:
-I/usr/include/cairo -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
-I/usr/include/freetype2 -I/usr/include/cairo -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 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT
-lfltk is not enough to build a minimal FLTK-based application.
I strongly suggest you to read the following page: http://www.fltk.org/doc-1.3/basics.html . It clearly explains how to compile a simple FLTK program.
Assuming your FLTK application is not using extra FLTK libraries (opengl, images, forms) and is in a single file, called myfltkapp.cpp, the absolutely quickest way to compile and link it properly would be:
fltk-config --compile myfltkapp.cpp
I guess the reason I got the error comes from the difference between gcc and g++. I thought I could compile it by gcc with fltk library, but gcc does not link c++ standard library automatically. Thus you have to include the C++ standard library for gcc. It was a silly question.
gcc myfltkapp.cpp -lstdc++ -lfltk
What is the difference between g++ and gcc?

Build shared library with Clang++

I am trying to build a shared library (dll for Windows) using Clang++.
I have run the following commands:
clang++ -c -o hello.o hello.cpp
clang++ -shared -v -o hello.dll hello.o
The first command works fine but when I try to build the dll I get this error:
clang version 3.2 (tags/RELEASE_32/final)
Target: i686-pc-mingw32
Thread model: posix
"c:/MinGW/bin/g++.exe" -shared -v -m32 -o worker.dll worker.o
Using built-in specs.
COLLECT_GCC=c:/MinGW/bin/g++.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.6.2 (GCC)
COMPILER_PATH=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/;c:/mingw/bin/../libexec/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/
LIBRARY_PATH=c:/mingw/bin/../lib/gcc/mingw32/4.6.2/;c:/mingw/bin/../lib/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/lib/;c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../;/mingw/lib/
COLLECT_GCC_OPTIONS='-shared' '-v' '-m32' '-o' 'worker.dll' '-shared-libgcc' '-mtune=i386' '-march=i386'
c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/collect2.exe --shared -Bdynamic -e _DllMainCRTStartup#12 --enable-auto-image-base -u ___register_frame_info -u ___deregister_frame_info -o worker.dll c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../dllcrt2.o c:/mingw/bin/../lib/gcc/mingw32/4.6.2/crtbegin.o -Lc:/mingw/bin/../lib/gcc/mingw32/4.6.2 -Lc:/mingw/bin/../lib/gcc -Lc:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/lib -Lc:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../.. -L/mingw/lib worker.o -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt c:/mingw/bin/../lib/gcc/mingw32/4.6.2/crtend.o
Cannot export _hello: symbol not found
collect2: ld returned 1 exit status
clang++: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)
Here is the file I am compiling:
// hello.cpp
#include <iostream>
#if defined(_WIN32)
#define LIBRARY_API __declspec(dllexport)
#else
#define LIBRARY_API
#endif
extern "C" void LIBRARY_API hello();
void hello()
{
std::cout << "Hello, World!" << std::endl;
}
A follow up to this important question is that as of clang++ version 6.0, the compilation of a DLL by clang is fine. There are differences for the name mangling of C++ functions in C++ for MSVC and CLang, that can impair the use of DLL's in mixed environments but these differences are easy to spot and correct.

GTK3 program no longer compiles - GCC "undefined reference" at link time

So I was merrily learning GTK+ programming with 3.0 in Ubuntu 11.04, and even got a working ruler program running. It compiled with my makefile perfectly.
I took some time away from it, upgraded to 11.10, and now have come back to it. But, alas, when I try to build the program, I get a lot of "undefined reference" errors to pretty much every gtk call in my program. Compiling is fine - the issue is at link time.
The project can be found here: https://github.com/zjmichen/ruler
I've tested it and it compiled fine.
superman#superman-mint ~/work/zjmichen-ruler-e783fe1 $ make
gcc -c -Wall `pkg-config --cflags --libs gtk+-3.0` main.c
gcc -c -Wall `pkg-config --cflags --libs gtk+-3.0` window.c
gcc -c -Wall `pkg-config --cflags --libs gtk+-3.0` graphics.c
gcc -c -Wall `pkg-config --cflags --libs gtk+-3.0` mouse.c
gcc `pkg-config --cflags --libs gtk+-3.0` main.o window.o graphics.o mouse.o -o zruler
superman#superman-mint ~/work/zjmichen-ruler-e783fe1 $
But this was on Linux Mint. Here you've got the arguments produced by pkg-config
-pthread -DGSEAL_ENABLE -I/usr/include/atk-1.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/freetype2 -I/usr/include/libpng12 -I/usr/include/gtk-3.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pixman-1 -pthread -L/usr/lib/x86_64-linux-gnu -lgtk-3 -lgdk-3 -latk-1.0 -lcairo-gobject -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
I've also did a quick test on Ubuntu 11.10 and indeed it doesn't compile. I'll take a better look this evening.
So I did test it on Ubuntu and changed the line 14 in the makefile to
$(CC) $(OBJS) $(GTKFLAGS) -o $(NAME)
this changes the order of object files and libraries that are being linked. I have no idea why this problem occurs on the new Ubuntu. Maybe it is because it is a different version of gcc. On my linux mint gcc is version 4.5.2 on ubuntu 11.10 it is 4.6.1
Unfortunately I currently don't have access to a running Linux machine with GTK3.0 installed, but looking at your code I noticed the inclusion of X11/xlib.h in main.c. Since you are not using X11 code anywhere in your code and you are using 'pkgconfig ... gtk+-3.0' instead of gtk+-X11-3.0, I assume you could remove that include statement. If you do need the X11 libraries the make sure it is listed in the compiler flags. I hope this helps :)

Resources