[ITP] mingw-w64

[JonY]

On 6/30/2010 00:10, Charles Wilson wrote:
> On 6/28/2010 15:16, JonY wrote:
>> On 6/28/2010 14:53, Charles Wilson wrote:
>>> If you *really* want to prefix everything with w64 to indicate which
>>> "compiler family" they belong to, then something like
>>>         w64-mingw64-libgcc1
>>>         w64-mingw64-libstdc++6
>>>         w64-mingw64-libgfortran3
>>> or similar would be good. If the compiler is multilib (e.g. supports
>>> also -m32), then the 32bit runtime libs should have their OWN
>>> separate packages, perhaps
>>>         w64-mingw32-libgcc1
>>>         w64-mingw32-libstdc++6
>>>         w64-mingw32-libgfortran3
>>
>> now the packages are all prefixed with w64-mingw64 for 64bit and w32-
>> mingw64 for 32bit.
>
> Hmm.  While this makes sense for the header packages, runtime DLL
> packages, and implib packages, I'm not sure you needed to add "mingw64"
> to the binutils and gcc binary packages.  It's not like there's going to
> be a *separate* w64-mingw32-gcc or w64-mingw32-binutils, is there? I
> mean, that's kinda the whole point of "multilib":
>     w64-gcc*
>     w64-binutils
> would be the common w64 toolchain for building either mingw64 or mingw32
> apps...but
>     w64-mingw64-gcc4-libgcc1
>     w64-mingw64-crt
> would be the w64-specific runtime and linktime support, contrasted with
>     w64-mingw32-gcc4-libgcc1
>     w64-mingw32-crt
> are 32bit versions (derived from, and used by, the mingw64 multi-lib
> cross compiler).
>
>> Toolchain is now multilib capable, defaulting to
>> 64bit. Obj-c and obj-c++ can be done too, but I guess I should at
>> least get the packaging right first.
>
> Sure.
>
>> Sourceforge doesn't have an FTP, it makes things a bit hard, I'll try
>> to get an FTP server soon. Basically, its everything under:
>> <https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/
>
> FTP isn't necessary. Sure, it's a bit more difficult/time-consuming to
> dl individually, but if you are really dying to make the uploader's
> lives easier see Jari's recent postings with wget commands baked into
> the cake.
>
>> The pthreads import library and headers for i686-w64-mingw64 isn't
>> very useful right now without the actual toolchain up. The 32bit
>> import lib devel package for the 64bit is mirrored as w32*-devel64,
>> likewise for 64bit import lib for the planned 32bit toolchain as w64*-
>> devel32.
>
> I see.
>
>> As with import libs, the pthreads headers32 is for the i686-w64-
>> mingw32 toolchain while headers64 is for the x86_64-w64-mingw32
>> toolchain. The 2 are identical except for the installation path.
>
> Makes sense.
>
>
> I still think there are some packaging/naming problems.  How about
> getting the names hashed out before spending much more time re-packaging
> and re-uploading all the tarballs...I think that would be more
> productive.  Then, once the package names are nailed down, then we can
> make sure the setup.hints are all ok, so save those for later.
>
> Now, I thought you wanted to use the w64 prefix as a "project origin"
> indicator, and assumed that "-mingw64-" would be the "target bitdepth"
> indicator.  However, given  "w64-mingw64-pthreads-devel32" and
> "w32-mingw64-pthreads-headers32" I'm not sure that's the case. It seems
> NOW that you want to use 'mingw64' as the "project origin" indicator,
> and "w64"/"w32" as the target bit depth (and I'm sure the trailing '32'
> in these two anomalies is unnecessary).
>
> So, I think I'd put the project origin first, followed by the bit depth.
>

Yes, I was using w64/w32 as bitness indicator, as with some releases 
made with the buildbot on sf, mingw64 to differentiate it from mingw.org.

The trailing 32/64 is to indicate which toolchain the pthreads implibs 
are for, it is too possible to setup a 32bit default multilib setup, the 
current toolchain is defaulting to 64bit. So w64*devel32 means 64bit 
implib for 32bit default toolchain that has yet to bet setup.

