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

On 03/07/13 21:21, Earnie Boyd wrote:
> 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.

The concept of "target" doesn't apply to libraries, (because they don't 
*generate* code; they furnish code which has been generated already for 
a specific "host").  You are correct, in your subsequent references to 
"host"...

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

I understand the intent; my concern is the maintenance burden.

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


Sure.  It's ugly, but not otherwise contentious.  I would prefer that we 
retain the "mingw32" vs. "mingw64" distinction, because that's how 
mingw-get will discriminate between 32-bit and 64-bit packages.

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

Okay.  There's nothing improper in that, but ... who's going to address 
the burden of documenting it?

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

Does that really convey a significant advantage?  Given ...

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

... that each such cross-compiler will live in it's own distinct tree, 
so each will have its own host specific sysroot/subtree, in which all of 
its pertinent headers and libraries will reside.  Your lib/ lib32/ 
lib64/ arrangement only has benefit for a multi-arch compiler, which you 
are saying you would prefer not to offer.  I agree with that preference: 
we may not have the manpower to maintain such a beast.

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

My existing linux hosted cross-compiler is selected by a simple:

    $ .../configure --host=mingw32 ...

It would be a minor inconvenience, (but an inconvenience nonetheless), 
if you were to demand that I rebuild it to require:

    $ .../configure --host=i686-pc-mingw ...

More crucially, I routinely use the $host_os component, derived from 
that via AC_CANONICAL_HOST, in my makefiles, to deduce the designated 
"sysroot" into which mingw-get should install generated packages; we 
need to preserve "mingw32" and "mingw64" to avoid ...

> Because a user could accidently select a 64bit package to be
> installed for his 32bit system, which would fail to work, ...

The "accident" shouldn't occur, provided we keep the two separate 
$host_os classifications, because mingw-get will install the two into 
independent sysroots.

> No need to get defensive or hostile about it;

Neither was intended.  However, you invited a discussion of a 
fundamental design decision, which I consider to be non-negotiable; 
mingw-get should not change its behaviour, based on whether it happens 
to have been built as a 32-bit or a 64-bit application, so let's not 
waste any more time in this blind alley.

> we just need to understand how to help the user not install the wrong
> thing. Suggestions for that appreciated.

mingw-get will DTRT, provided we keep the sysroot classifications 
unambiguous; "mingw32" and "mingw64" packages would be installed to 
independent, sysroot and architecture specific, directory trees.

-- 
Regards,
Keith.

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

Build for Windows Store.

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