Archives and 'X'

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Archives and 'X'

Greg Chicares
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.

------------------------------------------------------------------------------
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
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: Archives and 'X'

John Emmas
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


------------------------------------------------------------------------------
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
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: POSIX vs WINDOWS paths [WAS: Archives and 'X']

Earnie Boyd

Quoting John Emmas <[hidden email]>:

>
> 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

------------------------------------------------------------------------------
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
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: POSIX vs WINDOWS paths [WAS: Archives and 'X']

John Emmas
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


------------------------------------------------------------------------------
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
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: Archives and 'X'

Tor Lillqvist
In reply to this post by John Emmas
> 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

------------------------------------------------------------------------------
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
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: Archives and 'X'

John Emmas
----- Original Message -----
From: "Tor Lillqvist" <[hidden email]>
>
> What are those strange error codes? Pointer values! ;)
>
>> where can I find a list of GErrors
>
> A GError is a struct:
>
Thanks Tor.  I think I must have realised this while you were typing your
response

>
> 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.
>
Yes, I appreciate that - this was just a test to find out what was expected.
In fact, since posting I've discovered something that might be significant.
If I use a Unix-style path, like so:-

GdkPixbuf *const pixbuf =
gdk_pixbuf_new_from_file("/usr/local/share/icons/left_arrow.png", &error);
I consistently get this error:-

Failed to open file "/usr/local/share/icons/left_arrow.png". No such file or
directory.

Neither the path nor the type of file make any difference.  OTOH, if I pass
the full Windows path, like so:-

GdkPixbuf *const pixbuf =
gdk_pixbuf_new_from_file("c:/cygwin/usr/local/share/icons/left_arrow.png",
&error);  I consistently get a different error:-

Couldn't recognize the image file format for file
"c:/cygwin/usr/local/share/icons/left_arrow.png".

Once again, neither the path nor the type of file make any difference to the
error.

I must admit, I'm totally confused at the moment but it looks like
something's not quite right with my installation.

Thanks,

John


------------------------------------------------------------------------------
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
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: Archives and 'X'

Tor Lillqvist
> Failed to open file "/usr/local/share/icons/left_arrow.png". No such file or directory.

Which of course is as expected, as /usr exists only in Cygwin.

> OTOH, if I pass the full Windows path, like so:-

> GdkPixbuf *const pixbuf = gdk_pixbuf_new_from_file("c:/cygwin/usr/local/share/icons/left_arrow.png", &error);
>I consistently get a different error:-

> Couldn't recognize the image file format for file
> "c:/cygwin/usr/local/share/icons/left_arrow.png".

The most likely explanation is that the gdk-pixbuf library doesn't
find it's so-called loaders, which in many builds of GTK+ are separate
DLLs. How did you install the GTK+ runtime for Windows on your
machine? (Note that if you use the conceptually simplest way,
"installing" just means "unpacking a zip archive".) What version of
GTK+, downloaded from where? Did you move the files around with
respect to each others after installing, especially did you move the
DLLs into some other location, from which your program is now loading
them?

This is getting really off-topic for the MinGW-users list, but let's
solve this problem, and then if you have further questions about GTK+
on Windows, please use the gtk-app-devel-list list.

--tml

------------------------------------------------------------------------------
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
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: Archives and 'X'

John Emmas
----- Original Message -----
From: "Tor Lillqvist" <[hidden email]>
>
> This is getting really off-topic for the MinGW-users list, but let's
> solve this problem, and then if you have further questions about GTK+
> on Windows, please use the gtk-app-devel-list list.
>
Yes, I apologise for that.  I'll move to the other list if I don't get this
solved quickly.  However, I think you're probably right with this reply:-

