mingw-users Mailing List for MinGW - Minimalist GNU for Windows

On Thu, 2007-05-31 at 10:09 +0100, Keith MARSHALL wrote:
> Please
> register as site users, and use the comments facility at
> http://www.mingw.org/cms/drupal_on_mingw_todo

I'm not sure what it is about this page but it freezes firefox
completely on my Xandros box at work.  I'll have to try again at home
with Debian 4.0 Ice Ape.  FWIW I have never seen this firefox freeze
like this.  I had to kill -5 pid.

Cheers,
James.

Fredric Johansson wrote:
> About a month ago there was talk about www.mingw.org/download.shtml
> not being as up to date as it should be. Keith requested patches for
> it to update it. At that time I thought fixing it, but I never got
> around to do it, until today.

No problem; at least you did get around to it, before anyone else.

> I think I managed to remove all references to the file-table, added
> a new subheading "Downloads" and fixed an incomplete sentence under
> "Installing MinGW". Is this good enough to get that page updated?
> If you have any comments please post them.

Thanks Fredric.  I've had a quick look.  Apart from one or two very
minor grammatical glitches -- understandable, since I'm sure English
is not your native language -- it looks good.  I'll fix the grammar,
and apply it, just as soon as I can get around to it.

FYI, we have plans afoot to completely replace the existing MinGW.org
site content, with Drupal managed content.  You will find a preview
of the new look at http://www.mingw.org/cms  Comments are welcome;
volunteers to participate in the effort, even more so.  Please
register as site users, and use the comments facility at
http://www.mingw.org/cms/drupal_on_mingw_todo

Regards,
Keith.

Aaron Gray wrote:
> checking for C compiler default output file name... configure:
> error: C compiler cannot create executables

This used to stop a virgin build of the mingw-runtime libraries;
as part of the standard configure test for the compiler, it tries
to link a minimal executable.  For this to succeed, the linker
must be able to locate crt0.o, one of the library components that
we are trying to build, so of course, it doesn't exist yet.  Thus,
the link fails, configure decides that it can't find a working
compiler, and stops dead.

Of course, to build a runtime library, it isn't necessary to have
a compiler which can create fully functioning executables; it is
sufficient that it can emit object files.  To work around this
chicken and egg scenario, GCC configury includes a hack to defeat
autoconf's default requirement that a compiler must be able to
create executables; this hack is deployed for the purpose of
building the runtime libraries.

AFAIK, current versions of mingw-runtime and w32api should also
incorporate this GCC hack, so you shouldn't be seeing this error
when you build those specific components.  That you are seeing
it suggests that, at whatever point it occurs, your runtime
libraries and associated object components have not (yet) been
installed where the compiler expects to find them.

Regards,
Keith.

James Steward escribió:
> Hi Folks,
> 
> I hope some of you have had some Microsnot experience writing client RPC
> applications to talk to a *nix style RPC server.
> 
> I've just read http://docs.freebsd.org/44doc/psd/22.rpcgen/paper.pdf
> that describes how to write both a simple server and client application
> compiled and run on *nix.  With little effort I got it working between 2
> Linux boxes.
> 

Apart from your compiling troubles, you may want to know about DCE-RPC / 
  NDR and ONC-RPC / XDR.

cheers
--
chafar

On Thu, 2007-05-31 at 12:13 +1000, James Steward wrote:
> I found a (not) working example
> http://www.codeproject.com/internet/rpcintro1.asp .  When I go to
> compile the midl generated Example1_c.c file with gcc I get all sorts of
> warnings and errors.

In trying to compile just the Example1_c.c file, I used the command,
gcc -c -DTARGET_IS_NT50_OR_LATER=1 -o Example1_c.o Example1_c.c

Without the -DTARGET.... the compile complains and errors out.

The /mingw/include/rpcdcep.h file structure definition for
RPC_CLIENT_INTERFACE differs from the one I found in 
c:\Program Files\Microsoft Platform SDK\Include\RpcDcep.h.  There is a
missing unsigned int Flags at the end of the structure in the MinGW
version.

Regards,
James.

Hi Folks,

I hope some of you have had some Microsnot experience writing client RPC
applications to talk to a *nix style RPC server.

I've just read http://docs.freebsd.org/44doc/psd/22.rpcgen/paper.pdf
that describes how to write both a simple server and client application
compiled and run on *nix.  With little effort I got it working between 2
Linux boxes.

My goal is to have a Linux RPC server application that is remotely
called by a WinXP client.

Trouble is, when I started reading the Windows documentation it left me
in a daze.  I started from here
http://msdn2.microsoft.com/en-us/library/aa379010.aspx and when I got to
here http://msdn2.microsoft.com/en-us/library/aa378705.aspx I was nearly
ready to beg for mercy ;-)

I found a (not) working example
http://www.codeproject.com/internet/rpcintro1.asp .  When I go to
compile the midl generated Example1_c.c file with gcc I get all sorts of
warnings and errors.

Does anyone know of or have a decent MinGW RPC working example I could
learn from?

Cheers,
James.

On 2007-05-30 15:42Z, Steve Blinkhorn wrote:
> I have the source code for a DLL that was designed to be compiled
> under MSVC.   I need to make a static library from this source code to 
> link into a (complex) fully-static executable that I have been
> building under mingw.   But this source code has one function that is
> all inline assembler, and one, just one, line of this assembler won't
> translate into the gnu syntax for gas.

First of all, did you try '.intel_syntax'? Otherwise...

> At least it's beyond me (I
> just use intel2gas).

One option is to post the line that doesn't translate, along
with whatever context is necessary for it to make sense.
Maybe someone here or on some 'intel2gas' list can help you
rewrite it. It would be helpful to copy and paste any error
message you get from that tool.

Another option is to figure out what the asm function does,
and rewrite it completely in an asm dialect that the gnu
assembler accepts, or in a higher-level language. Perhaps
the author can give guidance there.

Or maybe you can just use ms tools, or something else like
'nasm', to assemble this one file and link the resulting
machine code to the binary you produce with gcc.

>>> http://dessent.net/tmp/gcc-vista-3.4.5-20060117-1.tar.gz
>>><http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972>
>>
>> I also found this which is what I really needed to patch GCC 4.2.0 :-
>>
>>    http://gcc.gnu.org/ml/gcc/2007-05/msg00228.html
>>
>> Thanks everyone :)
>
> I am trying to build GCC 4.2.0 on MinGW on Vista. I have patched GCC 4.2.0
> system.h with the access() hack and patched insn-modes.c's printf %n bug.
> But am still getting what I presume is an access() X_OK bug.
>
> Do I need a new patched version on MinGW runtime and if so could you give 
> me
> a link to it and any other new patched files please.

Ah, I am getting exactly the same bug on XP, so its a GCC4.2.0/MinGW issue 
:(

    checking for C compiler default output file name... configure: error: C 
compiler cannot create executables

Back over to working on Linux then :(

Aaron

>> http://dessent.net/tmp/gcc-vista-3.4.5-20060117-1.tar.gz
>><http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972>
>
> I also found this which is what I really needed to patch GCC 4.2.0 :-
>
>    http://gcc.gnu.org/ml/gcc/2007-05/msg00228.html
>
> Thanks everyone :)

I am trying to build GCC 4.2.0 on MinGW on Vista. I have patched GCC 4.2.0 
system.h with the access() hack and patched insn-modes.c's printf %n bug. 
But am still getting what I presume is an access() X_OK bug.

Do I need a new patched version on MinGW runtime and if so could you give me 
a link to it and any other new patched files please.

Aaron

I have the source code for a DLL that was designed to be compiled
under MSVC.   I need to make a static library from this source code to 
link into a (complex) fully-static executable that I have been
building under mingw.   But this source code has one function that is
all inline assembler, and one, just one, line of this assembler won't
translate into the gnu syntax for gas.   At least it's beyond me (I
just use intel2gas).

Of course it compiles with MSVC, but I could use some clear guidance
about:

1. Can I simply rename a static foo.lib file from MSVC to libfoo.a and
link as normal.

2. When I do 1., it is clear that the linker is trying to resolve
external references via _imp__MyFunc entry points rather than MyFunc.
Is this a matter of MSVC setup options?   Something in the source (I
thought I had removed anything that looked as if it were setting
things up to be a DLL)?

3. Or do I need to go through an extra step that I am missing?

--
Steve Blinkhorn <st...@pr...>

Hello

About a month ago there was talk about www.mingw.org/download.shtml not 
being as up to date as it should be. Keith requested patches for it to 
update it. At that time I thought fixing it, but I never got around to do 
it, until today.

I think I managed to remove all references to the file-table, added a new 
subheading "Downloads" and fixed an incomplete sentence under "Installing 
MinGW". Is this good enough to get that page updated? If you have any 
comments please post them.

Fredric

