Re: non-Linux OSes
Hi On Tue, Oct 22, 2013 at 4:45 PM, fanc...@yahoo.com.tw wrote: Also, just wondering whether there are any people using GLib with Windows XP 64-bit edition or Windows Server 2003 x64, or does GLib (built as x64 binaries) even work on these platforms? The thing is, if there isn't really I have been successfully building and testing virt-viewer (a Gtk2 application, but using quite recent GLib) on xp 2003 x64. need for such setups, I guess it might be good for me to move the MSVC x64 builds to not include support XP/Server 2003 first in this cycle. So any thoughts on this? It would be nice if we can keep XP compatibility for a few more years (why would we need to drop it now?). XP support could be limited to mingw64, if it's complicated to keep MSVC support? -- Marc-André Lureau ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ with latest mingw and gcc 4.8
See also bug https://bugzilla.gnome.org/show_bug.cgi?id=699673 On Mon, May 6, 2013 at 11:07 AM, Aleksander Morgado aleksan...@gnu.orgwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 compiling gtk+-3.6.4 with latest mingw and gcc 4.8 leads to lots of errors like this one: /usr/local/mingw64-2.8/32/lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/lib/../lib/libuuid.a(lib32_libuuid_a-uuid.o):uuid.c:(.rdata+0x5f0): multiple definition of `FOLDERID_CommonPrograms' win32/.libs/libgdk-win32.a(gdkdnd-win32.o):gdkdnd-win32.c: The root cause is that in gdk/win32/gdkdnd-win32.c #define INITGUID is defined. which leads in i686-w64-mingw32/include/knownfolders.h that these known Folders are deifined again. But the are alread defined in libuuid. From my point of view the error is in gtk+ you should not define INITGUID. how can this be fixed properly? I just deleted the define for me. This define is still defined in HEAD revision, too. For reference, that is what Fedora is already doing in its mingw-gtk packaging: http://pkgs.fedoraproject.org/cgit/mingw-gtk2.git/tree/gtk-dont-define-initguid.patch - -- Aleksander -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGHcuYACgkQgxIgkKLogl7EqgCgwyaxi0DR8yqg/z3m9T4iOQxK jT4An2QjRfNT8PRIaQ3LX0obbpkVgPEo =09Q0 -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Marc-André Lureau ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Hi tarnyko On Tue, Apr 9, 2013 at 10:33 PM, tarn...@tarnyko.net wrote: Hi folks, As you may know, I'm currently working on a GTK+3 Win32/64 bundle. Sorry, I failed to reply on the threads before.. The build environments are currently based on MinGW, running on Win32 host (Win64 for the 64-bit builds). They are browsable online here : http://www.tarnyko.net/repo/gtk3_build_system/ It would be better if you could check in your scripts in a repository, so one could more easily study and eventually contribute to your effort. All the binaries should be fetched or build from the source (and verified). It should be easy and safe to reproduce and modify the build, by anyone at anytime. .bat scripts are quite poor, even for a build system. Makefile or python, powershell are probably more suited for the task. There are tons of build systems, but for targetting native windows build [1], I would really suggest looking at cerbero ( http://cgit.freedesktop.org/gstreamer-sdk/cerbero/). It is backing the gstreamer-sdk, which has some professional support, which is a real plus. Furthermore, it can do native and cross compilation, not only for Windows, but for Android and MacOS (and already includes gtk+ builds) The installation steps for cerbero can be a bit tedious, although with chocolatey it could be automated. It has been said that in order to be officially supported, Windows binaries should be compiled on a GNOME-owned machine. That is to say, in order to use my build environment, GNOME should own a Windows machine ^^. Is it the case now ? (no trolling intended, serious question). Have you investigated using a cloud windows server, such as EC2 or rackspace to host the windows machine? Imho, the windows SDK and DDK should be avoided. Only the headers should be required to compile, since we can cross-compile with mingw-headers, I would try to stick to that, probably avoiding any extra license fee or legal problems (I exclude the possibility of using VC completely, as very few projects actually can build with it afaik) It it's the case, then we could keep the buildenv as is. Or we could try to adapt it to a GCC cross-compile install under Linux, but I'd like to avoid that for reasons that I will explain further. If it's not the case, I will obviously need to adapt the buildenv to a GCC cross-compile install under Linux ; same thing, I'd like to avoid that, but I need to know. I believe some work is needed to be able to reuse cross-compiled projects under Windows. For example, the .pc file path will need to be adjusted etc. [1] I am very much a cross-build only guy, because Windows is not my work environment, cross-building is ridiculously easy thanks to projects like mingw-fedora, and scriptscompilers tend to be slower and break more on Windows because they are not tested as often. However, I came to the conclusion that there is no reason to have official gtk cross-built binaries. Each build system (MXE, OBS, fedora-mingw etc.) comes with its own set of packages, distribution, build infrastructure, community etc. It's actually better this way, just not that visible. Choose what you see fits best. But for native build, you don't have anything like that. So this is where this effort should aim. Eventually NuGet integration too. The number of people interested is probably larger in total than people doing cross-compilation. -- Marc-André Lureau ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Hi On Wed, Apr 10, 2013 at 11:05 AM, tarn...@tarnyko.net wrote: There are tons of build systems, but for targetting native windows build [1], I would really suggest looking at cerbero I prefer keep using vanilla MinGW, either on Windows or under Linux. Using a very particular and complex buildenv, possibly tied to lots of prerequisites, won't help in a long time. Plus it would mean maintenance for GNOME folks, too. Their build requirements is similar to yours or anyone: http://docs.gstreamer.com/display/GstSDK/Building+from+source+using+Cerbero. We are building the same set of packages after all. Building only gtk+ is really not enough in many cases. It's not going to fly if each project distribute its own set of binaries. Maintenance of a shared and proven project can be easier than a new standalone one. Many people who have experience with distro and windows build contributed to it. Also I think cerbero isn't that complicated, it looks quite elegant and powerful for what it does. -- Marc-André Lureau ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Wed, Apr 10, 2013 at 11:11 AM, Dieter Verfaillie
diet...@optionexplicit.be wrote:
I you mean the paths stated inside .pc files, then pkg-config on
windows should be able to automatically deduce the correct value for
${prefix} based on the location where said package is installed [1]
and ignore whatever is stated as ${prefix} inside the .pc file.
No adjustments should be needed.
This was made so by tml way back, when he used to ./configure
and make install each package into a separate prefix, stringing
things together (both for build and runtime usage) as needed
using PATH, PKG_CONFIG_PATH, ACLOCAL_FLAGS and other env vars.
Quite elegant, one can test (build and/or use) different versions
of packages fast, without having to go and build a complete
bundled distribution for each test (unless there's ABI breaks off
course).
Interesting, I didn't know (and I wouldn't try, I am cross-compiling guy :)
However, this isn't going to be enough, there are many variables in .pc
which may contain path. Also projects not using pkg-config have the same
problems. Doing a grep under fedora-mingw sys-root reveals that there are
many binaries that refer to hardcoded path too. In general, it's not going
to work if I try to reuse those cross-builds for doing native build.
Fortunately, by now, most of the runtime is working natively, but there are
still corner-cases (this is still one of the first thing you need to fix
when porting a lib/app)
--
Marc-André Lureau
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Wed, Apr 10, 2013 at 7:18 PM, Paul Davis p...@linuxaudiosystems.comwrote: to be relocatable, your app should *fall back* on -DPKGDATADIR but should first try checking for an environment variable and then a path relative to the executable. Or just rely on g_get_system_data_dirs(), that's what I usually do. https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-system-data-dirs -- Marc-André Lureau ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Wed, Apr 10, 2013 at 8:08 PM, Paul Davis p...@linuxaudiosystems.comwrote: i assume you mean as the fallback? You said, should first try checking for an environment variable and then a path relative to the executable., what environment variable? PKGDATADIR? Who set it? Is it only for the developper? If you have a good case for that extra environment variable, I would suggest to submit a patch to g_get_system_data_dirs(), It does the later, giving you a list of where to look for the data. So it could easily be tweaked to look for more locations. -- Marc-André Lureau ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