For the current multilib toolchain example, users would want w32*devel64 
and w64*devel64 pthreads packages, 32bit and 64bit implib for 64bit 
default toolchain (the tarballs have the same installation path to the 
64bit libdir).

The pthreads naming is a bit confusing (to myself as well). I should 
change it to something easier. Ideas welcome.

>
> Secondly, due to what are (IMNSHO) bizarre triplet naming choices by the
> upstream mingw64 team, the triples for this compiler are
>
>     i686-w64-mingw32      -- 32bit
>   x86_64-w64-mingw32      -- 64bit
>
> But, that's built in to this compiler suite, it's not something that can
> or should be changed at this point just because I think it's silly. (I
> know *why* it was chosen: lots of configure tests are based on
> '*mingw32* )' and mingw64 wanted to piggy back that without having to
> modify every such package to support the mingw64 fork. Short term gain,
> long term confusion...).  Me, I would have bitten the bullet early, used
> 'mingw64', and worked on modifying upstream packages to support
> '*mingw*' instead. But, that's all water under the bridge now.
>
> Thirdly, this is very interesting....
>
>       usr/x86_64-w64-mingw32/x86_64-w64-mingw32/
>
> Oh boy. Back to the old days of /usr/$host/$target/ naming, eh?  I
> remember that from cygwin-B19.  We got LOTS of faqs about that; but we
> were using that naming even for the native cygwin compiler.  Here,
> you're a cross compiler, so presumably only users with some amount of
> technical savvy would be trying to use it, and will probably understand
> $host/$target naming.
>
> Except that in this case, the linker and compiler executables themselves
> are ACTUALLY i686-pc-cygwin, so...
>

No, it isn't meant to signify host. It is a workaround for GCC insisting 
on using "/mingw" for all mingw* targets, hence there is a "mingw" 
symlink to point to "x86_64-w64-mingw32". I'm sure we don't want a 
/usr/mingw clashing around if we do ever want another mingw cross 
compiler in Cygwin.

>
>
> BINUTILS
> ============================
> w64-mingw64-binutils-2.20.51-1.tar.bz2
> w64-mingw64-binutils-2.20.51-1-src.tar.bz2
>
> I'd just call this: mingw64-binutils. ditto with
>
>     usr/share/doc/Cygwin/w64-mingw64-binutils.README
>     usr/share/doc/w64-mingw64-binutils/
>
> However, these all conflict with the cygwin binutils:
>
> usr/share/info/as.info.gz
> usr/share/info/bfd.info.gz
> usr/share/info/binutils.info.gz
> usr/share/info/configure.info.gz
> usr/share/info/gprof.info.gz
> usr/share/info/ld.info.gz
> usr/share/info/standards.info.gz
> usr/share/locale/*/LC_MESSAGES/binutils.mo
> usr/share/locale/*/LC_MESSAGES/gprof.mo
> usr/share/locale/*/LC_MESSAGES/ld.mo
>
> That's bad, and I don't know any better way to fix it than to (a) don't
> install any of those files, or (b) use a different --prefix (or
> --datarootdir, but that violates cygwin policy).  (a) is bad because the
> message files expected by gcc-4.6.0 will differ from the ones supplied
> by cygwin gcc-4.3.4; and the documentation for the two versions
> obviously differs.  You could finesse the .info issue by renaming them
> with the target triple (as with man pages), but I don't think you can
> fix the LC_MESSAGES problem.
>
> Which leads to...use a different prefix as the only viable choice, I
> think (I'd go with /opt/mingw64/).  Or asking to use a non-standard
> --datarootdir -- and HOPE that the only conflicts we ever discover are
> these /usr/share ones.
>
>

I'm also not too sure how to proceed, --datarootdir sounds good.

>
> COMPILER EXECUTABLES
> ============================
> w64-mingw64-gcc4-4.6.20100619-1-src.tar.bz2
> w64-mingw64-gcc4-4.6.20100619-1.tar.bz2
> w64-mingw64-gcc4-g++-4.6.20100619-1.tar.bz2
>
> I'd just call these mingw64-gcc4-*, ditto with
>
> usr/share/doc/Cygwin/
> usr/share/doc/Cygwin/w64-mingw64-gcc4.README
> usr/share/doc/w64-mingw64-gcc4/
>
> However, as currently constructed you still have the similar conflicts
> with cygwin gcc4:
>
> usr/share/info/cpp.info.gz
> usr/share/info/cppinternals.info.gz
> usr/share/info/gcc.info.gz
> usr/share/info/gccinstall.info.gz
> usr/share/info/gccint.info.gz
> usr/share/info/libgomp.info.gz
> usr/share/locale/*/LC_MESSAGES/
> usr/share/locale/*/LC_MESSAGES/cpplib.mo
> usr/share/locale/*/LC_MESSAGES/gcc.mo
>
> Also,
> usr/share/man/man7/fsf-funding.7.gz
> usr/share/man/man7/gfdl.7.gz
> usr/share/man/man7/gpl.7.gz
>
>
> Which implies using a different --prefix, or not installing any of these
> conflicting files.
>
>
>
> PLATFORM HEADERS (approx. equiv. to cygwin's 'mingw-runtime' PLUS
> w32api, but only the header parts)
> ============================
> w64-mingw64-headers-20100628-1.tar.bz2
> w64-mingw64-headers-20100628-1-src.tar.bz2
>
> Both 32- and 64-bit?
>
> I'm not sure how that can be, since the contents are only under
> x86_64-w64-mingw32/ and not i686-w64-mingw32/, how does the -m32
> compiler find them?  Unless this symlink is the trick:
>