_________________________________________________________________
Så blir du kvitt mamma-magen 
http://e-health.msn.se/traning/Mamma_Bli_kvitt_magen_4789.html

Julien Lecomte wrote:
> I believe that mingw-runtime should trim the spaces on the right
> before calling WinMain and that results should be more consistent
> under cmd.exe.  Should we or not modify mingw-runtime to trim
> those spaces?

I believe this is more likely to be an issue with the way in which
MSYS' sh.exe reconstructs the command line it passes to the child
process, rather than a problem in mingw-runtime.

Any native Woe32 process receives its arguments as a single string
of characters.  Whatever you type on the cmd.exe command line just
gets passed verbatim to the child; this includes any leading or
trailing spaces which happen to be present, after the command name
has been carved off, and up to any following command separator.  The
only exception to this is that redirection operators are actioned,
and filtered out.

MSYS' sh.exe, OTOH, behaves like any UNIX shell.  It parses each
command line, expanding one level of quoting, and constructs an
argument vector; this is then passed to the child through an `exec'
function call, (after forking a process in which to run the child).
To make this work in the Woe32 world, MSYS' `exec' function has to
reconstruct a single command line argument string, from the passed
argument vector; it is this reconstructed string which is then
passed to the child, via the system's own `CreateProcess' function.

I don't think it would be practical to make sh.exe reproduce the
behaviour of cmd.exe, wrt redundant white space; here are just a
few of the reasons which spring to mind:

1) While constructing the argument vector for `exec', one level of
   quoting is expanded; the quoting characters are discarded.

2) In this process, all unquoted white space is discarded.

3) Attempting to modify this behaviour would, in all likelihood,
   destroy sh.exe's variable expansion and command substitution
   features.

4) sh.exe supports a much richer set of quoting capabilities; it
   is not practical to simply pass all quoting directly to a Woe32
   process, which is unlikely to understand the syntax.

One thing which does seem odd, is the single trailing space left on
the *unquoted* argument in your example; I would not have expected
the MSYS `exec' function to add that, so it could be considered a
bug, which we may wish to investigate.  Please raise a ticket on
the bug tracker:
https://sourceforge.net/tracker/?func=add&group_id=2435&atid=102435

FWIW, you should also note that Woe32's own `exec' function, as
provided by MSVCRT, is critically broken wrt the quoting of grouped
arguments with included white space, which are present in the passed
argument vector.  The disfunctional `spawn' functions, which MSVCRT
provides instead of the `fork()...exec()' API is identically broken.
For an explanation, and GPLed workaround, see:
https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82725&release_id=366538

Regards,
Keith.

(NB: I'm replying to a post in another thread, because for some reason, 
even if I did receive a post ack, when I create a new thread my post 
mysteriously never gets through. I'm sorry.)


Vincent Torri's mail on WinMain, CommandLineToArgvW and
GetCommandLineA/W made me notice the following "bug" which can be tested
with the following code:

== BOF test1.c ==
#include <stdio.h>
#include <windows.h>

int APIENTRY
WinMain (HINSTANCE hinstance,
   HINSTANCE hPrevInstance,
   LPSTR     lpCmdLine,
   int       nCmdShow)
{
   printf("lpCmdLine (%d) = **%s**\n", strlen(lpCmdLine), lpCmdLine);
   // strip right trailing spaces
   CHAR* cstrip = lpCmdLine + strlen(lpCmdLine) - 1;
   while (*cstrip == ' ')
     *cstrip-- = 0;
   printf("stripped (%d) = **%s**\n\n", strlen(lpCmdLine), lpCmdLine);
   return 0;
}
== EOF test1.c ==

I've noticed that the mingw-runtime will:
- often add at least a trailing space when using several commands in a row.
- convert/remove quotes in some cases.

With the folowing commands (please note that spaces can be important)
$ gcc test1.c -o test1.exe
$ ./test1.exe "toto1"
$ ./test1.exe 'toto2'
$ ./test1.exe toto3&& ./test1.exe toto4
$ ./test1.exe toto5       && ./test1.exe toto6

I get the selected following results:

With console MSYS shell
(TERM=cygwin; MSYSTEM=MINGW32)

julienlecomte@PUMILIO ~/procrast
$ ./test1.exe "toto1"
lpCmdLine (6) = **toto1 **
stripped (5) = **toto1**

$ ./test1.exe 'toto2'
lpCmdLine (6) = **toto2 **
stripped (5) = **toto2**

$ ./test1.exe toto3&& ./test1.exe toto4
lpCmdLine (6) = **toto3 **
stripped (5) = **toto3**

lpCmdLine (6) = **toto4 **
stripped (5) = **toto4**

$ ./test1.exe toto5       && ./test1.exe toto6
lpCmdLine (6) = **toto5 **
stripped (5) = **toto5**

lpCmdLine (6) = **toto6 **
stripped (5) = **toto6**


With console cmd.exe:

M:\home>test1.exe "toto1"
lpCmdLine (7) = **"toto1"**
stripped (7) = **"toto1"**

M:\home>test1.exe 'toto2'
lpCmdLine (7) = **'toto2'**
stripped (7) = **'toto2'**

M:\home>test1.exe toto3&& test1.exe toto4
lpCmdLine (5) = **toto3**
stripped (5) = **toto3**

lpCmdLine (5) = **toto4**
stripped (5) = **toto4**

M:\home>test1.exe toto5       && test1.exe toto6
lpCmdLine (12) = **toto5       **
stripped (5) = **toto5**

lpCmdLine (5) = **toto6**
stripped (5) = **toto6**


I might be able to understand why quotes are converted (toto1 and toto2 
for example) depending on console box as this might be an effect of the 
shell before creating the process.

On the other hand, I can't understand why behavior isn't the same in 
toto5 test case since I tend to believe that any command line will 
(should?) always be right space trimmed.

I believe that mingw-runtime should trim the spaces on the right before 
calling WinMain and that results should be more consistent under cmd.exe.
Should we or not modify mingw-runtime to trim those spaces?

> http://dessent.net/tmp/gcc-vista-3.4.5-20060117-1.tar.gz
><http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972>

I also found this which is what I really needed to patch GCC 4.2.0 :-

    http://gcc.gnu.org/ml/gcc/2007-05/msg00228.html

Thanks everyone :)

