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


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



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.



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:

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


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



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?

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 !




LIBGCC RUNTIME DLL
===================================
w64-mingw64-gcc4-libgcc1-4.6.20100619-1.tar.bz2

(First, no need to include 'gcc4' in the library package name).

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



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



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.



PTHREAD STUFF
===================================
More on these, later. I'm out of time for now:
w32-mingw64-pthreads-headers32-20100619-1.tar.bz2
w32-mingw64-pthreads-devel64-20100619-1.tar.bz2
w32-mingw64-pthreads-devel32-20100619-1.tar.bz2
w32-mingw64-pthreads-20100619-1.tar.bz2
w32-mingw64-pthreads-20100619-1-src.tar.bz2
w64-mingw64-pthreads-headers64-20100619-1.tar.bz2
w64-mingw64-pthreads-devel64-20100619-1.tar.bz2
w64-mingw64-pthreads-devel32-20100619-1.tar.bz2
w64-mingw64-pthreads-20100619-1-src.tar.bz2
w64-mingw64-pthreads-20100619-1-src.tar.bz2

--
Chuck


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