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
