Please could you link all the binaries into /usr/i586-mingw32msvc/bin,
e.g. /usr/bin/i586mingw32msvc-gcc --> /usr/i586-mingw32msvc/bin/gcc?

This would make it easier to use some build systems by just setting a
prefix for all paths (/usr --> /usr/i586-mingw32msvc), so that systems
that do something like:

BINPATH = $prefix/bin
LIBPATH = $prefix/lib
INCPATH = $prefix/include

&c. The rest of the mingw32 package is nicely set up for this to work,
and indeed some of the binaries are already hard linked as I'd like
(e.g. strip and dlltool).

BTW, thanks very much for this package, it's great being able to
develop for Windows under Linux!

Hi,

This comes up from time to time, but I'm still not totally convinced
that this is an idiom we should be encouraging.  The upstream install
does not do this, and it is not what is recommended by autoconf.

What I'd really like to see before I go messing with it like this,
is some sort of documentation that clearly defines where and how
various cross tools should be installed -- so that whatever we do
is likely to work for any cross variant, not just this one.

I'm a little loathe to blaze out on our own if this may be a source of
future migration trouble, but I would also like to see this settled
once and for all before the end of time ;-)

These are from the -binutils...

but I agree that just makes it more confusing.

Nikita, can you throw any light on the direction we should be taking
here?  It seems to share some context with the recent discussion
re dpkg-cross.

cheers,
Ron

What does autoconf recommend? The current scheme doesn't play well with
it, and the scheme I suggest works fine with autoconf. In addition, by
using a unique prefix you're unlikely to clash with any other scheme, so
in the event of a future consensus you can fix things.

I've never seen any document on how cross-development related files should
be located. So I don't know how to do things properly :(

Under autoconf, you should only need to configure with --build and
--host set appropriately, and any properly generic build system
using the right tests, should just do the right thing.
See "Hosts and Cross-Compilation" in the autoconf docs.

Given that every cross platform app I use or have written works
with this, I'd have to say that it seems to be working ok...

Part of my fear of adding this change, is precisely that it
may be used to hide otherwise 'broken' build systems.  Do you
have a specific app we can refer to that does not work properly
like this?

My first guess at the problem would be that they are hardcoding
the names of the toolchain components, when they should be testing
for them with something like AC_PROG_CC &co.

But we are more likely to have people do things like PATH=/usr/i586-...
Which seems like its own road to a nasty clash.

I'd be a bit more in favour of this if you _weren't_ using autoconf,
but instead had a good (enough) generic makefile.  But if you are
using autoconf, we should fix the problems with using it correctly
first, then see what we still need.

I think it is going to take real examples to resolve this, as
if we try to talk hypothetically there are just far to many
possibilities for ways we _could_ do things, when I think its
most productive to try and determine how we _should_ do them,
and then recommend that as widely as possible.

cheers,
Ron

Why was the name 'i586-mingw32msvc' choosen?  To me this implies that
this build was compiled with Microsoft Visual C Compiler.  I'm very much
assuming it was not.

The (official?) mingw cross-compiler build scripts by Keith Marshall use
'i386-mingw32' and this is statically defined in the build scripts.  The README
states that the resulting cross compiler should be invoked as 'i386-mingw32-gcc',
but it does also create a directory full of binary stubs for gcc, ld, ar, etc.
as this original bug report suggests doing.

I do a bit of cross compiling using mingw and I find it quite annoying at
the scattered naming conventions that different distros use.

As a comprimise, why not just create symbolic links with some more standard
names?  For example: mingw32-gcc would be a symlink to i586-mingw32msvc-gcc or
whatever wonky prefix of choice is.

To indicate the target binaries for this build use the msvcrt runtime.

Until it can create linux targetted binaries, and be included in
the distro, it should be fairly safe to assume that remains a clear
impossibility, yes ;-)

I don't think Keith was around when the msvcrt runtime was new and shiny
and the crtdll runtime was old and reliable, and people needed the ability
to choose for themselves.  I've never seen Keith's scripts, but I'm pretty
sure these packages pre-date them by more years than I'd care to remember...

I can understand that he dropped the msvct/crtdll distinction, since mingw
itself dropped support for crtdll quite some time back now, but using
i386 for the target cpu would seem to indicate someone didn't put a whole
lot of thought into choosing that target designation very carefully...

And does it suggest there are good reasons for the latter?  I'm still
yet to see any that don't boil down to "work-around broken build scripts
in other packages" -- and it seems totally wrong and unproductive to me
to encourage the proliferation of broken build scripts and bad habits.

*shrug*  there were no other distro's providing this when the naming
conventions in this package were established.  It was even discussed on
the mingw lists IIRC.  I can't help others not following suit.

I'd surely get more hate mail from long time users if I gratuitously
changed the name now, than I get from people who want to hard code
things that they shouldn't.

If you really care about unified naming, you're going to need to get
all the affected parties together and come up with a plan to transition.
And then spend the next few years chasing everyone who didn't get the
memo.

Sorry, but I don't see that as a compromise, or even related to the
original request.  Hardcoding extra wonky prefixes, for cpu's that
neither Debian nor Billware support any more, so that build scripts
can be even _more_ broken, frankly seems quite insane.  The only thing
this could possibly help with is spreading confusion and Bad Practice.

If your build scripts can't handle any triplet that you might have a
toolchain for, from s390-mingw32crtdll to arm-linux-uclibc, then they
don't support cross compiling.  When they do, you won't need all this
extra goop, or feel the need to be annoyed at the number of possible
cross permutations.  There are more of them than you'll ever want to
hardcode.

(More) standard naming conventions for this sort of thing would be
lovely to have, but more names for the same toolchain on a single
system is an idea that should send a chill down your spine.

I've yet to see a real problem that had no other solution than this,
so in the absence of that, this kludge seems pretty hard to justify...
and the more time that goes by, the more of a kludge it appears to be.

YMMV, but I need real evidence of that before I'll be convinced that
messing with PATH is somehow a good thing to do for cross builds,
even without using a different name to the rest of the toolchain.

Cheers,
Ron