>
> The most likely explanation is that the gdk-pixbuf library doesn't
> find it's so-called loaders, which in many builds of GTK+ are separate
> DLLs. How did you install the GTK+ runtime for Windows on your
> machine? (Note that if you use the conceptually simplest way,
> "installing" just means "unpacking a zip archive".)
>
Yes, that's exactly what I did - I just unpacked them from the zip file,
maintaining the directory structure.  I ended up with the main DLL's in
/usr/bin/ but I had to move them into /bin/ because /usr/bin/ is an alias in
Cygwin amd seems to be kept empty.  I remember seeing some more DLL's in
/usr/lib/gtk-2.0/2.10.0/loaders/  and wondering if I should add that
directory to my system path.  I remember thinking "this'll come back to
haunt me soon" and now it has.  My guess is that I need to add something to
my path so that those DLL's can be found.  There are 2 more orphaned DLL's
in  /usr/lib/gtk-2.0/2.10.0/engines/  so I'm a bit unclear about what I need
to add to my path....  :-(

John


------------------------------------------------------------------------------
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
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: Archives and 'X'

Tor Lillqvist
> Yes, that's exactly what I did - I just unpacked them from the zip file,
> maintaining the directory structure.  I ended up with the main DLL's in
> /usr/bin/

Hmm, I don't think it's ever a good idea to put non-Cygwin software in
the Cygwin structure, i.e. non-Cygwin executables into Cygwin's
/usr/bin (or /bin). That will just lead to confusion. At the very
least, put them in the /usr/local tree.

> I remember seeing some more DLL's in
> /usr/lib/gtk-2.0/2.10.0/loaders/  and wondering if I should add that
> directory to my system path. [...] My guess is that I need to add something to
> my path so that those DLL's can be found.

No. That won't help, as those DLLs are not directly linked to by any
binary (.exe or .dll), but loaded dynamically on request. It is enough
that PATH contains the directory where the "main" DLLs that the app
links to (libgtk-win32-2.0-0.dll etc) is.

The important thing here is that the relative locations of the "main"
GTK+ DLLs) and other files read by GTK+ at run time, like config files
(in etc/gtk-2.0), message catalogs (in share/locale) and dynamically
loaded DLLs (in lib/gtk-2.0/...) is kept intact.

--tml

------------------------------------------------------------------------------
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
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: Archives and 'X'

Matthew Talbert
Hi all,

I'm new to this list. I'm a developer for Xiphos (http://xiphos.org)
previously known as GnomeSword, a Bible study software. We are just
finishing up our port to Windows using msys/mingw for all our
development work. Thanks everyone, for all the work you've put into
this.

> > Yes, that's exactly what I did - I just unpacked them from the zip file,
> > maintaining the directory structure.  I ended up with the main DLL's in
> > /usr/bin/
>
> Hmm, I don't think it's ever a good idea to put non-Cygwin software in
> the Cygwin structure, i.e. non-Cygwin executables into Cygwin's
> /usr/bin (or /bin). That will just lead to confusion. At the very
> least, put them in the /usr/local tree.

I am by no means as experienced as Tor, but I would just like to add
that I think you would be better off using msys rather than Cygwin.
One of our developers uses Cygwin and we had various issues and
conflicts, that were resolved by moving strictly to msys. In addition,
I've read (sorry, no link) that it is difficult and somewhat magical
to actually build something under Cygwin that doesn't in the end
require Cygwin to run. You might be interested in our wiki page
http://www.crosswire.org/wiki/Gnomesword_for_Windows which details how
we build our software (it's based off of GNOME so would be fairly
similar to what you are dealing with).

Thanks again to everyone here, and in the gtk/GNOME context a huge
thanks to Tor for all of the work put into porting gtk/GNOME.

Matthew

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
MinGW-users mailing list
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: Archives and 'X'

John Emmas
In reply to this post by Tor Lillqvist
----- Original Message -----
From: "Tor Lillqvist" <[hidden email]>

>
>> I remember seeing some more DLL's in
>> /usr/lib/gtk-2.0/2.10.0/loaders/  and wondering if I should add that
>> directory to my system path. [...] My guess is that I need to add
>> something to my path so that those DLL's can be found.
>
> No. That won't help, as those DLLs are not directly linked to by any
> binary (.exe or .dll), but loaded dynamically on request. It is enough
> that PATH contains the directory where the "main" DLLs that the app
> links to (libgtk-win32-2.0-0.dll etc) is.
>
> The important thing here is that the relative locations of the "main"
> GTK+ DLLs) and other files read by GTK+ at run time, like config files
> (in etc/gtk-2.0), message catalogs (in share/locale) and dynamically
> loaded DLLs (in lib/gtk-2.0/...) is kept intact.
>
Thanks again Tor.  I spent a long time experimenting with this last night
but no matter where I put those loader DLL's they simply can't be found.
This morning I discovered a small file called "gdk-pixbuf.loaders".  In my
previous version of cygwin (with the GKT-x11 backend) this contained the
actual path for each loader.  However, since I've upgraded, it contains
entries like:-

