This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] mingw-w64

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

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.


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:

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

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

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


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.


I'd just call this: mingw64-binutils. ditto with


However, these all conflict with the cygwin binutils:


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


However, as currently constructed you still have the similar conflicts
with cygwin gcc4:



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)

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

If so, then I'd add another symlink or two:

usr/x86_64-w64-mingw32/i686-pc-mingw32 ->
usr/x86_64-w64-mingw32/mingw64         ->

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:


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:


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


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


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:



G++ RUNTIME DLL =================================== w64-mingw64-gcc4-libstdc++-4.6.20100619-1.tar.bz2


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


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:


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:



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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]