The 64bit default compiler with -m32 option will still look in 
/sysroot/mingw/include. So the same include is used for both.

> usr/x86_64-w64-mingw32/mingw ->
> /usr/x86_64-w64-mingw32/x86_64-w64-mingw32
>
> If so, then I'd add another symlink or two:
>
> usr/x86_64-w64-mingw32/i686-pc-mingw32 ->
> /usr/x86_64-w64-mingw32/x86_64-w64-mingw32
> usr/x86_64-w64-mingw32/mingw64         ->
> /usr/x86_64-w64-mingw32/x86_64-w64-mingw32
>
>

I was planning to use /usr/i686-w64-mingw32 for the 32bit default toolchain.

The 32bit toolchain has "lib" pointing to "lib32", while the 64bit 
toolchain has it pointing to "lib64", so it isn't exactly elegant to do 
that.

> In this case, unlike binutils and the gcc executable packages, I think
> I'd include both 'w32' and 'w64' to make it clear that the package
> includes the headers for BOTH bit depths:
>
> mingw64-w64-w32-headers
>
>

I was using w64-mingw64-headers because the installation path leads to 
the 64bit default toolchain.

>
> PLATFORM IMPLIBS (approx equiv. to cygwin's mingw-runtime PLUS w32api,
> but only the import library parts)
> ============================
> w64-mingw64-crt-20100628-1.tar.bz2
> w64-mingw64-crt-20100628-1-src.tar.bz2
>
>
> This package includes the implibs for both 32- and 64-bit. As is typical
> with multilib gcc -- but still to my eye quite odd -- the libraries are
> arranged thus:
>
> usr/x86_64-w64-mingw32/x86_64-w64-mingw32/lib/<<<  64 bit .a's
> usr/x86_64-w64-mingw32/x86_64-w64-mingw32/lib32/<<<  32 bit .a's
>                         ^^^^^^^^^^^^^^^^
>                        not really the $target,
>                        anymore, is it?
>
> I think I'd probably split this into two separate downloads:
>
> mingw64-w64-crt
> mingw64-w32-crt
>
> With the obvious division. This means you might "break" -m32 if you
> don't install mingw64-w32-crt, but maybe I only want to support -m64 on
> my computer?
>

OK, will split the package.

> Now, given the highly symlink-dependant nature of the
>     usr/x86_64-w64-mingw32/mingw
> aka
>     usr/x86_64-w64-mingw32/i686-pc-mingw32
> "tree", I think uses of -m32 mode need to be warned somewhere to NOT try
> to set up a mingw32 (32bit) sysroot under
>      usr/x86_64-w64-mingw32/i686-pc-mingw32 !
>
>