"c:/devel/target/5e32e6f9bd779a13110a7c6ff9016d6e/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.dll"

which (I guess) was the relevant path on the original developer's system.
gdk-pixbuf.loaders is an automatically generated file so I guess that
gtk-win32-dev can't simply be "installed" by unpacking a zip file.  I
probably need to rebuild the modules for my system.

Anyway, we're way outside the scope of this mailing list now so I'll need to
transfer this question to gtk-app-devel-list.  Thanks for all the help
you've given with this.

Just out of interest, has anyone here managed to make gdk-pixbuf work with
MinGW?  And did they need to rebuild the dev modules after unpacking them?

John


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
MinGW-users mailing list
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: Archives and 'X'

John Emmas
In reply to this post by Matthew Talbert
----- Original Message -----
From: "Matthew Talbert"
Subject: Re: [Mingw-users] Archives and 'X'
>
> I am by no means as experienced as Tor, but I would just like to add
> that I think you would be better off using msys rather than Cygwin.
> One of our developers uses Cygwin and we had various issues and
> conflicts, that were resolved by moving strictly to msys. In addition,
> I've read (sorry, no link) that it is difficult and somewhat magical
> to actually build something under Cygwin that doesn't in the end
> require Cygwin to run.
>
Yes, that's an unavoidable consequence of using Cygwin, as is (apparently)
the need to use 'X' and gtk-x11, rather than gtk-win32.  However, although
these are drawbacks, the big plus for developers is that so many
"Cygwin-ised" libraries are already pre-built and available from
repositories.  This takes away a lot of the pain of getting on board with
Cygwin.

A few posts back, Earnie mentioned that a MinGW package repository has been
considered but it would force people to use a particular compiler.  I think
this is broadly similar to Cygwin.  For example, Cygwin Ver 1.5 uses gcc 3.4
as its standard compiler.  If you download any pre-built modules, they'll
have been built with that compiler and it's expected that you'll build your
own apps with the same compiler.  You can use a different compiler if you
wish but then you'd need to rebuild all the pre-built modules and sort out
any problems yourself.

Admittedly I haven't yet installed MinGW.  I've just been trying out some of
the elements that I'd need (e.g. GTK-win32) if I did decide to make the
switch.  However, that one library has given me endless grief and I don't
relish the prospect of going through all that pain with the dozens of other
libraries that I'll need to build.

I did find your wiki quite interesting Matthew but it'd be more interesting
to know how long it took you to get everything else working (before you
could make a start on your own project).  It looks like that would have been
a major task, just in itself.

A repository for pre-built MinGW packages?  I don't know enough to be able
to discuss the issues involved but it was a real godsend for me when I
started with Cygwin.  In fact, Cygwin would probably have ended up in the
bin if I'd had to build everything myself from source.

Given the compiler limitation, is there a case for a "MinGW-ports" project,
similar to "Cygwin-ports"?  Or is it one of the basic attractions of MinGW
that you can use compilers other than gcc?

John


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
MinGW-users mailing list
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: Archives and 'X'

Vincent Torri


On Tue, 3 Feb 2009, John Emmas wrote:

> A repository for pre-built MinGW packages?  I don't know enough to be able
> to discuss the issues involved but it was a real godsend for me when I
> started with Cygwin.  In fact, Cygwin would probably have ended up in the
> bin if I'd had to build everything myself from source.

afaik, gnuwin32 [1] provides a lot of libs that can be used with MSYS /
MinGW

regards

Vincent Torri

