Re: RFC: x86_64-pc-mingw64 and getting it mapped out

On Tue, Jul 2, 2013 at 5:40 AM, Keith Marshall wrote:
> On 25/06/13 20:48, Earnie Boyd wrote:
>> On Tue, Jun 25, 2013 at 8:38 AM, Earnie Boyd wrote:
>>> I've created myself a local source bakery for GCC, binutils and
>>> friends getting ready to think about providing 64bit toolsets.  I am
>>> currently attempting --host=i686-pc-mingw32 --build=i686-pc-mingw32
>>> --target=x86_64-pc-mingw64 builds.  Thinking about things like dwarf2
>>> vs sjlj, threading models of win32, pthreads and seh and the bitness
>>> of 32bit or 64bit I am considering being specific and creating
>>> "triplet" strings similar to i686-pc-mingw-dwarf2win32,
>
> Looks ugly, but expediency may need to win the day.
>

Yes, but ...

>>> x86_64-pc-mingw-sjljpthreads, etc.  This allows for
>>> /mingw/i686-pc-mingw-dwarf2win32/lib,
>>> /mingw/x86_64-pc-mingw-sjljpthreads/lib, etc to contain the disparate
>>> libraries.  Also, which of these should we consider for our default
>>> /mingw/lib directory?  Notice in this request I'm dropping the 32 and
>>> 64 indicators allowing the i686 and x86_64 to make the distinction of
>>> bitness.
>
> IMO, the mingw-w64 folks made a grave error of judgement over this
> decision; now you want to repeat it?  Please don't.
>

This is not mimicking mingw-w64, not even close.  It really has to do
with me thinking aloud.

My thought is that the host/target directories for various cross
compilers would contain the appropriate libraries.  So if the user
wants sjlj it goes in one named for that host.  Or if he wants dwarf2
it goes in that host.  And then you add varying threading models
(currently a count of three); but we would choose one hopefully but
dwarf2 isn't supported in 64bit Windows versions yet.

So you could do --host=i686-pc-mingw-dwarf2win32 for dwarf2 exceptions
and win32 threading model.  Or do --host=i686-pc-mingw-dwarf2pthreads
for the dwarf2 exceptions and pthreads threading model.

I'm not saying we distribute all of these but we have one set and give
instruction on using the source to create a cross.  I agree it is ugly
but it does allow for proper use of the configure script and the
process picking the correct compiler for the users desires.

>> The way GCC is currently coded for mingw-w64 it allows for multiple
>> libraries and depending on the version build being 32bit or 64bit
>> determines that $prefix/lib contains the 32bit or the 64bit and
>> $prefix/lib64 for the 32bit version or $prefix/lib32 for the 64bit
>> version.
>
> That's quite similar to the storage model also adopted for multi-arch
> installations on *nix.
>

Yes.

>> The user then uses -m32 or -m64 for if they want the alternative
>> library set.  While this has some benefits I see this nearly close to
>> -mno-cygwin.
>
> Yuck!
>

But it does support the lib/ lib32/ and lib64/ idea in the previous paragraph.

>> I would prefer we offer cross compilers 32bit to 64bit and 64bit to
>> 32bit and the user specifies the --host to configure.
>
> I agree.
>

I thought you would.

>> The one the user installs would be dependent on his system.
>
> Obviously.  We'd need to offer two native compiler builds, for mingw32
> and mingw64 respectively.  We'd also need two cross compiler builds, for
> (host=mingw32, target=mingw64), and (host=mingw64, target=mingw32) resp.
>

While we can go with mingw[32|64] as the host and
config.guess/config.sub are already coded for it.  My question in the
previous paragraph leads me to do we want to?  I don't care if we do;
but should we consider other options?

> Note that differing build methodologies apply to the distinct cases of
> building cross and native compilers.
>

Acknowledged.

>> Because a user could accidently select a 64bit package to be
>> installed for his 32bit system, which would fail to work, should we
>> somehow encode our package metadata
>
> Yes.
>
>> so that mingw-get could check the users system?
>
> As I build it, mingw-get runs as a 32-bit process.  It neither cares,
> nor needs to care, what the host's processor word size may be.
>
>> Or perhaps mingw-get 32bit would refuse to install 64bit packages and
>> a user with a 64bit system would need to install mingw-get 64bit to
>> install 64bit packages?
>
> No.  Not while I maintain it.  If you want me to continue in the role of
> mingw-get developer and maintainer, then please do not ask me to
> incorporate any such heuristic -- a.k.a. broken by design -- logic.  I
> will not take responsibility for any such bullshit; the behaviour of
> mingw-get is controlled by, and must continue to be controlled by, the
> dependency rules specified within the XML catalogue files with which it
> operates.

No need to get defensive or hostile about it; we just need to
understand how to help the user not install the wrong thing.
Suggestions for that appreciated.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev