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

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,
> 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.
>
> Any thoughts?

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.  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.  I would prefer we offer cross compilers
32bit to 64bit and 64bit to 32bit and the user specifies the --host to
configure.  The one the user installs would be dependent on his
system.  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 so that mingw-get could check the
users system?  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?

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