Aaron

 

> -----Original Message-----
> From: min...@li... 
> [mailto:min...@li...] On Behalf 
> Of Brian Dessent
> Sent: Sunday, May 27, 2007 4:54 PM
> To: MinGW Users List
> Subject: Re: [Mingw-users] Vista GCC cc1plus bug
> 
> > Aaron Gray wrote:
> 
> > When running GCC on MinGW32 on _Vista_ GCC is unable to find
> > cc1plus.exe and friends.
> > 
> > To hack this I have put /MinGW/libexec/gcc/mingw32/3.4.5 on 
> the PATH.
> > 
> > Thats fine until you want to build another version of GCC when it
> > falls over several times.
> > 
> > Is there a bug report and/or fix for this problem ?
> 
> This is due to a change in access() in MSVCRT no longer supporting the
> undocumented X_OK.  There is an updated mingw-runtime that contains a
> workaround.  There are updated MinGW gcc binaries available.  This has
> been discussed to death on this mailing list over the last 4 months or
> so, please read the fine archives.  Upstream gcc has not been 
> changed to
> stop using X_OK because it's a non-trivial change, as it is used often
> and its meaning is overloaded to also indicate that
> HOST_EXECUTABLE_SUFFIX needs to be appended.  Thus if you're building
> gcc you have to use the __USE_MINGW_ACCESS workaround.

And the GCC bug report is here:
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972>

Eric Weddington

Thanks to all of you for your disambiguating responses.

Erik.

----- Original Message ----- 
From: "Aaron Gray" <an...@be...>

If you have trouble finding it, here's an excerpt from a previous post of 
Brian's:

----------------------------------
If it helps anyone else, I took the three patched drivers that Danny
posted (gcc, g++, collect2) and copied them to their various aliases
(e.g. c++, mingw-g++, etc) and put them in the appropriate directory
structure, and made it a tarball:

http://dessent.net/tmp/gcc-vista-3.4.5-20060117-1.tar.gz

$ tar ztvf gcc-vista-3.4.5-20060117-1.tar.gz
-rwxr-xr-x brian/None    86016 2007-05-18 18:41 bin/c++.exe
-rwxr-xr-x brian/None    86016 2007-05-18 18:41 bin/g++.exe
-rwxr-xr-x brian/None    83456 2007-05-18 18:40 bin/gcc.exe
-rwxr-xr-x brian/None    86016 2007-05-18 18:41 bin/mingw32-c++.exe
-rwxr-xr-x brian/None    86016 2007-05-18 18:41 bin/mingw32-g++.exe
-rwxr-xr-x brian/None    83456 2007-05-18 18:40 bin/mingw32-gcc-3.4.5
-rwxr-xr-x brian/None    83456 2007-05-18 18:40 bin/mingw32-gcc.exe
-rwx------ brian/None    85504 2007-05-18 18:41
libexec/gcc/mingw32/3.4.5/collect2.exe