Right, users shouldn't touch anything usr/{i686,x86_64}-w64-mingw32/ at all.

To clear things up further, the multilib 64bit default toolchain will 
only read /usr/x86_64-w64-mingw32/mingw and 
/usr/x86_64-w64-mingw32/x86_64-w64-mingw32 even when -m32 is used.

>
>
> LIBGCC RUNTIME DLL
> ===================================
> w64-mingw64-gcc4-libgcc1-4.6.20100619-1.tar.bz2
>
> (First, no need to include 'gcc4' in the library package name).
>

I'm not sure how to do this with cygport. Any ideas?

> Currently contains both -m32 and -m64 versions of the DLL. I don't have
> a quibble about burying the DLLs deep inside the compiler paths; without
> setting a policy of where -m32 and -m64 sysroots should go:
>
>     /usr/mingw64/{bin, include, lib} + /usr/mingw32/{bin, include, lib}?
>     Probably not, because that might conflict with where a mingw.org
>     sysroot tree would go.
>
> So, better to not try and set policy, and keep everything "deep" for
> now, and let end users copy the DLLs where they want 'em. For now.
>
> However, this package contains BOTH:
>
> usr/lib/gcc/x86_64-w64-mingw32/4.6.0/libgcc_s_sjlj-1.dll
> usr/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libgcc_s_sjlj-1.dll
>
> but any given client is going to depend on one or the other, not both.
> The whole point of splitting the DLLs into individual packages is to
> make dependencies more granular.  So, this should really be:
>
> mingw64-w32-libgcc1
> mingw64-w64-libgcc1
>
>

OK.

>
> G++ RUNTIME DLL
> ===================================
> w64-mingw64-gcc4-libstdc++-4.6.20100619-1.tar.bz2
>
> Contains:
> usr/lib/gcc/x86_64-w64-mingw32/4.6.0/libstdc++-6.dll
> usr/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libstdc++-6.dll
>
> Again, no need to include 'gcc4' in the pkg name. However, you should
> also include the DLL version number in the package name.  I'd split this
> down as
>
> mingw64-w64-libstdc++6
> mingw64-w32-libstdc++6
>
>

I thought I had put it there, my mistake.

>
> G++ DEVEL LIBS
> ===================================
> w64-mingw64-gcc4-libstdc++-devel-4.6.20100619-1.tar.bz2
>
> Includes both w32 and w64 stuff.  Again, what if I want to use the
> mingw64 cross compiler to support only -m32? or only -m64? This too
> should probably be granular:
>
> mingw64-w64-libstdc++-devel
> mingw64-w32-libstdc++-devel
>
> with the obvious division.
>
>
> OTHER RUNTIME AND DEVEL LIBS
> ===================================
> w64-mingw64-gcc4-libgfortran3-4.6.20100619-1.tar.bz2
> w64-mingw64-gcc4-libgfortran3-devel-4.6.20100619-1.tar.bz2
> w64-mingw64-gcc4-libgomp1-4.6.20100619-1.tar.bz2
> w64-mingw64-gcc4-libgomp1-devel-4.6.20100619-1.tar.bz2
> w64-mingw64-gcc4-libssp0-4.6.20100619-1.tar.bz2
> w64-mingw64-gcc4-libssp0-devel-4.6.20100619-1.tar.bz2
>
> Probably should be treated similarly to G++ DEVEL LIBS:
>
> mingw64-w64-libgfortran3
> mingw64-w32-libgfortran3
> mingw64-w64-libgomp1
> mingw64-w32-libgomp1
> mingw64-w64-libssp0
> mingw64-w32-libssp0
>
> mingw64-w64-libgfortran-devel
> mingw64-w32-libgfortran-devel
> mingw64-w64-libgomp-devel
> mingw64-w32-libgomp-devel
> mingw64-w64-libssp-devel
> mingw64-w32-libssp-devel
>
>
> but I haven't looked at them closely.
>
>

Ok, right now, I should make all the dlls package common to 32bit and 
64bit defaulting toolchain, but I'm not too sure how to do it with 
cygport. Any ideas?