From: John E. <jo...@ti...> - 2009-01-29 10:30:36
|
Firstly, please forgive me for not searching the archives but my question is about 'X' and I figured that such a search would throw up too many replies. In any case, I couldn't find a way to filter the archives. This page:- http://sourceforge.net/mailarchive/forum.php?forum=mingw-users offers a search bar but is seems to search the whole of Sourceforge (as opposed to just mingw-users). Am I missing something? Anyway, I'm just trying to find out how MinGW handles GTK applications. Cygwin handles them by emulating X but from what I've read about MinGW, its aim is to produce native Windows apps, rather than Cygwin's approach which requires Cygwin support DLL's to be installed on the target machine. So does a GTK app somehow come out looking like a native Windows app? Or does it retain its GTK appearance? And does MinGW need something akin to an X server? Thanks, John Emmas |
From: JonY <10...@gm...> - 2009-01-29 12:07:11
|
On 1/29/2009 18:30, John Emmas wrote: > Firstly, please forgive me for not searching the archives but my question is > about 'X' and I figured that such a search would throw up too many replies. > > In any case, I couldn't find a way to filter the archives. This page:- > > http://sourceforge.net/mailarchive/forum.php?forum=mingw-users > > offers a search bar but is seems to search the whole of Sourceforge > (as opposed to just mingw-users). Am I missing something? > > Anyway, I'm just trying to find out how MinGW handles GTK applications. > Cygwin handles them by emulating X but from what I've read about MinGW, its > aim is to produce native Windows apps, rather than Cygwin's approach which > requires Cygwin support DLL's to be installed on the target machine. > > So does a GTK app somehow come out looking like a native Windows app? Or > does it retain its GTK appearance? And does MinGW need something akin to an > X server? > > Thanks, > > John Emmas > Hi, MinGW GTK apps retain their GTK look and feel like their X server counterpart. The GTK+ toolkit has many back ends, one of them is Win32, you don't need an X server for the win32 back end. Hope that helps. |
From: John E. <jo...@ti...> - 2009-01-29 13:20:33
|
----- Original Message ----- From: "JonY" > > Hi, > MinGW GTK apps retain their GTK look and feel like their X server > counterpart. > > The GTK+ toolkit has many back ends, one of them is Win32, you don't > need an X server for the win32 back end. > > Hope that helps. > Yes thanks, that's very helpful. If it's not too cheeky, is there anywhere where I can download a (reasonably complex) GTK/MinGW app in binary form to see what it "feels" like. One of the things I'm most interested in is to find out how it looks and reacts in a dual-monitor environment. This is one area where Cygwin's reliance on 'X' emulation lets it down. I'm assuming that MinGW won't suffer from the same problems but it would be interesting to see for myself. Thanks again, John |
From: JonY <10...@gm...> - 2009-01-29 13:48:26
|
On 1/29/2009 21:20, John Emmas wrote: > ----- Original Message ----- > From: "JonY" >> Hi, >> MinGW GTK apps retain their GTK look and feel like their X server >> counterpart. >> >> The GTK+ toolkit has many back ends, one of them is Win32, you don't >> need an X server for the win32 back end. >> >> Hope that helps. >> > Yes thanks, that's very helpful. If it's not too cheeky, is there anywhere > where I can download a (reasonably complex) GTK/MinGW app in binary form to > see what it "feels" like. One of the things I'm most interested in is to > find out how it looks and reacts in a dual-monitor environment. This is one > area where Cygwin's reliance on 'X' emulation lets it down. I'm assuming > that MinGW won't suffer from the same problems but it would be interesting > to see for myself. > > Thanks again, > > John Hi, They're probably a few canned Windows GTK apps out there, here are a few I can think of: Pidgin <http://www.pidgin.im/> Wireshark <http://www.wireshark.org/> Gimp (Win32) <http://gimp-win.sourceforge.net/> You may need to install the GTK runtime environment, link: <http://gtk-win.sourceforge.net/home/index.php/en/Home> |
From: Tor L. <tm...@ik...> - 2009-01-29 14:25:59
|
> is there anywhere > where I can download a (reasonably complex) GTK/MinGW app in binary form The term "GTK/MinGW app" doesn't really mean anything. A GTK app on Windows consists of one or several Windows executables (exe and dll files). Once the app is built, there is nothing "MinGW" about it. You can't see from an executable's behaviour whether it was built with MinGW or with Microsoft's toolchain. There is no MinGW runtime that would need to be present (at least not for C code; for C++ code I think a small MinGW-specific DLL is needed. But GTK does not use C++.) Now, a Cygwin app is different. It requires the Cygwin runtime when run. --tml |
From: Tor L. <tm...@ik...> - 2009-01-29 14:18:19
|
> Anyway, I'm just trying to find out how MinGW handles GTK applications. Well, MinGW doesn't "handle" them, it just can be used to compile them. Or Visual C can be used. > Cygwin handles them by emulating X Cygwin is an operating system "emulator". MinGW is a toolchain. You can't compare them like this. That said, that GTK on Cygwin uses X is just a design choice by the people who build it. It would be possible to build GTK for Cygwin also to use the win32 backend, i.e. use the GDI API to display and manage the windows and GUI in them. > So does a GTK app somehow come out looking like a native Windows app? With "looking", do you mean the visual appearance? The visual appearance of a GTK app depends on what theme is used, if any. There is a theme for GTK that is specifically for use on Windows, which makes the GTK widgets look very much like Microsoft's widgets (although Microsoft doesn't call them "widgets", but "common controls" or something like that). To use this theme, put the line gtk-theme-name = "ms-windows" in the etc/gtk-2.0/gtkrc file of the GTK installation. (Or have the GTK app programmatically cause the same settings to be used.) But note that this just makes the GTK widgets *look* like the Microsoft ones. GTK doesn't use Microsoft's widgets. (Except for in the print dialog on Windows.) Or do you mean whether GTK apps are "native" Windows binaries that don't require Cygwin or something like that? Yes, GTK built for Windows has native normal Windows DLLs that don't require Cygwin or any other Unix emulation, or any X11 display. They use the plain old GDI APIs. GTK apps built for Windows are likewise native Windows executable > Or does it retain its GTK appearance? So apparently you are talking about visual appearance here? As I said, it depens on what theme, if any, are used. > And does MinGW need something akin to an X server? MinGW is a toolchain used to compile and link software for Windows. It has nothing to do with X. --tml |
From: John E. <jo...@ti...> - 2009-01-29 14:44:29
|
Thanks JonY and Tor, I wasn't aware that GTK supported different themes but that makes sense now that I know it (at first I was a bit puzzled by JonY's links because the screenshots looked pretty much like conventional Windows apps). Let me just ask a slightly dumb "newbie" question then.... what would be the reason for building with MinGW rather than (say) Microsoft Visual C++? Is MinGW better at compiling code that expects to be built in a Posix environment, for example? Thanks, John |
From: Tor L. <tm...@ik...> - 2009-01-29 15:05:38
|
> Let me just ask a slightly dumb "newbie" question then.... what would be > the reason for building with MinGW rather than (say) Microsoft Visual C++? Because the GTK+ stack itself, and typical Open Source apps that use GTK+, come with an existing build infrastructure (the configure.in and Makefile.am files etc that are mangled by various tools to produce a configure script and Makefiles) that work nicely only with a POSIXish environment like MSYS and MinGW as the compiler and toolchain. Most importantly, it is these Makefile.am and configure.in files that are actively maintained by people who work on the code and commit new files etc, and always up-to-date. That said, there are people who maintain Visual Studio project files for the GTK+ stack, too. GLib has VS project files in its tarballs, and I think they are up-to-date even. For more of the GTK+ stack, see this for instance: https://launchpad.net/oah > Is MinGW better at compiling code that expects to be built in a Posix > environment, for example? To some extent, yes, MinGW comes with a small amount of POSIX and/or C99 compatibility that exceeds that available in Microsoft's compiler. (One could say that this goes against the "Minimal" part of MinGW's name, and personally I am not that fond of such extensions, as it might make it harder to keep code easily compilable with both MinGW and MSVC.) But for the GTK+ stack, this doesn't matter: The intent is that the code shall continue be compilable with Microsoft's compilers, too. --tml |
From: JonY <10...@gm...> - 2009-01-29 15:17:05
|
On 1/29/2009 22:44, John Emmas wrote: > Thanks JonY and Tor, > > I wasn't aware that GTK supported different themes but that makes sense now > that I know it (at first I was a bit puzzled by JonY's links because the > screenshots looked pretty much like conventional Windows apps). > > Let me just ask a slightly dumb "newbie" question then.... what would be > the reason for building with MinGW rather than (say) Microsoft Visual C++? > Is MinGW better at compiling code that expects to be built in a Posix > environment, for example? > > Thanks, > > John > Hi, theoretically speaking, both are linking to Microsoft's C runtime. In practice, they handle slightly different for C code, mostly in areas of C99 and compiler specific extensions. So depending on the coding standards and portability policies of a software project, it might work with both, or 1 of them only. For C++, they both use different ABIs, lots of things can go wrong if you mix the code from different compilers. Recent versions of GTK+-2 for example supports building with MinGW, but not with Visual C++. Projects like OpenSSL and cURL, will works with both. |
From: Earnie B. <ea...@us...> - 2009-01-30 13:20:07
|
Quoting John Emmas <jo...@ti...>: > > Let me just ask a slightly dumb "newbie" question then.... what would be > the reason for building with MinGW rather than (say) Microsoft Visual C++? > Is MinGW better at compiling code that expects to be built in a Posix > environment, for example? > MinGW compilers are Open Source. MinGW extends the C runtime with some emulated POSIX functions. MinGW extends the C runtime for C99 compatibility. MinGW runtime source is distributable. MinGW windows API source is distributable. MinGW runtime and windows API is incomplete but contains the routines important enough for others to add patches. MinGW does not have its own pretty visual IDE but can be used with many IDE. MinGW compilers can use Microsoft's complete runtime and windows API; they don't have to use the MinGW runtime. Microsoft compilers are Closed Source. Microsoft runtime and windows API are not distributable. Microsoft runtime and windows API are complete. Microsoft compilers can only use the Microsoft runtime. Microsoft provides its own visual IDE. If others can think of things to add, please do. Earnie |
From: Xavier M. <xav...@ca...> - 2009-01-30 13:23:10
|
Visual C++ Debugger is better than GDB. We are friday, can I ? ;) Earnie Boyd a écrit : > Quoting John Emmas <jo...@ti...>: > >> Let me just ask a slightly dumb "newbie" question then.... what would be >> the reason for building with MinGW rather than (say) Microsoft Visual C++? >> Is MinGW better at compiling code that expects to be built in a Posix >> environment, for example? >> > > MinGW compilers are Open Source. > MinGW extends the C runtime with some emulated POSIX functions. > MinGW extends the C runtime for C99 compatibility. > MinGW runtime source is distributable. > MinGW windows API source is distributable. > MinGW runtime and windows API is incomplete but contains the routines > important enough for others to add patches. > MinGW does not have its own pretty visual IDE but can be used with many IDE. > MinGW compilers can use Microsoft's complete runtime and windows API; > they don't have to use the MinGW runtime. > > Microsoft compilers are Closed Source. > Microsoft runtime and windows API are not distributable. > Microsoft runtime and windows API are complete. > Microsoft compilers can only use the Microsoft runtime. > Microsoft provides its own visual IDE. > > If others can think of things to add, please do. > > Earnie > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > > _______________________________________________ > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. > > Most annoying abuses are: > 1) Top posting > 2) HTML/MIME encoded mail > 3) Improper quoting > 4) Improper trimming |
From: Kai T. <Kai...@on...> - 2009-01-30 13:32:58
|
Earnie Boyd <ea...@us...> wrote on 30.01.2009 14:20:04: > > Quoting John Emmas <jo...@ti...>: > > > > > Let me just ask a slightly dumb "newbie" question then.... what would be > > the reason for building with MinGW rather than (say) Microsoft Visual C++? > > Is MinGW better at compiling code that expects to be built in a Posix > > environment, for example? > > > > MinGW compilers are Open Source. > MinGW extends the C runtime with some emulated POSIX functions. > MinGW extends the C runtime for C99 compatibility. > MinGW runtime source is distributable. > MinGW windows API source is distributable. > MinGW runtime and windows API is incomplete but contains the routines > important enough for others to add patches. > MinGW does not have its own pretty visual IDE but can be used with many IDE. > MinGW compilers can use Microsoft's complete runtime and windows API; > they don't have to use the MinGW runtime. > > Microsoft compilers are Closed Source. > Microsoft runtime and windows API are not distributable. > Microsoft runtime and windows API are complete. > Microsoft compilers can only use the Microsoft runtime. > Microsoft provides its own visual IDE. > > If others can think of things to add, please do. > > Earnie One of the most important points is missing IMHO Mingw can be used as cross-compiler, so you have one build environment for different targets. Also (this is just true for 64-bits and is mostly related to gcc itself), we are producing faster code as the MS C13. Kai | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | (")_(") world domination. |
From: John E. <jo...@ti...> - 2009-01-29 17:33:22
|
----- Original Message ----- From: "JonY" > > Recent versions of GTK+-2 for example supports building with MinGW, but > not with Visual C++. Projects like OpenSSL and cURL, will works with both. > Okay, let me ask another question that might seem dumb to you guys. Cygwin comes with the equivalent of a "package manager" which can be used to install various common Linux libraries that have been pre-built in a "cygwin-ised" form. So for example I could install libxml2 or libraptor or libboost etc. I took a look at the MinGW site but I could only find a small number of packages relating to MinGW itself. So what if I wanted to build a particular open source project that relies on some standard Linux libraries (let's say, libraptor and libxml2). Would I be able to install libraptor and libxml2 binaries from a repository somewhere or would I need to obtain the source and build it using MinGW? John |
From: JonY <10...@gm...> - 2009-01-29 18:13:18
|
On 1/30/2009 01:32, John Emmas wrote: > ----- Original Message ----- > From: "JonY" >> Recent versions of GTK+-2 for example supports building with MinGW, but >> not with Visual C++. Projects like OpenSSL and cURL, will works with both. >> > Okay, let me ask another question that might seem dumb to you guys. Cygwin > comes with the equivalent of a "package manager" which can be used to > install various common Linux libraries that have been pre-built in a > "cygwin-ised" form. So for example I could install libxml2 or libraptor or > libboost etc. > > I took a look at the MinGW site but I could only find a small number of > packages relating to MinGW itself. So what if I wanted to build a > particular open source project that relies on some standard Linux libraries > (let's say, libraptor and libxml2). Would I be able to install libraptor > and libxml2 binaries from a repository somewhere or would I need to obtain > the source and build it using MinGW? > Hi, currently no, there are no official repositories. You will need to manually compile and build it from source yourself. There was some talk about a package manager sometime, not too sure what became of it though. |
From: Earnie B. <ea...@us...> - 2009-01-30 13:06:16
|
Quoting John Emmas <jo...@ti...>: > ----- Original Message ----- > From: "JonY" >> >> Recent versions of GTK+-2 for example supports building with MinGW, but >> not with Visual C++. Projects like OpenSSL and cURL, will works with both. >> > Okay, let me ask another question that might seem dumb to you guys. Cygwin > comes with the equivalent of a "package manager" which can be used to > install various common Linux libraries that have been pre-built in a > "cygwin-ised" form. So for example I could install libxml2 or libraptor or > libboost etc. > > I took a look at the MinGW site but I could only find a small number of > packages relating to MinGW itself. So what if I wanted to build a > particular open source project that relies on some standard Linux libraries > (let's say, libraptor and libxml2). Would I be able to install libraptor > and libxml2 binaries from a repository somewhere or would I need to obtain > the source and build it using MinGW? > I've seen the other responses to this but here is my take on this. I want to be sure that the library binaries meet the same ABI for the compiler/linker that I use. Therefore, I always build libraries from scratch. Using other ppl's builds may cause you unware problems just because the library was built with a different compiler. Earnie |
From: Tor L. <tm...@ik...> - 2009-01-29 19:30:22
|
>> So what if I wanted to build a >> particular open source project that relies on some standard Linux libraries >> (let's say, libraptor and libxml2). Would I be able to install libraptor >> and libxml2 binaries from a repository somewhere or would I need to obtain >> the source and build it using MinGW? > currently no, there are no official repositories. You will need to > manually compile and build it from source yourself. Never heard of libraptor. But for libxml2, actually, there *is* an "official" Windows binary package. "Official" in the sense that it is linked to from "the horse's mouth" so to say... www.libxml.org -> http://www.xmlsoft.org/downloads.html -> http://www.zlatkovic.com/libxml.en.html -> http://www.zlatkovic.com/pub/libxml/ That doesn't mean that everybody would be (re-)distributing exactly these binaries for Win32, of course. Typically people who build and distribute something larger on Win32 that depends on libxml2 have some good reason to either just repackage zlatkovic's packages (not recompile, but picke and split up what is in the zlatkovic zip files into different zip files or installers), or build libxml2 themselves from scratch. But then, so do Linux distros. Every distro recompiles each package from sources. So in a sense one could say that each installer for some software on Windows that includes a stack of common libraries is comparable to a different Linux distro. (Another similar case to libxml2 is zlib, where there is also one very "official" Win32 DLL right at the zlib.net site. Still there are many differently compiled zlib DLLs floating around.) --tml |
From: JonY <10...@gm...> - 2009-01-30 01:26:51
|
On 1/30/2009 03:30, Tor Lillqvist wrote: >>> So what if I wanted to build a >>> particular open source project that relies on some standard Linux libraries >>> (let's say, libraptor and libxml2). Would I be able to install libraptor >>> and libxml2 binaries from a repository somewhere or would I need to obtain >>> the source and build it using MinGW? > >> currently no, there are no official repositories. You will need to >> manually compile and build it from source yourself. > > Never heard of libraptor. But for libxml2, actually, there *is* an > "official" Windows binary package. "Official" in the sense that it is > linked to from "the horse's mouth" so to say... www.libxml.org -> > http://www.xmlsoft.org/downloads.html -> > http://www.zlatkovic.com/libxml.en.html -> > http://www.zlatkovic.com/pub/libxml/ > Hi, you're right, I thought John was referring to something like apt package manager for Debian. |
From: John E. <jo...@ti...> - 2009-01-30 10:30:55
|
----- Original Message ----- From: "JonY" Subject: Re: [Mingw-users] Archives and 'X' > > Hi, > you're right, I thought John was referring to something like apt package > manager for Debian. > Actually, I did mean that - but it's good to know about the other options. One thing I found very interesting in this thread was this:- ----- Original Message ----- From: "Tor Lillqvist" > > Because the GTK+ stack itself, and typical Open Source apps that use > GTK+, come with an existing build infrastructure (the configure.in and > Makefile.am files etc that are mangled by various tools to produce a > configure script and Makefiles) that work nicely only with a POSIXish > environment like MSYS and MinGW as the compiler and toolchain. Most > importantly, it is these Makefile.am and configure.in files that are > actively maintained by people who work on the code and commit new > files etc, and always up-to-date > How reliable is the "configure" and "make" build model under MinGW? I'm only asking because this is an area that I've found very hit-and-miss in Cygwin. Both the configuration files and makefiles often need to be "cygwin-ised" (i.e. patched) before they can be built and this is usually done by a "cygport" utility. The downside is that unless you're quite expert with Cygwin, the quickest option to getting something built is usually to wait until one of the experts builds it. Sometimes "configure" and "make" just work "right out of the box" but equally as often, they don't. Is that also the case for MinGW? Let me say that I'm not criticising Cygwin in that respect. There's a movement called "Cygwin-Ports" who are remarkably good at addng things to Cygwin's repertoire. However, their time is obviously limited. John |
From: Tor L. <tm...@ik...> - 2009-01-30 12:37:48
|
> How reliable is the "configure" and "make" build model under MinGW? Well, "make" as such is very reliable. It's the configury that generates Makefiles and config.h files etc that usually is tricky. It depends very much on how well the configure.in and Makefile.am files have been written for some particular software package. Unfortunately writing configure.in and Makefile.am files that work well both on Linux, other Unixes, in MSYS with MinGW, and for cross-compilation for instance from Linux (using mingw cross tools) to Win32, is not easy. There are too many liberties left to the developer;) And some developers get some things completely wrong, like having "make install" install headers that #include "config.h". Then there is libtool which has some very spectacular failure modes with interesting error messages. But once you have something that works well, it usually keeps on working well from version to version if only trivial changes, like adding new source files to some executable or library, adding a new library, etc are done. In the GTK+ stack that this thread initially mentioned this holds. (Except that one often has to trick around some libtool misfeatures. The build scripts are included in the developer packages of the GTK+ stack on ftp.gnome.org, in them you can see such tricks.) Some people say CMake is a much better alternative to autotools, libtool and Make. Other say CMake stinks;) And then there are things like SCons that I know nothing about. Yeah, it would be really great if there existed a nice and elegant tool, running on all kinds of Unix, Windows and MacOSX, without any "extra" requirements (like a Bourne-style shell, sed, awk, perl etc) that would supersede all of autofoo, libtool and make. Maybe such a tool even exists. But who could convince most maintainers of Open Source software to switch to this one tool to rule them all? It would be a very big task. Consider that Makefile(,am) files after all can contain arbitrary shell commands in the rules. How should a hypothetical über-tool do things that now use some complex shell command that invokes sed or awk? > The downside is that unless you're quite > expert with Cygwin, the quickest option to getting something built is > usually to wait until one of the experts builds it. The same holds for Win32 and MinGW, to an even higher degree. But even "the experts" have not been experts since birth. It just takes some effort and enthusiasm to learn this stuff... > Sometimes "configure" > and "make" just work "right out of the box" but equally as often, they > don't. Is that also the case for MinGW? Certainly yes. And as Windows is not Unix (unlike Cygwin, which very much tries to look and feel like Unix), much software can't even in theory be compiled for Windows, as the code uses Unix-only APIs, fork() being perhaps the most glaring example. --tml |
From: Earnie B. <ea...@us...> - 2009-01-30 12:58:03
|
Quoting John Emmas <jo...@ti...>: > How reliable is the "configure" and "make" build model under MinGW? I'm > only asking because this is an area that I've found very hit-and-miss in > Cygwin. Both the configuration files and makefiles often need to be > "cygwin-ised" (i.e. patched) before they can be built and this is usually > done by a "cygport" utility. The downside is that unless you're quite > expert with Cygwin, the quickest option to getting something built is > usually to wait until one of the experts builds it. Sometimes "configure" > and "make" just work "right out of the box" but equally as often, they > don't. Is that also the case for MinGW? > You might have to tweak the source here and there but the configure process isn't changed. We have an unreleased portmaker package you can find in CVS http://mingw.cvs.sourceforge.net/viewvc/mingw/portmaker/. A mingwPORT, we call it, creates a mingwport directory with scripts and the patch. It requires wget to be present to as well as MSYS. The scripts downloads the pristine file or asks the user where to find the file, extracts the file, applies the prepared patch, asks some configure questions, and executes configure and make. The mingwPORT releases in the FRS then contain just the contents of the mingwport/ directory. However, the packages released as a whole do not require anything special other than following the packaging name requirements. Earnie |
From: Greg C. <gch...@sb...> - 2009-01-30 13:45:43
|
On 2009-01-30 10:30Z, John Emmas wrote: > > How reliable is the "configure" and "make" build model under MinGW? I'm > only asking because this is an area that I've found very hit-and-miss in > Cygwin. Both the configuration files and makefiles often need to be > "cygwin-ised" (i.e. patched) before they can be built and this is usually > done by a "cygport" utility. The downside is that unless you're quite > expert with Cygwin, the quickest option to getting something built is > usually to wait until one of the experts builds it. Sometimes "configure" > and "make" just work "right out of the box" but equally as often, they > don't. Is that also the case for MinGW? It's fruitful to view this in terms of "programming by contract": http://en.wikipedia.org/wiki/Programming_by_contract where you desire a successful build as a postcondition resulting from combining different components, which may have their own preconditions and postconditions. To that end, I'll speak very generally and gloss over many details. Cygwin provides a posix emulator. Its contract is to fulfill your postcondition for posix code that doesn't exceed its emulator's capabilities, and for cross-platform code that needs no emulator. MSYS is a minimalist fork of Cygwin. Its contract is to fulfill the postcondition for cross-platform code that needs no emulator. [And MinGW is simply a gcc toolchain--the one MSYS typically uses. Cygwin provides its own gcc toolchain that's nearly identical.] In this context, the contract for an application you want to build is just to be portable: its postcondition must satisfy the build platform's preconditions. Many applications don't do this; that's probably the main reason why some "just work", while others don't. If the application calls the posix fork() function, then it's not portable to a non-posix platform like MSYS + MinGW, though it'll probably work with Cygwin. Similarly, if it calls windows system functions, it's not portable to a posix platform. That doesn't mean it's bad code; it's just not portable across platforms. There's no way that MSYS + MinGW can build a posix-dependent application, and that's not a defect of MSYS. If you need that to work, you must change the application to make it portable (or wait until someone else does). It's not useful to think of modifying MSYS to fill this gap, because MSYS is already fulfilling its contract. Because Cygwin's contract is broader (remember, MSYS is a subset of a fork of an older version of Cygwin), it's unlikely that an application will build on MSYS if it doesn't build on Cygwin. Cygwin does strive to conform to the published posix standard. Patching a posix application so that it works on Cygwin might entail working around a Cygwin issue, but it may just as well mean changing application code that relied on some behavior not required by the posix standard. Applications may also need to be patched because they rely on unspecified programming-language behavior. An uninitialized C variable might reliably have the value zero on *nix, for example, but have a random value on msw, and both those behaviors conform to the C standard. Hence, this syllogism: My program works great on GNU/Linux. It compiles and links fine with MinGW, but fails at run time. Therefore MinGW is broken. is generally not accepted at face value on this list, because the problem is usually that the program is defective. Fixing it isn't a matter of "adapting" it to MinGW, MSYS, Cygwin, or msw: instead, it means improving the program so that it works reliably on many platforms, rather than by accident on only one. Here's another example that frequently comes up on this list. The order in which libraries are specified to the linker doesn't seem to matter on ELF platforms as long as shared objects are used, but it matters for static linking on ELF, and for PE always. It's possible to write linker commands that work reliably for both, but sometimes a developer omits to do that, so the makefiles must be changed to make them more portable. Thus, my answer to your question: > How reliable is the "configure" and "make" build model under MinGW? is that it's quite reliable; and that it often doesn't do what you want; and that there's no contradiction between those statements. There's an awful lot of non-portable code out there that isn't meeting the "contract" described above. |
From: John E. <jo...@ti...> - 2009-02-02 12:22:00
|
Thanks to everyone who's contributed to this thread. I've learned an enormous amount since I started it and I've been very impressed by how comprehensive the replies are. Several posts back, Tor mentioned that GTK+ apps can be built in MinGW, thanks to GTK's Win32 backend so I took a look at the Win32 backend yesterday. I haven't yet installed MinGW (for the time being I'm still experimenting with Cygwin's gcc compiler, which is already installed) but one thing I immediately noticed was that almost every function that expects a file path seems to have been renamed in GTK+'s Win32 backend. This got me wondering whether (if I changed to MinGW) I'd also need to rewrite programs to use DOS-style paths - e.g. (case insensitive) "C:\\Documents and Settings\\john\\some_file") as opposed to the Unix-style paths that Cygwin favours - e.g. (case sensitive) "/home/john/some_file". I wrote a small app that does very little, apart from including these lines that worked previously when I was using the x11 backend:- gtk_init (&argc, &argv); GError* error = 0; GdkPixbuf *const pixbuf = gdk_pixbuf_new_from_file("/usr/local/share/icons/fader_belt.png", &error); With the Unix-style path, this function fails with error:- 0xea1a90 whereas if I change to a DOS-style path, it fails with error - 0xea1a50 (the file does exists, BTW). Can anyone tell me which style of path they'd be using if they were building with MinGW? Also, (I know it's outside the scope of this forum) but where can I find a list of GErrors, so I can hopefully see what the failure was due to. Thanks, John |
From: Earnie B. <ea...@us...> - 2009-02-02 12:38:18
|
Quoting John Emmas <jo...@ti...>: > > Can anyone tell me which style of path they'd be using if they were building > with MinGW? Also, (I know it's outside the scope of this forum) but where > can I find a list of GErrors, so I can hopefully see what the failure was > due to. > It depends on the function. All of the C functions accept either POSIX paths or WINDOWS paths, most of the windows functions will accept either POSIX or WINDOWS paths while some, E.G.: CreateProcess, requires WINDOWS paths. Earnie |
From: John E. <jo...@ti...> - 2009-02-02 14:09:07
|
Thanks Earnie - and please excuse my silly confusion over GError. It's not a simple enumeration (as I thought). After resorting to reading the manual I discovered that a GError is actually a struct containing error information. From the error I'm getting, it seems like I'm probably not setting something up that needs to be set up. I need to dig a bit deeper. John |
From: Tor L. <tm...@ik...> - 2009-02-02 14:11:18
|
> almost every function that expects > a file path seems to have been renamed in GTK+'s Win32 backend. Umm, are you referring to the functions that have been #defned in some headers to actually have an _utf8 appended? That is an implementation detail to handle some old backward compatibility isses that you should not care about. Use just the "normal" name of the function without any _utf8 suffix in your own code, pass just UTF-8 file names to GLib and GTK+ functions, and expect them to return UTF-8 file names, and don't worry. (The long story is that way back in time, GLib and GTK+ on Windows wanted file names to be in the "system codepage", but a policy decision was then made to just use UTF-8 everywhere instead. To avoid breaking existing binaries which expected the old behaviour, existing entry points kept the old behaviour, and instead new functions with _utf8 appended, and the #defines, were added so that freshly built code would use the UTF-8 API. New API that has been introduced since don't have any backward compatibility versions, they always use UTF-8 on Windows, and don't need any such #defines.) > This got me > wondering whether (if I changed to MinGW) I'd also need to rewrite programs > to use DOS-style paths - e.g. (case insensitive) "C:\\Documents and > Settings\\john\\some_file") as opposed to the Unix-style paths that Cygwin > favours - e.g. (case sensitive) "/home/john/some_file". You are now confusing three mostly unrelated things: 1) the UTF-8 vs. system codepage issue already explained above, 2) backslashes vs. forward slashes, and 3) pathnames as visible in some Unix emulation environment like Cygwin. Also, please don't use "DOS", just say "Windows". If you write code that will run on Windows (and not Cygwin, which really is a different operating system, even if it happens to run on top of Windows), then yes, you can obviously not use pathnames that are implemented by Cygwin, like /home. (Sure, you can have a top-level folder on your current drive in Windows called \home (or equivalently, /home), but let's assume that is not the case now.) As for the UTF-8 vs. system codepage issue, just be aware that pathnames (and all other strings, to be displayed in the GUI etc) you pass to GLib and GTK+, and that are returned from them, should be in UTF-8. This matters for non-ASCII characters only, of course. This is different from the C runtime, where functions like fopen() expect file names in system codepage, and thus can't access all possible file names. (Like file names containing Greek characters on an English Windows machine. Being able to handle any possible file name *is* an important point in GLib and GTK+.) In the C runtime (and the Win32 API), one needs to use the so-called wide character versions of the API to handle any possible file name. Those use UTF-16. Note that this issue has no direct equivalence on Unix, where file names are always just strings of bytes. Any interpretation as UTF-8 or ISO8859-1 or whatever is totally up to user code. Compare to Windows, where the actual file names as stored in the file system are in UTF-16. If you read documentation for C or C++ programming in old-fashioned Microsoft style, you might see talk about TEXT and TCHAR and tstrcpy() etc, and building in "Unicode mode" or "ANSI mode". Most of that is historical garbage that you really need not know these days especially if you use GTK+. Win9x is dead, there is no reason to bother with "non-Unicode" "modes". If using GTK+, you must use UTF-8. And when using the Win32 API, ideally just use the "W" versions of the API and wide character strings explicitly . Ditto when using the Microsoft C library, use the wide character versions of file-related functions explicitly. (But in a GTK+ program you should instead just use the wrappers from <gstdio.h> that take UTF-8.) > I wrote a small app that does very little, apart from including these lines > that worked previously when I was using the x11 backend:- > gdk_pixbuf_new_from_file("/usr/local/share/icons/fader_belt.png", &error); > With the Unix-style path, this function fails with error:- 0xea1a90 whereas > if I change to a DOS-style path, it fails with error - 0xea1a50 (the file > does exists, BTW). What exactly was the "DOS-style" path you passed to the function? Hopefully not something like "C:\\usr\\local\\share\\icons\\fader_belt.png" unless you really have a "usr" folder at the top level of you current drive? You should pass a path that is valid in Windows. Whether you use backslashes or (forward) slashes is mostly irrelevant. What are those strange error codes? Pointer values! ;) > where can I find a list of GErrors A GError is a struct: struct _GError { GQuark domain; gint code; gchar *message; }; the message field should contain a plain text error message. The domain and code fields are "codes", but there can't be any exhaustive list of them as any software that returns error information in the form of GError can use whatever codes they like. You will have to refer to the documentation for the API you are calling to see if it specifies the possible values for domain and code. > Can anyone tell me which style of path they'd be using if they were building > with MinGW? There is no choice. Use paths that are valid Windows paths. In UTF-8. Whether you use backslashes or (forward) slashes is mostly a matter of taste. You can even use both in the same file name, like: gdk_pixbuf_new_from_file("C:\\Program Files\\FooApp\\share/icons/mumble.png", &error) which might happen especially if you construct the file name at run-time. More important than worrying about whether to use backslashes or slashes is to realize that if you write software that you intend to distribute to others, you can not hard-code locations in the file system in your code. Except in very restricted environments, you can't know where some end-user is going to install your software. So if your code wants to open some file that is part of its installation at run-time, you can't hard-code the pathname to that file. You should determine at run-time where the software has been installed (typically based on the location of an .exe or .dll file of your software), and then construct the pathname to the file to be opened based on that. The GetModuleFileName function helps here. --tml |