If you unpack this in your MinGW root folder (e.g. /mingw) just like all
the other gcc-foo tarballs it should install the files in all the right
places.  I tested this on a Vista copy running VMware and it worked fine
for compiling and linking C and C++.
----------------------------------

(That's for 3.4.5 only.)

Cheers,
Rob 

> Aaron Gray wrote:

> When running GCC on MinGW32 on _Vista_ GCC is unable to find
> cc1plus.exe and friends.
> 
> To hack this I have put /MinGW/libexec/gcc/mingw32/3.4.5 on the PATH.
> 
> Thats fine until you want to build another version of GCC when it
> falls over several times.
> 
> Is there a bug report and/or fix for this problem ?

This is due to a change in access() in MSVCRT no longer supporting the
undocumented X_OK.  There is an updated mingw-runtime that contains a
workaround.  There are updated MinGW gcc binaries available.  This has
been discussed to death on this mailing list over the last 4 months or
so, please read the fine archives.  Upstream gcc has not been changed to
stop using X_OK because it's a non-trivial change, as it is used often
and its meaning is overloaded to also indicate that
HOST_EXECUTABLE_SUFFIX needs to be appended.  Thus if you're building
gcc you have to use the __USE_MINGW_ACCESS workaround.

Brian

When running GCC on MinGW32 on _Vista_ GCC is unable to find cc1plus.exe =
and friends.

To hack this I have put /MinGW/libexec/gcc/mingw32/3.4.5 on the PATH.

Thats fine until you want to build another version of GCC when it falls =
over several times.

Is there a bug report and/or fix for this problem ?

Many thanks in advance,

Aaron

Erik Leunissen wrote:

> 1)
> The autoconf manual mentions as the format of the canonical system type:
> 
>      cpu-company-system
> 
> Does that entirely apply here? (I can't see how "pc" relates to company)

For the x86 architecture, the "company" field is essentially
irrelevant.  You can use "pc", but a lot of people question whether this
is a good idea -- what's a "pc" exactly?  Is a 32-core rackmount x86
server a PC?  Is an embedded device with 16 MB flash a "pc"?  The x86
architecture has great breadth, so calling everything a "pc" is kind of
silly, so it's slightly more PC (no pun intended!) to use "unknown" here
instead.  Some Linux distros insert their branding here, e.g.
ia64-suse-linux-gnu, x86_64-suse-linux-gnu, etc.  But that's mostly
cosmetic as far as I know.  It really doesn't matter that much, as long
as like Keith said you are internally consistent with how you decide to
label the target when creating your cross-toolchain.

This field is really more relevant for platforms made by a single
company:

s390-ibm-linux-gnu
sparc-sun-solaris2.10
powerpc-apple-darwin9
i686-apple-darwin8
hppa2.0w-hp-hpux11.11
...

> 2)
> How does one "run config.guess natively"?
> I can run it under cygwin, where it returns "i686-pc-cygwin".
> (I could run it under msys, but I do not have that installed.)

With MSYS.

Brian

On Sunday 27 May 2007 15:19, Brian Dessent wrote:
> > I am using a (linux) hosted MinGW to cross compile libraries which
> > are loaded/executed on a pc running Win2K [*].
> >
> > When using this setup, I need to run ./configure with the
> > "--host=3Dtype" option.
> >
> > What is the correct system type specification for the host in such
> > a setup?
>
> The canonical host triplet is defined by what config.guess returns
> when run natively on the host, which is i686-pc-mingw32. =A0Note that
> the 686 here means absolutely nothing about the specific processor of
> the system, nor does it mean you're generating code for any
> particular processor type, it just means "x86 family"; you could use
> practically any digit [3456] here with identical results.

It doesn't need to be a canonical host triplet, but neither can you just=20
specify anything arbitrary; the determinant is whatever prefix you are=20
using to designate your cross compiler tool chain.  If you've used our=20
build scripts, and accepted the default, that will give you a cross=20
compiler invoked as `i586-mingw32-gcc', (and similarly for the other=20
tools, `i586-mingw32-toolname'); with this, you need to specify the=20
`host_alias' as `--host=3Di586-mingw32', otherwise the configure script=20
will be unable to detect your cross compiler.  If your cross compiler=20
tool chain is identified by any other `tool_prefix', then you need to=20
adjust that `host_alias' accordingly.

