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

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.

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

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

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

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

I agree.

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

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

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

-- 
Regards,
Keith.

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

Build for Windows Store.

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