[1] http://gnuwin32.sourceforge.net/

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
MinGW-users mailing list
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: Archives and 'X'

Tor Lillqvist
In reply to this post by John Emmas
> "c:/devel/target/5e32e6f9bd779a13110a7c6ff9016d6e/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.dll"
>
> which (I guess) was the relevant path on the original developer's system.

Yes, that path ending in the hex string is the (temporary) build
prefix for that particular version and build of GTK+. But this is as
expected, and need not be changed. Uless you have deliberately broken
the installation, everything will automagically work anyway. Read my
full reply in gtk-app-devel-list.

> Just out of interest, has anyone here managed to make gdk-pixbuf work with MinGW?

Of course. For instance GIMP for Windows is built with MinGW, uses
GTK+ including gdk-pixbuf, has had millions of downloads over the
years, and presumably works fine for the large majority of users.
(Sure, as always on Windows, there are people who have managed to
screw up  or "enhance" their machine in various innovative ways, and
then it doesn't work for them. Oh well.)

> And did they need to rebuild the dev modules after unpacking them?

I don't know what exactly you mean with this, but at least the
gdk-pixbuf.loaders file does not need to be edited, even if it
contains pathnames that don't exist on the end-user system. There is
code in gdk-pixbuf to take care of this. (This is true only on
Windows. On Unix, including Cygwin, the paths in the
gdk-pixbuf.loaders file must be existing true paths. But that is also
as it should be, on Unix the convention is that packages are installed
where the packager has decided that they must be installed.)

--tml

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
MinGW-users mailing list
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: Archives and 'X'

Earnie Boyd
In reply to this post by John Emmas

Quoting John Emmas <[hidden email]>:

> A few posts back, Earnie mentioned that a MinGW package repository has been
> considered but it would force people to use a particular compiler.

IIRC the post you refer to, I was saying that _my_ preference is to
compile all libraries with the same compiler.  That statement doesn't
force anyone to use a particular compiler.  My preference ensures _me_
that all ABI for all libraries are the same.

Earnie

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
MinGW-users mailing list
[hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: Archives and 'X'

Matthew Talbert
In reply to this post by John Emmas
> Yes, that's an unavoidable consequence of using Cygwin, as is (apparently)
> the need to use 'X' and gtk-x11, rather than gtk-win32.  However, although
> these are drawbacks, the big plus for developers is that so many
> "Cygwin-ised" libraries are already pre-built and available from
> repositories.  This takes away a lot of the pain of getting on board with
> Cygwin.

If by libraries you mean libraries that you are going to link against,
this is going to cause lots of trouble I think. There are gtk win32
binaries for a huge chunk of the gtk world, so I'm not sure which
others you would need.

> Admittedly I haven't yet installed MinGW.  I've just been trying out some of
> the elements that I'd need (e.g. GTK-win32) if I did decide to make the
> switch.  However, that one library has given me endless grief and I don't
> relish the prospect of going through all that pain with the dozens of other
> libraries that I'll need to build.

You shouldn't need to build any gtk libraries.

> I did find your wiki quite interesting Matthew but it'd be more interesting
> to know how long it took you to get everything else working (before you
> could make a start on your own project).  It looks like that would have been
> a major task, just in itself.

When I started I was a novice at c/c++ development, gtk development,
autotools, and pretty much every other needed skill. I successfully
built and ran GnomeSword (its name then) including all needed
libraries in just a week. That includes setting up the environment. In
fact, I would write off the entire first 6 days as just learning the
basics of the setup (which are now detailed for you in the wiki I
linked). After 6 days, I started over completely and had my first
successful build in 8 hours.

To answer your above question about pixbuf loaders, our project uses
this library (at least, I believe it does as I'm fairly certain any
loading of images for menus, etc is done with this library). We have
not had any issues with this or any other gtk library, nor have we had
any issues with the "target" you mentioned. For more fun stuff, check
out the .pc file for any library.

I really think you are making things harder than they would have to be
by using cygwin. As I am still a novice, I'll bow out at this point.
Hopefully you can get some help on the gtk list.

Matthew

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
MinGW-users mailing list
[hidden email]

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
12