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?