Re: Problem with gtkbuilder mingw cross (not the signal problem)
John Stebbins wrote: Tor Lillqvist wrote: (Adding gtk-app-devel-list back as Cc. Please let's keep this discussion on the list.) Oops, didn't notice that reply went direct to you instead of to the list. Why make it harder for yourself, why not use a shared library (dll) build of gtk+ like everyone else? --tml Short answer, I don't know what I'm doing ;-) . I saw that cross development environment announced on freshmeat, and on a whim I decided to try porting my application to windows. It looked like a nice self contained set of tools that could get me there. I didn't explicitly ask for it to build static. From the package's feature list, creates libraries to be linked statically, no DLL hell. The last time I build a cross-compiler from scratch and build the GTK stack for it, it created all dlls. I guess that was my own setup though. I use only Tor's official zip files if I do that now. As far as I know, GTK simply cannot run statically linked, especially on win32. Basically all kinds of paths are keyed off of the main gtk dll's path. In other words, if you put the gtk dll in a folder named bin, it will automatically check in ../etc/ for stuff like the gtkrc file, ../lib/gtk-2.0 for things like theme engines. This makes it easy to bundle the runtime up with your EXE on windows. In short, GTK just isn't designed to be a statically-build system. Additionally if you did so, your resulting executable has to be licensed to users under the terms of the LGPL, something that is not always desirable. It's not hard to add the official gtk win32 binaries, libraries, and include files to your cross-compiler's environment. On my machine I have /opt/mingw/i386-pc-mingw32 and inside there are bin, include, and lib directories. I just unzip the zip files inside that folder, and things normally go into the right places. The only catch is dealing with pkg-config. you have to set the PKG_CONFIG_PATH variable to point to /opt/mingw/i386-pc-mingw32/lib/pkgconfig, but also you ahve to modify all the .pc files for GTK to have the linux paths on your machine (paths to the mingw areas). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problem with gtkbuilder mingw cross (not the signal problem)
I did some sleuthing, and discovered that g_module_symbol() fails to find the symbol gtk_adjustment_get_type. Sorry, I have no idea why that would happen. gtk_adjustment_get_type is exported from the libgtk DLL (libgtk-win32-2.0-0.dll), just like all the other functions. You will have to dig into it more deeply. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problem with gtkbuilder mingw cross (not the signal problem)
(Adding gtk-app-devel-list back as Cc. Please let's keep this discussion on the list.) I'm statically linking libgtk-win32-2.0.a. That cross development environment I pointed out creates only static libraries for everything. I'll bet it has something to do with that. Is using the dll required?' Ah... Well, if you use a static öibgtk you are on your own;) If you then try to look up gtk+'s own functions with g_module_symbol, I am not surprised that it doesn't work, as those symbols are presumably not exported from the .exe into which gtk has been statically linked. (Yes, symbols can be exported not only from .dll files, but also .exe files. It is not common, but possible. Basically there is very little difference between a .dll and a .exe.) Do note that the concept of exported symbols is quite different in PE executables (on Windows) and ELF ones (on Linux). Why make it harder for yourself, why not use a shared library (dll) build of gtk+ like everyone else? --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problem with gtkbuilder mingw cross (not the signal problem)
Tor Lillqvist wrote: (Adding gtk-app-devel-list back as Cc. Please let's keep this discussion on the list.) Oops, didn't notice that reply went direct to you instead of to the list. Why make it harder for yourself, why not use a shared library (dll) build of gtk+ like everyone else? --tml Short answer, I don't know what I'm doing ;-) . I saw that cross development environment announced on freshmeat, and on a whim I decided to try porting my application to windows. It looked like a nice self contained set of tools that could get me there. I didn't explicitly ask for it to build static. From the package's feature list, creates libraries to be linked statically, no DLL hell. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Problem with gtkbuilder mingw cross (not the signal problem)
I'm cross compiling a gtk app that uses gtk builder with mingw. My build system is Fedora 10. I create my mingw env from this: http://www.profv.de/mingw_cross_env/ This is not the same problem others have had with connecting callbacks, but it may be related. The app builds fine. When the application starts, gtk_builder_add_from_string() fails. I did some sleuthing, and discovered that g_module_symbol() fails to find the symbol gtk_adjustment_get_type. I'm guessing it fails for other symbols as well, GtkAdjustment just happens to be the first object in my builder file. nm shows that the symbol is in the binary. Note that I can successfully lookup my callback functions using g_module_symbol(). So it just has something to do with exporting those symbols gtkbuilder relies on for instantiating objects. Any ideas? example compile line: i386-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I/home/jstebbins/Source/HandBrake.mingw/build/../gtk/src -I.. -DPACKAGE_LOCALE_DIR=\/home/jstebbins/Source/HandBrake.mingw/build/contrib/share/locale\ -DPACKAGE_SRC_DIR=\/home/jstebbins/Source/HandBrake.mingw/build/../gtk/src\ -DPACKAGE_DATA_DIR=\/home/jstebbins/Source/HandBrake.mingw/build/contrib/share\ -mms-bitfields -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/gtk-2.0 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/gtk-2.0/include -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/atk-1.0 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/cairo -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/pango-1.0 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/glib-2.0 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/glib-2.0/include -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/pixman-1 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/freetype2 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/libpng12 -Wall -g -g3 -O3 -fno-common -I/home/jstebbins/Source/HandBrake.mingw/build//libhb -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o /home/jstebbins/Source/HandBrake.mingw/build/../gtk/src/main.c example link line: i386-mingw32msvc-g++ -g -O2 -I/home/jstebbins/Source/HandBrake.mingw/build//libhb -Wl,--export-dynamic -g3 -O3 -o ghb.exe callbacks.o queuehandler.o audiohandler.o x264handler.o main.o settings.o resources.o presets.o preview.o icons.o icon_tools.o values.o appcast.o plist.o hb-backend.o renderer_button.o ghbcellrenderertext.o ghb-dvd.o marshalers.o -L/home/jstebbins/Source/HandBrake.mingw/build//libhb -L/home/jstebbins/Source/HandBrake.mingw/build//contrib/lib -lhb /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/liba52.a -lm /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libmkv.a -lavformat -lavcodec -lavutil /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libdca.a /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libdvdread.a /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libfaac.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libmp3lame.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libmpeg2.a -L/home/jstebbins/Source/HandBrake.mingw/build/contrib//lib /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libvorbisenc.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libvorbis.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libsamplerate.a -lx264 -lxvidcore /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libmp4v2.a -lswscale /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libtheora.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libogg.a /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libfaad.a -lbz2 -lpthread -liberty -L/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libgtk-win32-2.0.a -lcomdlg32 -lwinspool -lcomctl32 /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libgdk-win32-2.0.a -limm32 -lshell32 -luuid /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libatk-1.0.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libgdk_pixbuf-2.0.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libtiff.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libjasper.a -ljpeg /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libpangocairo-1.0.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libcairo.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libpng12.a -lmsimg32 /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libpixman-1.a