On Sunday 27 May 2007 16:56, Erik Leunissen wrote:
> Thanks for your answer Brian,
>
> ...
>
> 1)
> The autoconf manual mentions as the format of the canonical system
> type:
>
>      cpu-company-system
>
> Does that entirely apply here? (I can't see how "pc" relates to
> company)

The `company' component is normally used to specify the manufacturer of=20
the CPU.  Since x86 CPUs use identical machine code, regardless of the=20
manufacturer, `pc' is used as a generic term.  IIRC, this is mentioned=20
in the autoconf manual; if not, it's stated within in `config.guess'=20
and `config.sub'.

> 2)
> How does one "run config.guess natively"?
> I can run it under cygwin, where it returns "i686-pc-cygwin".
> (I could run it under msys, but I do not have that installed.)

The canonical form only becomes important if the configure script uses=20
AC_CANONICAL_HOST autoconf macro, either directly or implicitly via=20
AC_CANONICAL_SYSTEM.  In either case, it will use `config.sub', not=20
`config.guess', to canonicalise the `host_alias' you specify.  You can=20
run that on your GNU/Linux host, to determine how your chosen form of=20
`host_alias' will be canonicalised as a Win32 host triplet.

Regards,
Keith.

On 27/05/2007 17:56, Erik Leunissen wrote:
> 1)
> The autoconf manual mentions as the format of the canonical system type:
>      cpu-company-system
> Does that entirely apply here? (I can't see how "pc" relates to company)

I'm too lazy to find the source of this info, but here is how I remember 
having read about it:
"pc" actually just means default or unspecified. It used to be "unknown" 
(eg. i386-unknown-linux) but apparently "unknown" was more confusing to 
users than "pc".

Thanks for your answer Brian,

For all practical purposes, I can proceed.

However, at a fundamental level, a few things are left:

> 
> The canonical host triplet is defined by what config.guess returns when
> run natively on the host, which is i686-pc-mingw32.  Note that the 686
> here means absolutely nothing about the specific processor of the
> system, nor does it mean you're generating code for any particular
> processor type, it just means "x86 family"; you could use practically
> any digit [3456] here with identical results.
> 

1)
The autoconf manual mentions as the format of the canonical system type:

     cpu-company-system

Does that entirely apply here? (I can't see how "pc" relates to company)


2)
How does one "run config.guess natively"?
I can run it under cygwin, where it returns "i686-pc-cygwin".
(I could run it under msys, but I do not have that installed.)

Erik.

Erik Leunissen wrote:

> I am using a (linux) hosted MinGW to cross compile libraries which are
> loaded/executed on a pc running Win2K [*].
> 
> When using this setup, I need to run ./configure with the "--host=type"
> option.
> 
> What is the correct system type specification for the host in such a setup?

The canonical host triplet is defined by what config.guess returns when
run natively on the host, which is i686-pc-mingw32.  Note that the 686
here means absolutely nothing about the specific processor of the
system, nor does it mean you're generating code for any particular
processor type, it just means "x86 family"; you could use practically
any digit [3456] here with identical results.

But you can also use a non-canonical version of the host triplet.  What
is acceptable here all depends entirely on how the macros are written;
it's really a type of freeform field with certain conventions.  For
example, the canonical host triplet for linux is i686-pc-linux (or even
i686-pc-linux-gnu) but sometimes you'll see people specify just
i386-linux.  You can look at common m4 / autoconf macros and see that
they typically match host using globs that are quite accomodating.  Thus
you'll often see people use just "mingw32" as the non-canonical host
triplet for MinGW, which should work fine everywhere as it's established
practice.

> Some basic system info, gained by executing under cygwin:
> 
> $ uname -srmpio
> CYGWIN_NT-5.0 1.5.18(0.132/4/2) i686 unknown unknown Cygwin

This is completely irrelevant.  The only thing this indicates is the
version of windows (NT 5.0 aka Win 2k) and the version of Cygwin.  And
the version of Windows has no bearing on the host triplet.

Brian

I am using a (linux) hosted MinGW to cross compile libraries which are 
loaded/executed on a pc running Win2K [*].

When using this setup, I need to run ./configure with the "--host=type" 
option.

What is the correct system type specification for the host in such a setup?

Thanks in advance,

Erik Leunissen
==============

[*]
Some basic system info, gained by executing under cygwin:

$ uname -srmpio
CYGWIN_NT-5.0 1.5.18(0.132/4/2) i686 unknown unknown Cygwin