Re: Glib cross complilation
narcisse doudieu siewe schreef op vr 01-08-2014 om 16:39 [+0100]:
I need to compile GLib 2.40 for the windows platform on my ubuntu
14.04 so I use the following command: ./configure --host=i586-mingw32
but this fails with the following errors:
checking for i586-mingw32-windres... no
checking for windres... no
configure: error: * Could not find an implementation of windres in
your PATH
I wan to know if I can bypass windres because I notice that it is not
included in the /usr/i586-mingw32msvc/bin folder or if it is possible
to download it
Thank for your help.
Hi,
The ${host}-windres tool should be part of the binutils package
belonging to the MinGW cross compiler. I don't know how this package is
named on Ubuntu, but on Fedora and OpenSuSE it is part of the
mingw32-binutils package. If it is missing from the Ubuntu
(cross-compiled) binutils package you should get in contact with the
package maintainer.
Regards,
Erik van Pienbroek
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+-3.9.10 build fixes for MinGW
Martin Schlemmer schreef op di 30-07-2013 om 16:30 [+0200]: Hi First two hunks (g[dt]k/Makefile.am) fixes regressions due to commits: https://git.gnome.org/browse/gtk+/commit/gdk/Makefile.am?id=d08d7f2c5a4c4c28a774119f8e1dd88e5fca1681 https://git.gnome.org/browse/gtk+/commit/gtk/Makefile.am?id=d08d7f2c5a4c4c28a774119f8e1dd88e5fca1681 A similar patch to fix this win32 build issue was already submitted in https://bugzilla.gnome.org/show_bug.cgi?id=700445 The third hunk (testsuite/gtk/Makefile.am) fix a regression from commit: https://git.gnome.org/browse/gtk+/commit/testsuite/gtk/Makefile.am?id=c5e241147b6f710fcefde5d54582ea3936f48807 (defaultvalue does not build on win32). A fix for this one was also already submitted in https://bugzilla.gnome.org/show_bug.cgi?id=704173 The last hunk (modules/input/gtkimcontextime.c) fixes undefined values from gdkkeysyms-compat.h. I assume the duplicate added include of gdkkeysyms.h from commit: https://git.gnome.org/browse/gtk+/commit/modules/input/gtkimcontextime.c?id=493ca20912a9a84b3b13f44c1e99b97eb75dd943 should have been to include gdkkeysyms-compat.h. I wasn't aware of this issue yet (the commit in pretty recent), but I would recommend you to create a separate patch containing this specific snippet and propose it at bugzilla Regards, Erik van Pienbroek Fedora MinGW SIG ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: STDOUT_FILENO and STDERR_FILENO
John Emmas schreef op ma 20-05-2013 om 11:53 [+0100]: On 19/05/2013 12:23, John Emmas wrote: Just updated from Git and tried to build libglib using MSVC. The build fails because a couple of files are now referencing 'STDOUT_FILENO' and/or 'STDERR_FILENO'. From the (admittedly, limited) research I did, it seemed as if they're only relevant for *nix, bash and Wine. Here are the affected source files in case someone wants to check them:- glib/gtestutils.c gio/tests/filter-cat.c gio/tests/gdbus-eavmple-server.c I've attached a couple of sample patches, either of which should fix the problem for 'glib/gtestutils.c'. I'm not sure which of them would be considered as more preferable..? One minor thing to take into account is that stdout and stderr are not always file descriptors 1 and 2 on Windows environments. When an executable is built with '-mwindows' (instead of '-mconsole') then there is no stdout/stderr by default. To get a stdout/stderr one has to use the win32 API functions AttachConsole and freopen which in turn will return different file descriptors than 1 and 2. See also this bugreport which I filed some time ago (with patch) regarding g_log on Win32: https://bugzilla.gnome.org/show_bug.cgi?id=692085 Regards, Erik van Pienbroek Fedora MinGW SIG ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: STDOUT_FILENO and STDERR_FILENO
John Emmas schreef op ma 20-05-2013 om 14:06 [+0100]: Also (in theory) it should only attempt to write to the console if stdout / stderr appears to be valid (hopefully Windows would set them to NULL if they weren't valid?). The documentation about the Win32 API function fileno() has this to say about that specific situation: In Visual C++ 2005, there is a behavior change. If stdout or stderr is not associated with an output stream (for example, in a Windows application without a console window), the file descriptor returned is -2. In previous versions, the file descriptor returned was -1. This change allows applications to distinguish this condition from an error. http://msdn.microsoft.com/en-us/library/zs6wbdhx%28v=vs.80%29.aspx So when there is no valid stdout/stderr the fileno call will return either -1 or -2. When this value is passed as argument to a write call, then the write call itself will fail with an 'invalid file descriptor', but other than that there's shouldn't be any major issues with it. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Composite GtkBuilder template
Nicola Fontana schreef op do 09-05-2013 om 15:15 [+0200]: The build fails during cross-compilation with: ./extract-strings.exe /home/aur/archlinux/fedora-mingw-w64-gtk3/src/gtk+-3.9.0/gtk/gtklockbutton.ui gtklockbutton.ui.h /bin/sh: ./extract-strings.exe: cannot execute binary file Some days ago I filed a bug for this issue: https://bugzilla.gnome.org/show_bug.cgi?id=699690 ___ 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
tarn...@tarnyko.net schreef op do 11-04-2013 om 15:12 [+0200]: Native build + easier (works around most problems in configure scripts and Makefiles) I'd have to disagree here. In order to build gtk on a windows host then you basically need to arrange these things yourself first: - Install msys (which contains sh.exe which is needed to run the configure script) - Install the mingw.org or mingw-w64 compiler - Manually build (or download precompiled files for) all gtk+ dependencies (like gettext, libiconv, pixman, cairo, libjpeg, ...) When you use the cross-compiled packages which various distros are providing then all these steps are already arranged for you. For example on Fedora it's sufficient to run 'yum-builddep mingw32-gtk3' and all dependencies which are needed to allow building of gtk3 will be installed automatically (including the compiler). Once all dependencies are installed it's sufficient to run 'mingw32-configure make' from your source tree and there you go. For Fedora we've created an instruction which describes how commonly used cross-compiling tasks can be performed: https://fedoraproject.org/wiki/MinGW/Tutorial Regards, Erik van Pienbroek Fedora MinGW SIG ___ 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
Dieter Verfaillie schreef op wo 10-04-2013 om 21:04 [+0200]: If anybody feels like making the KnownFolders.h stuff work (and getting it in mingw mingw-w64) and un-bit-rotting that branch (and getting it in glib proper), please feel free to do so. Don't think I'll be able to go back working on that for at least another couple of months... The knownfolders.h header was recently added to mingw-w64 already [1]. Unfortunately it causes a build regression in gdkdnd-win32.c for both gtk2 and gtk3. In the Fedora MinGW gtk2 and gtk3 packages we've worked around this for now with [2]. Before this patch can be included in the upstream gtk+ git it needs to be tested on other compilers (msvc, mingw.org and older mingw-w64 releases) first to make sure it doesn't introduce other breakages. Regards, Erik van Pienbroek Fedora MinGW SIG 1: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64?view=revisionrevision=5589 2: http://pkgs.fedoraproject.org/cgit/mingw-gtk3.git/commit/?id=82ccf489f4763e375805d848351ac3f8fda8e88b ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib on Windows for Windows Stroe apps
arnaud collard schreef op di 02-04-2013 om 08:34 [+]: I was wondering if Glib could work on Windows 8 embedded in a Windows store application. The VLC developers (in collaboration with the mingw-w64 developers) are currently working on a library called 'winstorecompat'. This library wraps various Win32 API functions which are considered 'forbidden' for use in Windows Store apps and replaces them with 'good' Win32 API functions The initial commit of this helper library has this comment: -- libwinstorecompat: new library to help porting to Windows Store This library can be linked to code targetting Windows Store. Functions that are not available anymore for Windows Store are redefined, using similar functions that are allowed. 'Forbidden' functions can be found either by browsing MSDN, either by running WACK (Windows Application Certification Kit) on the application. For now the only symbol redefined is CreateEventW() but others will follow. Note: this library has no headers, since we don't add new functions but only redefine existing ones. For this to work, -lwinstorecompat should appear on the linking cmdline after object files using it, but before any library defining the same symbols. In this case: -lkernel32 So: gcc -shared -o foo.dll foo.o -lwinstorecompat -lkernel32 should work. -- It would be interesting to find out if GLib can be made Windows Store compliant with this helper library. I'm sure upstream would welcome contributions where more 'forbidden' Win32 API functions are implemented. This library can be found in the mingw-w64 SVN repository at http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-libraries/winstorecompat/ Regards, Erik van Pienbroek Fedora MinGW SIG ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Plans for GTK+ Bundles for win32 and win64?
Op Fri, 09 Sep 2011 12:29:38 +0200, schreef Jean-Philippe Chancelier: Hello, I am cross-compiling windows gtk-applications and I would be interested by the opposite task. I have a .ddl (or a .dll + dll.a) generated by cross-compilation and I would like to produce an import .lib file without having to use VC i.e from Linux. Does anyone know if such a tool exists ? Regards, JP The mingw.org wiki has a page dedicated to this: http://mingw.org/wiki/MSVC_and_MinGW_DLLs It describes how to create MSVC import libraries for gcc compiled dll's and the other way around. In order to create MSVC import libraries from a Linux host, you'd probably have to copy the lib.exe from MSVC to your Linux environment and excute it using wine. I also recall some references that the .a files coming from mingw-w64 compiled dll's (not the mingw.org toolchain) can be used directly by MSVC, but don't pin me on that. Kind regards, Erik van Pienbroek ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Plans for GTK+ Bundles for win32 and win64?
Op Thu, 08 Sep 2011 13:41:00 +0300, schreef Kalev Lember: There's also the option to go with cross-compiling from Linux. There are at least two separate efforts which use the gcc cross-compiler to produce ready-made binary Windows libraries, including the full GTK+ stack. In early 2009, Richard W.M. Jones started the Fedora MinGW project [1] which uses the mingw.org [2] runtime / libraries / headers. The idea was that there was too much fragmentation and duplication of work because at that time pretty much everybody had to build their own set of libraries; the Fedora MinGW project would make it easier by distributing binary library packages that everybody could reuse and contribute back to. For the last couple of months various people in the Fedora MinGW project (including Kalev Lember and me) started to work on introducing the mingw- w64 toolchain (version v2.0-rc1) and porting all current (about 110) mingw packages which are already in Fedora to generate both win32 as well as win64 binaries [1][2]. The most important difference between this effort and the OBS effort is the fact that both win32 and win64 binaries are built from the same .spec file (for the people who are not familiar with RPM: this is the file which contains instructions how a package must be built). This means that every time an upstream releases a new version of their software the package maintainer only has to update the package in one place instead of two places (like currently is the case with the OBS effort). As an added bonus, we've also got a darwinx cross compiler! With the work we've done so far it is possible to generate win32, win64 and darwinx binaries at the same time using the same .spec file. Unfortunately we won't be able to add the darwinx cross compiler to the main Fedora repository because of the use of 'forbidden licenses' so this will have to remain in a separate repository for the time being, but that shouldn't be too much of an issue. As already mentioned in another posting in this thread: the Fedora mingw- w64 effort currently stalled because we're still waiting on approval from Red Hat Legal. That's why all development of testing of these packages is currently done in a testing repository. We expect that the legal approval will be given soon and once that is the case we can start merging everything from the testing repository back to the main Fedora repository so the packages will become part of the next Fedora release. The list of mingw packages which are currently already part of Fedora can be found at [3]. Kind regards, Erik van Pienbroek [1]: https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework [2]: http://lists.fedoraproject.org/pipermail/fedora-mingw/2011- January/003285.html [3]: http://koji.fedoraproject.org/koji/search? match=globtype=packageterms=mingw* ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
