Re: [ITP] mingw-w64 (32-bit)
On 9/16/2010 9:38 AM, JonY wrote: I have uploaded the 32bit toolchain, I hope there are no thinkos when adapting the cygport files. All packages rebuild from source ok. Packaging looks good; I used them to build a working xz and liblzma with no trouble. genini is happy with the setup.hints (although the -header one pasted inline was incorrect, but the one on the sf site was good). All packages GTG, and uploaded. -- Chuck
Re: [ITP] mingw-w64 (32-bit)
On 9/17/2010 16:17, Charles Wilson wrote: On 9/16/2010 9:38 AM, JonY wrote: I have uploaded the 32bit toolchain, I hope there are no thinkos when adapting the cygport files. All packages rebuild from source ok. Packaging looks good; I used them to build a working xz and liblzma with no trouble. genini is happy with the setup.hints (although the -header one pasted inline was incorrect, but the one on the sf site was good). All packages GTG, and uploaded. -- Chuck Thanks.
Re: [ITP] mingw-w64 (32-bit)
On Sep 17 04:17, Charles Wilson wrote: On 9/16/2010 9:38 AM, JonY wrote: I have uploaded the 32bit toolchain, I hope there are no thinkos when adapting the cygport files. All packages rebuild from source ok. Packaging looks good; I used them to build a working xz and liblzma with no trouble. genini is happy with the setup.hints (although the -header one pasted inline was incorrect, but the one on the sf site was good). All packages GTG, and uploaded. cygwin-pkg-maint? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] mingw-w64 (32-bit)
On Sep 17 10:33, Charles Wilson wrote: On 9/17/2010 7:24 AM, Corinna Vinschen wrote: cygwin-pkg-maint? Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[ITP] mingw-w64 (32-bit)
Hi, I have uploaded the 32bit toolchain, I hope there are no thinkos when adapting the cygport files. mingw64-i686-binutils category: Devel requires: libgcc1 libintl8 zlib0 sdesc: Binutils for MinGW-w64 Win32 toolchain ldesc: Mingw-w64 Cross binutils for Win32 target. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-binutils/mingw64-i686-binutils-2.20.51-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-binutils/mingw64-i686-binutils-2.20.51-1-src.tar.bz2/download mingw64-i686-headers category: Devel requires: libgcc1 libintl8 zlib0 sdesc: Binutils for MinGW-w64 Win32 toolchain ldesc: Mingw-w64 Cross binutils for Win32 target. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/mingw64-i686-headers-1.0b_svn3433-1.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/mingw64-i686-headers-1.0b_svn3433-1-src.tar.bz2/download mingw64-i686-runtime category: Devel requires: mingw64-i686-headers sdesc: CRT libraries for Win32 target. ldesc: Mingw-w64 CRT libraries for Win32 target development. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-20100809-1.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-20100809-1-src.tar.bz2/download mingw64-i686-pthreads category: Devel requires: mingw64-i686-runtime sdesc: libpthread for MinGW-w64 Win32 toolchain ldesc: libpthread for MinGW-w64 Win32 toolchain https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-pthreads/mingw64-i686-pthreads-20100619-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-pthreads/mingw64-i686-pthreads-20100619-1.tar.bz2/download mingw64-i686-gcc category: Devel sdesc: GCC for MinGW-w64 Win32 toolchain (sources) ldesc: GCC for MinGW-w64 Win32 toolchain requires: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-gcc/mingw64-i686-gcc-4.5.1-1-src.tar.bz2/download mingw64-i686-gcc-objc category: Devel requires: mingw64-i686-gcc-core external-source: mingw64-i686-gcc sdesc: GCC objc and objc++ for MinGW-w64 Win32 toolchain ldesc: GCC objc and objc++ for MinGW-w64 Win32 toolchain https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-gcc/mingw64-i686-gcc-objc/mingw64-i686-gcc-objc-4.5.1-1.tar.bz2/download mingw64-i686-gcc-g++ category: Devel requires: mingw64-i686-gcc-core external-source: mingw64-i686-gcc sdesc: GCC g++ for MinGW-w64 Win32 toolchain ldesc: GCC g++ for MinGW-w64 Win32 toolchain https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-gcc/mingw64-i686-gcc-g%2B%2B/mingw64-i686-gcc-g%2B%2B-4.5.1-1.tar.bz2/download mingw64-i686-gcc-fortran category: Devel requires: mingw64-i686-gcc-core external-source: mingw64-i686-gcc sdesc: GCC gfortran for MinGW-w64 Win32 toolchain ldesc: GCC gfortran for MinGW-w64 Win32 toolchain https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-gcc/mingw64-i686-gcc-fortran/mingw64-i686-gcc-fortran-4.5.1-1.tar.bz2/download mingw64-i686-gcc-ada category: Devel requires: mingw64-i686-gcc-core external-source: mingw64-i686-gcc sdesc: GCC ada for MinGW-w64 Win32 toolchain ldesc: GCC ada for MinGW-w64 Win32 toolchain https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-gcc/mingw64-i686-gcc-ada/mingw64-i686-gcc-ada-4.5.1-1.tar.bz2/download mingw64-i686-gcc-core category: Devel requires: libcloog0 libgcc1 libgmp3 libiconv2 libintl8 libmpc1 libmpfr1 libppl mingw64-i686-binutils mingw64-i686-pthreads mingw64-i686-runtime external-source: mingw64-i686-gcc sdesc: GCC for MinGW-w64 Win32 toolchain ldesc: GCC for MinGW-w64 Win32 toolchain https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-gcc/mingw64-i686-gcc-core/setup.hint/download
Re: [ITP] mingw-w64 Second try
On Tue, Sep 14, 2010 at 05:58:08AM +0100, Andy Koppe wrote: On 13 September 2010 18:26, Charles Wilson wrote: On 9/13/2010 6:52 AM, JonY wrote: OK, new headers tarballs up. Thanks for keeping an eye out. All packages are uploaded. A big round of applause for JonY, Chuck, and Yaakov for the huge amount of work they've put into this. Hear, hear! cgf
Re: [ITP] mingw-w64 Second try
On 9/12/2010 10:24 PM, JonY wrote: On 9/13/2010 01:01, Charles Wilson wrote: On 9/11/2010 2:07 AM, JonY wrote: OK, new files are up, same links. Err...the pthread packages seem to be missing... Sorry about that, pthreads now uploaded. OK, all packages rebuild fine from souce. Also, now we have: a) the gcc packages are GTG b) the binutils package is GTG c) the runtime package is GTG d) the pthreads package is GTG but ... e) the headers setup.hint is missing a final on the ldesc. If you'd like to update that package, then we can go ahead and upload the whole lot... -- Chuck
Re: [ITP] mingw-w64 Second try
On 9/13/2010 6:52 AM, JonY wrote: OK, new headers tarballs up. Thanks for keeping an eye out. All packages are uploaded. Please wait 24 hours until they can propagate to the mirrors, then post announcements to cygwin-announce. Please look at the suggested templates here: http://cygwin.com/cgi-bin/cvsweb.cgi/htdocs/package-maint/templates/?cvsroot=cygwin for these messages. If I were you, I'd post six separate announcements: 1) An overall announcement for the mingw64-x86_64 cross toolchain and then, individual announcements for each of the major (e.g. separately versioned) components: 2) mingw64-x86_64-binutils 3) mingw64-x86_64-gcc 4) mingw64-x86_64-headers 5) mingw64-x86_64-runtime 6) mingw64-x86_64-pthreads Note that your messages should NOT have subject lines beginning with [ANNOUNCEMENT]; that will be added automatically. Oh, and one last thing: now that this is officially distributed by the cygwin mirrors, you need to be *very* careful about unique version/release numbers. Over all of these ITP iterations, you have continued to use the same ver/rel numbers for EVERY new update you've uploaded. That's ok -- but ONLY during the ITP process. From now on, every test release and iterative update placed on the cygwin mirrors *must* increment the release number each time; otherwise we'll never know WHICH 4.5.1-2 gcc package a bug-reporter was using. It'd be better, if that numbering guideline were ALSO obeyed for any cygwin test releases you upload to mingw64's sf site, too... In any case, for future updates all you need to do is make the new packages accessible and post an [RFU] message to cygwin-apps; there's no need for this long, drawn-out process anymore. If you want to release a given package as a 'test' release, just make a note of that in the [RFU] message, such as: Please upload this as a 'test' release, keeping 4.5.0-1 (or whatever) as 'current'. ...and one doesn't typically announce test releases on cygwin-announce; instead, send a message specifically to the cygwin list. Just watch what the other maintainers do on cygwin-apps... and thanks again for doing this! -- Chuck
Re: [ITP] mingw-w64 Second try
On Sep 13 13:26, Charles Wilson wrote: On 9/13/2010 6:52 AM, JonY wrote: OK, new headers tarballs up. Thanks for keeping an eye out. All packages are uploaded. Please wait 24 hours until they can propagate to the mirrors, then post announcements to cygwin-announce. Chuck, can you please update http://cygwin.com/cygwin-pkg-maint, too? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] mingw-w64 Second try
On 9/13/2010 2:16 PM, Corinna Vinschen wrote: Chuck, can you please update http://cygwin.com/cygwin-pkg-maint, too? Done.
Re: [ITP] mingw-w64 Second try
On 13 September 2010 18:26, Charles Wilson wrote: On 9/13/2010 6:52 AM, JonY wrote: OK, new headers tarballs up. Thanks for keeping an eye out. All packages are uploaded. A big round of applause for JonY, Chuck, and Yaakov for the huge amount of work they've put into this. Andy
Re: [ITP] mingw-w64 Second try
On 9/11/2010 2:07 AM, JonY wrote: OK, new files are up, same links. Err...the pthread packages seem to be missing... -- Chuck
Re: [ITP] mingw-w64 Second try
On 9/13/2010 01:01, Charles Wilson wrote: On 9/11/2010 2:07 AM, JonY wrote: OK, new files are up, same links. Err...the pthread packages seem to be missing... Sorry about that, pthreads now uploaded.
Re: [ITP] mingw-w64 Second try
On 9/10/2010 08:51, JonY wrote: On 9/10/2010 07:09, Charles Wilson wrote: On 9/9/2010 6:10 AM, JonY wrote: OK, we're amost there. binutils and runtime are GTG. gcc, headers, and pthreads are really close. Everything rebuilds from source fine, and the uploaded packages actually match the rebuilt versions (or vice versa). So that's all good. Plus, I was able to build a sample project using these tools (mingw64-x86_86-xz-4.999.9beta-1) with no problems. However, when I tried to install these packages via setup.exe, I ran into problems with the setup.hints. In the first case, genini (*) did not like some of them -- complained about missing fields -- AND, genini couldn't actually parse the package name of mingw64-x86_64-headers. (*) genini is a user script that can be used to generate a setup.ini for a cygwin package repository. On the sourceware server, a different tool -- upset -- is used. Now, maybe -- MAYBE -- upset is smarter than genini, and won't complain. However, it's usually better to make sure that genini is happy; then you are much more likely to NOT cause the upset script on sourceware to send cgf a bunch of nasty warnings via email. That makes cgf angry. You wouldn't like cgf when he's angry. Here are the bad setup.hints: mingw64-x86_64-gcc-core/setup.hint mingw64-x86_64-gcc-fortran/setup.hint mingw64-x86_64-gcc-g++/setup.hint mingw64-x86_64-gcc-objc/setup.hint mingw64-x86_64-gcc-ada/setup.hint mingw64-x86_64-gcc/setup.hint mingw64-x86_64-pthreads/setup.hint Plus there are bigger changes required to the -headers package. We'll talk about that last. In each of the following cases, the setup.hint was missing an ldesc: field. This annoys genini, but upset might be ok with it. mingw64-x86_64-gcc-core/setup.hint mingw64-x86_64-gcc-fortran/setup.hint mingw64-x86_64-gcc-g++/setup.hint mingw64-x86_64-gcc-objc/setup.hint mingw64-x86_64-gcc-ada/setup.hint mingw64-x86_64-pthreads/setup.hint The top gcc setup.hint was missing both an ldesc: and a requires: field (requires was empty, of course). mingw64-x86_64-gcc/setup.hint I've attached the updated setup.hints. Here's what I would suggest we do, for gcc: DON'T bother to rebuild it. Just save these setup.hints, and make sure to fold them in to your NEXT official release's CYGWIN-PATCHES/ directory. When I upload this first version of mingw64-gcc, I'll be sure to use these new hints instead of the ones you pasted inline. Let's call gcc GTG with alternate hint files. For pthreads, I'd suggest you actually rebuild and re-upload it with the attached hint (it doesn't take nearly as long...) but if you want to treat it just like gcc, above, that's fine. Let me know -- we'll call pthreads GTG with alternate hint files, or as rebuilt. Now...headers. Here's the problem: genini requires that the version part of the package name begin with a numeral. I think this is true of upset as well, but I'm not sure (but again, better safe than sorry. You wouldn't like cgf when he's angry). Also, genini and cygport do NOT like having a hyphen in the version number (but upset is ok with it). So, just liike your earlier gendef and libmangle packages -- where we discovered that they had to be named, e.g. gendef-1.0-svn2931-1.tar.bz2 gendef-1.0-svn2931-1-src.tar.bz2 libmangle-1.0-svn2930-1.tar.bz2 libmangle-1.0-svn2930-1-src.tar.bz2 ...the current name of the headers package is no good: mingw64-x86_64-headers-svn3433-1.tar.bz2 mingw64-x86_64-headers-svn3433-1-src.tar.bz2 ^^^ must start with numeral Now, following the gendef/libmangle pattern, I tried mingw64-x86_64-headers-1.0b-svn3433-1.tar.bz2 where 1.0b came from the configure.ac file, but I discovered that genini doesn't like the hyphen between 1.0b and svn3433 -- when you do that, genini (and cygport-0.10.0, for that matter) thinks the package name is mingw64-x86_64-headers-1.0b, and the version is svn3433, and we're right back where we started! Now, upset doesn't care about this -- obviously -- since gendef and libmangle, which use '-' between 1.0 and svn -- have not yet caused cgf to become angry. But...let's also try to keep genini happy. And, it may be a regression in cygport -- I'm not sure (obv. you were able to build gendef and libmangle with an older version of cygport, even with a hyphen in the middle of the version string), but we have to keep cygport happy, too. So, I rebuilt as: mingw64-x86_64-headers-1.0b_svn3433-1.tar.bz2 mingw64-x86_64-headers-1.0b_svn3433-1-src.tar.bz2 OK, this is fine. And that worked fine (genini was happy, cygport was happy, setup.exe was happy -- and presumably upset will be happy == no angry cgf). I've uploaded the modified version here: http://cygwin.cwilson.fastmail.fm/mingw64-x86_64-headers-1.0b_svn3433-1-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/mingw64-x86_64-headers-1.0b_svn3433-1.tar.bz2 so you can download it and pick it apart. The only thing that's different is (a) the package name, (b) the name of the
Re: [ITP] mingw-w64 Second try
On 9/2/2010 01:35, Charles Wilson wrote:
On 9/1/2010 11:44 AM, JonY wrote:
On 9/1/2010 23:15, Charles Wilson wrote:
On 8/31/2010 11:20 PM, JonY wrote:
On 9/1/2010 10:28, Charles Wilson wrote:
On 8/31/2010 8:52 PM, JonY wrote:
Strange, I'll try a rebuild. The former should be the correct
location.
Errr...no. The *latter* is the correct location (at least, that's where
the sysroot'ed compiler will look for them).
the (buggy) cygport(1) puts them in
usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/
but we really want them to be in
usr/x86_64-w64-mingw32/sys-root/mingw/include/
which is what your cygport(5) does -- when you actually use it to
rebuild.
Right, the latter is correct. I'm misreading it.
Given the results of the thread re: Possible cygport bug with cross
compiles (e.g. there is no bug), it looks like:
1) rebuild the -header package so that the includes end up in the
correct location. The current cygport(5) for that package is fine
(e.g. (a) the extra rule in src_install is needed, and proper, and (b)
it does the right thing)
I am getting a permission denied error that I wasn't aware of before. I
have fixed the mv command, and tested with cygport compile install
list, cyport list does show the correct locations. Tarball reuploaded.
2) fix the setup.hints
Does setup.hint itself (for mingw64-x86_64-gcc-core) need an
external-source link to mingw64-x86_64-gcc?
Well, you'd actually need two setup.hints:
mingw64-x86_64-gcc/
mingw64-x86_64-gcc-4.5.1-1-src.tar.bz2
(1) setup.hint
mingw64-x86_64-gcc-core/
mingw64-x86_64-gcc-core-4.5.1-1.tar.bz2
(2)setup.hint
mingw64-x86_64-gcc-fortran/
mingw64-x86_64-gcc-fortran-4.5.1-1.tar.bz2
setup.hint
mingw64-x86_64-gcc-g++/
mingw64-x86_64-gcc-g++-4.5.1-1.tar.bz2
setup.hint
mingw64-x86_64-gcc-ada/
mingw64-x86_64-gcc-ada-4.5.1-1.tar.bz2
setup.hint
The one marked (1) would not need any requires: or external-source:
marking. The one marked (2) would only need an external-source:
marking. The others would all need both an external-source AND a
requires: mingw64-x86_64-gcc-core marking.
I think this also means you need to modify your cygport(5) from
PKG_NAMES=${PN}-core ${PN}-ada ${PN}-g++ ${PN}-fortran ${PN}-objc
PKG_HINTS=setup ada g++ gfortran objc
to
PKG_NAMES=${PN} ${PN}-core ${PN}-ada ${PN}-g++ ${PN}-fortran ${PN}-objc
PKG_HINTS=setup core ada g++ gfortran objc
where the new core.hint file has the contents of the existing setup.hint
file (as updated above), and the new setup.hint file just says
category: Devel
sdesc: GCC for MinGW-w64 Win64 toolchain (source)
I *think* this means that you'll then get an EMPTY
mingw64-x86_64-gcc-4.5.1-1.tar.bz2
package, but you won't want to include that in the upload set.
--
Chuck
Hi,
sorry for the week long delay, the files have been sitting there for
quite some time (some were corrupt uploads, but I fixed them).
I kind of forgot about this thread.
mingw64-x86_64-headers
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1-src.tar.bz2/download
category: Devel
requires:
sdesc: Mingw-w64 headers for Win64 target.
ldesc: Mingw-w64 headers for Win64 target development.
This package is for the mingw-w64 toolchain that targets 64bit.
mingw64-x86_64-runtime
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1-src.tar.bz2/download
category: Devel
requires: mingw64-x86_64-headers
sdesc: CRT libraries for Win64 target.
ldesc: Mingw-w64 CRT libraries for Win64 target development.
mingw64-x86_64-binutils
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1-src.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1.tar.bz2/download
category: Devel
requires: libgcc1 libintl8 zlib0
sdesc: Binutils for MinGW-w64 Win64 toolchain
ldesc: Mingw-w64 Cross binutils for Win64 target.
mingw64-x86_64-pthreads
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1-src.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1.tar.bz2/download
category: Devel
requires: mingw64-x86_64-runtime
sdesc: libpthread for MinGW-w64 Win64 toolchain
mingw64-x86_64-gcc
Re: [ITP] mingw-w64 Second try
On 9/9/2010 6:10 AM, JonY wrote: OK, we're amost there. binutils and runtime are GTG. gcc, headers, and pthreads are really close. Everything rebuilds from source fine, and the uploaded packages actually match the rebuilt versions (or vice versa). So that's all good. Plus, I was able to build a sample project using these tools (mingw64-x86_86-xz-4.999.9beta-1) with no problems. However, when I tried to install these packages via setup.exe, I ran into problems with the setup.hints. In the first case, genini (*) did not like some of them -- complained about missing fields -- AND, genini couldn't actually parse the package name of mingw64-x86_64-headers. (*) genini is a user script that can be used to generate a setup.ini for a cygwin package repository. On the sourceware server, a different tool -- upset -- is used. Now, maybe -- MAYBE -- upset is smarter than genini, and won't complain. However, it's usually better to make sure that genini is happy; then you are much more likely to NOT cause the upset script on sourceware to send cgf a bunch of nasty warnings via email. That makes cgf angry. You wouldn't like cgf when he's angry. Here are the bad setup.hints: mingw64-x86_64-gcc-core/setup.hint mingw64-x86_64-gcc-fortran/setup.hint mingw64-x86_64-gcc-g++/setup.hint mingw64-x86_64-gcc-objc/setup.hint mingw64-x86_64-gcc-ada/setup.hint mingw64-x86_64-gcc/setup.hint mingw64-x86_64-pthreads/setup.hint Plus there are bigger changes required to the -headers package. We'll talk about that last. In each of the following cases, the setup.hint was missing an ldesc: field. This annoys genini, but upset might be ok with it. mingw64-x86_64-gcc-core/setup.hint mingw64-x86_64-gcc-fortran/setup.hint mingw64-x86_64-gcc-g++/setup.hint mingw64-x86_64-gcc-objc/setup.hint mingw64-x86_64-gcc-ada/setup.hint mingw64-x86_64-pthreads/setup.hint The top gcc setup.hint was missing both an ldesc: and a requires: field (requires was empty, of course). mingw64-x86_64-gcc/setup.hint I've attached the updated setup.hints. Here's what I would suggest we do, for gcc: DON'T bother to rebuild it. Just save these setup.hints, and make sure to fold them in to your NEXT official release's CYGWIN-PATCHES/ directory. When I upload this first version of mingw64-gcc, I'll be sure to use these new hints instead of the ones you pasted inline. Let's call gcc GTG with alternate hint files. For pthreads, I'd suggest you actually rebuild and re-upload it with the attached hint (it doesn't take nearly as long...) but if you want to treat it just like gcc, above, that's fine. Let me know -- we'll call pthreads GTG with alternate hint files, or as rebuilt. Now...headers. Here's the problem: genini requires that the version part of the package name begin with a numeral. I think this is true of upset as well, but I'm not sure (but again, better safe than sorry. You wouldn't like cgf when he's angry). Also, genini and cygport do NOT like having a hyphen in the version number (but upset is ok with it). So, just liike your earlier gendef and libmangle packages -- where we discovered that they had to be named, e.g. gendef-1.0-svn2931-1.tar.bz2 gendef-1.0-svn2931-1-src.tar.bz2 libmangle-1.0-svn2930-1.tar.bz2 libmangle-1.0-svn2930-1-src.tar.bz2 ...the current name of the headers package is no good: mingw64-x86_64-headers-svn3433-1.tar.bz2 mingw64-x86_64-headers-svn3433-1-src.tar.bz2 ^^^ must start with numeral Now, following the gendef/libmangle pattern, I tried mingw64-x86_64-headers-1.0b-svn3433-1.tar.bz2 where 1.0b came from the configure.ac file, but I discovered that genini doesn't like the hyphen between 1.0b and svn3433 -- when you do that, genini (and cygport-0.10.0, for that matter) thinks the package name is mingw64-x86_64-headers-1.0b, and the version is svn3433, and we're right back where we started! Now, upset doesn't care about this -- obviously -- since gendef and libmangle, which use '-' between 1.0 and svn -- have not yet caused cgf to become angry. But...let's also try to keep genini happy. And, it may be a regression in cygport -- I'm not sure (obv. you were able to build gendef and libmangle with an older version of cygport, even with a hyphen in the middle of the version string), but we have to keep cygport happy, too. So, I rebuilt as: mingw64-x86_64-headers-1.0b_svn3433-1.tar.bz2 mingw64-x86_64-headers-1.0b_svn3433-1-src.tar.bz2 And that worked fine (genini was happy, cygport was happy, setup.exe was happy -- and presumably upset will be happy == no angry cgf). I've uploaded the modified version here: http://cygwin.cwilson.fastmail.fm/mingw64-x86_64-headers-1.0b_svn3433-1-src.tar.bz2
Re: [ITP] mingw-w64 Second try
On 9/10/2010 07:09, Charles Wilson wrote: On 9/9/2010 6:10 AM, JonY wrote: OK, we're amost there. binutils and runtime are GTG. gcc, headers, and pthreads are really close. Everything rebuilds from source fine, and the uploaded packages actually match the rebuilt versions (or vice versa). So that's all good. Plus, I was able to build a sample project using these tools (mingw64-x86_86-xz-4.999.9beta-1) with no problems. However, when I tried to install these packages via setup.exe, I ran into problems with the setup.hints. In the first case, genini (*) did not like some of them -- complained about missing fields -- AND, genini couldn't actually parse the package name of mingw64-x86_64-headers. (*) genini is a user script that can be used to generate a setup.ini for a cygwin package repository. On the sourceware server, a different tool -- upset -- is used. Now, maybe -- MAYBE -- upset is smarter than genini, and won't complain. However, it's usually better to make sure that genini is happy; then you are much more likely to NOT cause the upset script on sourceware to send cgf a bunch of nasty warnings via email. That makes cgf angry. You wouldn't like cgf when he's angry. Here are the bad setup.hints: mingw64-x86_64-gcc-core/setup.hint mingw64-x86_64-gcc-fortran/setup.hint mingw64-x86_64-gcc-g++/setup.hint mingw64-x86_64-gcc-objc/setup.hint mingw64-x86_64-gcc-ada/setup.hint mingw64-x86_64-gcc/setup.hint mingw64-x86_64-pthreads/setup.hint Plus there are bigger changes required to the -headers package. We'll talk about that last. In each of the following cases, the setup.hint was missing an ldesc: field. This annoys genini, but upset might be ok with it. mingw64-x86_64-gcc-core/setup.hint mingw64-x86_64-gcc-fortran/setup.hint mingw64-x86_64-gcc-g++/setup.hint mingw64-x86_64-gcc-objc/setup.hint mingw64-x86_64-gcc-ada/setup.hint mingw64-x86_64-pthreads/setup.hint The top gcc setup.hint was missing both an ldesc: and a requires: field (requires was empty, of course). mingw64-x86_64-gcc/setup.hint I've attached the updated setup.hints. Here's what I would suggest we do, for gcc: DON'T bother to rebuild it. Just save these setup.hints, and make sure to fold them in to your NEXT official release's CYGWIN-PATCHES/ directory. When I upload this first version of mingw64-gcc, I'll be sure to use these new hints instead of the ones you pasted inline. Let's call gcc GTG with alternate hint files. For pthreads, I'd suggest you actually rebuild and re-upload it with the attached hint (it doesn't take nearly as long...) but if you want to treat it just like gcc, above, that's fine. Let me know -- we'll call pthreads GTG with alternate hint files, or as rebuilt. Now...headers. Here's the problem: genini requires that the version part of the package name begin with a numeral. I think this is true of upset as well, but I'm not sure (but again, better safe than sorry. You wouldn't like cgf when he's angry). Also, genini and cygport do NOT like having a hyphen in the version number (but upset is ok with it). So, just liike your earlier gendef and libmangle packages -- where we discovered that they had to be named, e.g. gendef-1.0-svn2931-1.tar.bz2 gendef-1.0-svn2931-1-src.tar.bz2 libmangle-1.0-svn2930-1.tar.bz2 libmangle-1.0-svn2930-1-src.tar.bz2 ...the current name of the headers package is no good: mingw64-x86_64-headers-svn3433-1.tar.bz2 mingw64-x86_64-headers-svn3433-1-src.tar.bz2 ^^^ must start with numeral Now, following the gendef/libmangle pattern, I tried mingw64-x86_64-headers-1.0b-svn3433-1.tar.bz2 where 1.0b came from the configure.ac file, but I discovered that genini doesn't like the hyphen between 1.0b and svn3433 -- when you do that, genini (and cygport-0.10.0, for that matter) thinks the package name is mingw64-x86_64-headers-1.0b, and the version is svn3433, and we're right back where we started! Now, upset doesn't care about this -- obviously -- since gendef and libmangle, which use '-' between 1.0 and svn -- have not yet caused cgf to become angry. But...let's also try to keep genini happy. And, it may be a regression in cygport -- I'm not sure (obv. you were able to build gendef and libmangle with an older version of cygport, even with a hyphen in the middle of the version string), but we have to keep cygport happy, too. So, I rebuilt as: mingw64-x86_64-headers-1.0b_svn3433-1.tar.bz2 mingw64-x86_64-headers-1.0b_svn3433-1-src.tar.bz2 OK, this is fine. And that worked fine (genini was happy, cygport was happy, setup.exe was happy -- and presumably upset will be happy == no angry cgf). I've uploaded the modified version here:
Re: [ITP] mingw-w64 Second try
On 8/31/2010 11:20 PM, JonY wrote: On 9/1/2010 10:28, Charles Wilson wrote: On 8/31/2010 8:52 PM, JonY wrote: Strange, I'll try a rebuild. The former should be the correct location. Errr...no. The *latter* is the correct location (at least, that's where the sysroot'ed compiler will look for them). the (buggy) cygport(1) puts them in usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/ but we really want them to be in usr/x86_64-w64-mingw32/sys-root/mingw/include/ which is what your cygport(5) does -- when you actually use it to rebuild. Right, the latter is correct. I'm misreading it. Given the results of the thread re: Possible cygport bug with cross compiles (e.g. there is no bug), it looks like: 1) rebuild the -header package so that the includes end up in the correct location. The current cygport(5) for that package is fine (e.g. (a) the extra rule in src_install is needed, and proper, and (b) it does the right thing) 2) fix the setup.hints and you're GTG! -- Chuck
Re: [ITP] mingw-w64 Second try
On 9/1/2010 23:15, Charles Wilson wrote: On 8/31/2010 11:20 PM, JonY wrote: On 9/1/2010 10:28, Charles Wilson wrote: On 8/31/2010 8:52 PM, JonY wrote: Strange, I'll try a rebuild. The former should be the correct location. Errr...no. The *latter* is the correct location (at least, that's where the sysroot'ed compiler will look for them). the (buggy) cygport(1) puts them in usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/ but we really want them to be in usr/x86_64-w64-mingw32/sys-root/mingw/include/ which is what your cygport(5) does -- when you actually use it to rebuild. Right, the latter is correct. I'm misreading it. Given the results of the thread re: Possible cygport bug with cross compiles (e.g. there is no bug), it looks like: 1) rebuild the -header package so that the includes end up in the correct location. The current cygport(5) for that package is fine (e.g. (a) the extra rule in src_install is needed, and proper, and (b) it does the right thing) I am getting a permission denied error that I wasn't aware of before. I have fixed the mv command, and tested with cygport compile install list, cyport list does show the correct locations. Tarball reuploaded. 2) fix the setup.hints Does setup.hint itself (for mingw64-x86_64-gcc-core) need an external-source link to mingw64-x86_64-gcc?
Re: [ITP] mingw-w64 Second try
On 9/1/2010 11:44 AM, JonY wrote:
On 9/1/2010 23:15, Charles Wilson wrote:
On 8/31/2010 11:20 PM, JonY wrote:
On 9/1/2010 10:28, Charles Wilson wrote:
On 8/31/2010 8:52 PM, JonY wrote:
Strange, I'll try a rebuild. The former should be the correct
location.
Errr...no. The *latter* is the correct location (at least, that's where
the sysroot'ed compiler will look for them).
the (buggy) cygport(1) puts them in
usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/
but we really want them to be in
usr/x86_64-w64-mingw32/sys-root/mingw/include/
which is what your cygport(5) does -- when you actually use it to
rebuild.
Right, the latter is correct. I'm misreading it.
Given the results of the thread re: Possible cygport bug with cross
compiles (e.g. there is no bug), it looks like:
1) rebuild the -header package so that the includes end up in the
correct location. The current cygport(5) for that package is fine
(e.g. (a) the extra rule in src_install is needed, and proper, and (b)
it does the right thing)
I am getting a permission denied error that I wasn't aware of before. I
have fixed the mv command, and tested with cygport compile install
list, cyport list does show the correct locations. Tarball reuploaded.
2) fix the setup.hints
Does setup.hint itself (for mingw64-x86_64-gcc-core) need an
external-source link to mingw64-x86_64-gcc?
Well, you'd actually need two setup.hints:
mingw64-x86_64-gcc/
mingw64-x86_64-gcc-4.5.1-1-src.tar.bz2
(1) setup.hint
mingw64-x86_64-gcc-core/
mingw64-x86_64-gcc-core-4.5.1-1.tar.bz2
(2)setup.hint
mingw64-x86_64-gcc-fortran/
mingw64-x86_64-gcc-fortran-4.5.1-1.tar.bz2
setup.hint
mingw64-x86_64-gcc-g++/
mingw64-x86_64-gcc-g++-4.5.1-1.tar.bz2
setup.hint
mingw64-x86_64-gcc-ada/
mingw64-x86_64-gcc-ada-4.5.1-1.tar.bz2
setup.hint
The one marked (1) would not need any requires: or external-source:
marking. The one marked (2) would only need an external-source:
marking. The others would all need both an external-source AND a
requires: mingw64-x86_64-gcc-core marking.
I think this also means you need to modify your cygport(5) from
PKG_NAMES=${PN}-core ${PN}-ada ${PN}-g++ ${PN}-fortran ${PN}-objc
PKG_HINTS=setup ada g++ gfortran objc
to
PKG_NAMES=${PN} ${PN}-core ${PN}-ada ${PN}-g++ ${PN}-fortran ${PN}-objc
PKG_HINTS=setup core ada g++ gfortran objc
where the new core.hint file has the contents of the existing setup.hint
file (as updated above), and the new setup.hint file just says
category: Devel
sdesc: GCC for MinGW-w64 Win64 toolchain (source)
I *think* this means that you'll then get an EMPTY
mingw64-x86_64-gcc-4.5.1-1.tar.bz2
package, but you won't want to include that in the upload set.
--
Chuck
Re: [ITP] mingw-w64 Second try
On 8/25/2010 12:19 AM, JonY wrote:
since cygport and gcc has been updated, I can do the packaging without
any local hacks.
Here are the packages.
Overall comments: I see you reverted to bundling the DLLs with the
compiler packages (e.g. no separate mingw64-x86_64-libfoo-* tarballs).
While it isn't the way I would do it, that's your choice as maintainer
(and Yaakov would agree with you, not me).
Many of the setup.hint's specify
requires: mingw64-x86_64-gcc
I *think* that should be
requires: mingw64-x86_64-gcc-core.
You don't actually HAVE a 'mingw64-x86_64-gcc' package, except for the
source-only one. And I'm sure you don't mean to require everybody to
install the source code...
mingw64-x86_64-pthreads
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1-src.tar.bz2/download
OK, and rebuilds fine from source.
mingw64-x86_64-headers
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1-src.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1.tar.bz2/download
Rebuilds fine from source (*), but the binary tarball above is not ok.
It has the headers in the following directory:
usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/
instead of
usr/x86_64-w64-mingw32/sys-root/mingw/include/
Now, if I *rebuild*, the binary tarball generated has the headers in the
correct spot; I think you just uploaded an old version.
mingw64-x86_64-runtime
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1-src.tar.bz2/download
OK, and rebuilds fine from source (*).
mingw64-x86_64-binutils
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1-src.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1.tar.bz2/download
OK, and rebuilds fine from source.
mingw64-x86_64-gcc-*
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-fortran/mingw64-x86_64-gcc-fortran-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-core/mingw64-x86_64-gcc-core-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-g%2B%2B/mingw64-x86_64-gcc-g%2B%2B-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-ada/mingw64-x86_64-gcc-ada-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-objc/mingw64-x86_64-gcc-objc-4.5.1-1.tar.bz2/download
OK, and (mostly) rebuilds fine from source. I had to comment out the Ada
parts. Even though I had gcc4-ada-4.3.4 installed, rebuilding your
package with Ada enabled failed. However, I've *never* tried to build
Ada before, so it may be that I'm missing some pre-requisite.
Or does building gcc-4.5.x Ada require a newer native Ada compiler than
4.3.4?
(*) I notice that both the -headers and -runtime cygport included this
line as the final command in src_install:
mv ${D}${CROSS_PREFIX}/${CROSS_HOST}/* ${D}${CROSS_PREFIX}
I see the same thing when I tried to use my old mingw*-zlib cygport; I
think the problem is in cygport(1), and your cygport(5) is just working
around the issue.
To sum up, assuming the Ada thing has a reasonable explanation, and the
setup.hints are fixed, I think this is GTG.
If you want to hold off and see what Yaakov does about the issue below,
and maybe revise your cygport(5)'s based on a new release of cygport(1),
that's up to you.
== POSSIBLE CYGPORT(1) BUG =
Yaakov?
the config.status for includedir has this:
S[includedir]=${prefix}/include
but other dirs are explicit:
S[bindir]=/usr/x86_64-w64-mingw32/sys-root/mingw/bin
Looking at the configure command (from config.status):
'/usr/src/mingw64/headers/mingw64-x86_64-headers-svn3433-1/src/mingw-w64-headers/configure'
'--srcdir=/usr/src/mingw64/headers/mingw64-x86_64-headers-svn3433-1/src/mingw-w64-headers'
'--prefix=/usr/x86_64-w64-mingw32/sys-root/mingw'
'--exec-prefix=/usr/x86_64-w64-mingw32/sys-root/mingw'
'--bindir=/usr/x86_64-w64-mingw32/sys-root/mingw/bin'
Re: [ITP] mingw-w64 Second try
On 9/1/2010 03:32, Charles Wilson wrote:
On 8/25/2010 12:19 AM, JonY wrote:
since cygport and gcc has been updated, I can do the packaging without
any local hacks.
Here are the packages.
Overall comments: I see you reverted to bundling the DLLs with the
compiler packages (e.g. no separate mingw64-x86_64-libfoo-* tarballs).
While it isn't the way I would do it, that's your choice as maintainer
(and Yaakov would agree with you, not me).
Many of the setup.hint's specify
requires: mingw64-x86_64-gcc
I *think* that should be
requires: mingw64-x86_64-gcc-core.
You don't actually HAVE a 'mingw64-x86_64-gcc' package, except for the
source-only one. And I'm sure you don't mean to require everybody to
install the source code...
Sorry, I was recycling setup.hint from earlier tries. I will fix this.
mingw64-x86_64-pthreads
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1-src.tar.bz2/download
OK, and rebuilds fine from source.
mingw64-x86_64-headers
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1-src.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1.tar.bz2/download
Rebuilds fine from source (*), but the binary tarball above is not ok.
It has the headers in the following directory:
usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/
instead of
usr/x86_64-w64-mingw32/sys-root/mingw/include/
Now, if I *rebuild*, the binary tarball generated has the headers in the
correct spot; I think you just uploaded an old version.
Strange, I'll try a rebuild. The former should be the correct location.
mingw64-x86_64-runtime
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1-src.tar.bz2/download
OK, and rebuilds fine from source (*).
mingw64-x86_64-binutils
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1-src.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1.tar.bz2/download
OK, and rebuilds fine from source.
mingw64-x86_64-gcc-*
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-fortran/mingw64-x86_64-gcc-fortran-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-core/mingw64-x86_64-gcc-core-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-g%2B%2B/mingw64-x86_64-gcc-g%2B%2B-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-ada/mingw64-x86_64-gcc-ada-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-objc/mingw64-x86_64-gcc-objc-4.5.1-1.tar.bz2/download
OK, and (mostly) rebuilds fine from source. I had to comment out the Ada
parts. Even though I had gcc4-ada-4.3.4 installed, rebuilding your
package with Ada enabled failed. However, I've *never* tried to build
Ada before, so it may be that I'm missing some pre-requisite.
Or does building gcc-4.5.x Ada require a newer native Ada compiler than
4.3.4?
I installed gcc 4.5.x from experimental for this purpose. The GCC docs
say to have a native ada compiler of the same version installed first.
GCC 4.5.0 and 4.5.1 should be close enough.
(*) I notice that both the -headers and -runtime cygport included this
line as the final command in src_install:
mv ${D}${CROSS_PREFIX}/${CROSS_HOST}/* ${D}${CROSS_PREFIX}
I see the same thing when I tried to use my old mingw*-zlib cygport; I
think the problem is in cygport(1), and your cygport(5) is just working
around the issue.
To sum up, assuming the Ada thing has a reasonable explanation, and the
setup.hints are fixed, I think this is GTG.
If you want to hold off and see what Yaakov does about the issue below,
and maybe revise your cygport(5)'s based on a new release of cygport(1),
that's up to you.
OK, my cygport was mostly from Yaakov's examples.
== POSSIBLE CYGPORT(1) BUG =
Yaakov?
the config.status for includedir has this:
S[includedir]=${prefix}/include
but other dirs are explicit:
S[bindir]=/usr/x86_64-w64-mingw32/sys-root/mingw/bin
Looking at the
Re: [ITP] mingw-w64 Second try
On 8/31/2010 8:52 PM, JonY wrote: On 9/1/2010 03:32, Charles Wilson wrote: Rebuilds fine from source (*), but the binary tarball above is not ok. It has the headers in the following directory: usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/ instead of usr/x86_64-w64-mingw32/sys-root/mingw/include/ Now, if I *rebuild*, the binary tarball generated has the headers in the correct spot; I think you just uploaded an old version. Strange, I'll try a rebuild. The former should be the correct location. Errr...no. The *latter* is the correct location (at least, that's where the sysroot'ed compiler will look for them). the (buggy) cygport(1) puts them in usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/ but we really want them to be in usr/x86_64-w64-mingw32/sys-root/mingw/include/ which is what your cygport(5) does -- when you actually use it to rebuild. Or does building gcc-4.5.x Ada require a newer native Ada compiler than 4.3.4? I installed gcc 4.5.x from experimental for this purpose. The GCC docs say to have a native ada compiler of the same version installed first. GCC 4.5.0 and 4.5.1 should be close enough. Oh, I did not know that; I figured any old Ada would do. OK... To sum up, assuming the Ada thing has a reasonable explanation, and the setup.hints are fixed, I think this is GTG. If you want to hold off and see what Yaakov does about the issue below, and maybe revise your cygport(5)'s based on a new release of cygport(1), that's up to you. OK, my cygport was mostly from Yaakov's examples. Thanks for your hard work. -- Chuck
Re: [ITP] mingw-w64 Second try
On 9/1/2010 10:28, Charles Wilson wrote: On 8/31/2010 8:52 PM, JonY wrote: On 9/1/2010 03:32, Charles Wilson wrote: Rebuilds fine from source (*), but the binary tarball above is not ok. It has the headers in the following directory: usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/ instead of usr/x86_64-w64-mingw32/sys-root/mingw/include/ Now, if I *rebuild*, the binary tarball generated has the headers in the correct spot; I think you just uploaded an old version. Strange, I'll try a rebuild. The former should be the correct location. Errr...no. The *latter* is the correct location (at least, that's where the sysroot'ed compiler will look for them). the (buggy) cygport(1) puts them in usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/ but we really want them to be in usr/x86_64-w64-mingw32/sys-root/mingw/include/ which is what your cygport(5) does -- when you actually use it to rebuild. Right, the latter is correct. I'm misreading it.
Re: [ITP] mingw-w64 Second try
On 8/25/2010 8:14 PM, JonY wrote: On 8/25/2010 12:19, JonY wrote: since cygport and gcc has been updated, I can do the packaging without any local hacks. Ping. Less than a single day is a bit quick to ping. I'll take a look at this tonight or tomorrow; thanks for your hard work. -- Chuck
Re: [ITP] mingw-w64 Second try
On 8/26/2010 22:21, Charles Wilson wrote: On 8/25/2010 8:14 PM, JonY wrote: On 8/25/2010 12:19, JonY wrote: since cygport and gcc has been updated, I can do the packaging without any local hacks. Ping. Less than a single day is a bit quick to ping. I'll take a look at this tonight or tomorrow; thanks for your hard work. Sorry, no rush intended. I'm having a bit of a long day here and might have gotten confused about when the itp was sent.
Re: [ITP] mingw-w64 Second try
On 8/25/2010 12:19, JonY wrote: Hi, since cygport and gcc has been updated, I can do the packaging without any local hacks. Here are the packages. mingw64-x86_64-pthreads https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1-src.tar.bz2/download category: Devel requires: mingw64-x86_64-runtime sdesc: libpthread for MinGW-w64 Win64 toolchain mingw64-x86_64-headers https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1.tar.bz2/download category: Devel requires: sdesc: Mingw-w64 headers for Win64 target. ldesc: Mingw-w64 headers for Win64 target development. This package is for the mingw-w64 toolchain that targets 64bit. mingw64-x86_64-runtime https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1-src.tar.bz2/download category: Devel requires: mingw64-x86_64-headers sdesc: CRT libraries for Win64 target. ldesc: Mingw-w64 CRT libraries for Win64 target development. mingw64-x86_64-binutils https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1.tar.bz2/download category: Devel requires: libgcc1 libintl8 zlib0 sdesc: Binutils for MinGW-w64 Win64 toolchain ldesc: Mingw-w64 Cross binutils for Win64 target. mingw64-x86_64-gcc-fortran https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-fortran/mingw64-x86_64-gcc-fortran-4.5.1-1.tar.bz2/download category: Devel requires: mingw64-x86_64-gcc external-source: mingw64-x86_64-gcc sdesc: GCC gfortran for MinGW-w64 Win64 toolchain mingw64-x86_64-gcc-core https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-core/mingw64-x86_64-gcc-core-4.5.1-1.tar.bz2/download category: Devel requires: libcloog0 libgcc1 libgmp3 libiconv2 libintl8 libmpc1 libmpfr1 libppl mingw64-x86_64-binutils mingw64-x86_64-pthreads mingw64-x86_64-runtime sdesc: GCC for MinGW-w64 Win64 toolchain mingw64-x86_64-gcc-g++ https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-g%2B%2B/mingw64-x86_64-gcc-g%2B%2B-4.5.1-1.tar.bz2/download ategory: Devel requires: mingw64-x86_64-gcc external-source: mingw64-x86_64-gcc mingw64-x86_64-gcc-ada https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-ada/mingw64-x86_64-gcc-ada-4.5.1-1.tar.bz2/download category: Devel requires: mingw64-x86_64-gcc external-source: mingw64-x86_64-gcc sdesc: GCC ada for MinGW-w64 Win64 toolchain mingw64-x86_64-gcc-objc https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-objc/mingw64-x86_64-gcc-objc-4.5.1-1.tar.bz2/download category: Devel requires: mingw64-x86_64-gcc external-source: mingw64-x86_64-gcc sdesc: GCC objc and objc++ for MinGW-w64 Win64 toolchain mingw64-x86_64-gcc https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-4.5.1-1-src.tar.bz2/download Ping.
[ITP] mingw-w64 Second try
Hi, since cygport and gcc has been updated, I can do the packaging without any local hacks. Here are the packages. mingw64-x86_64-pthreads https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1-src.tar.bz2/download category: Devel requires: mingw64-x86_64-runtime sdesc: libpthread for MinGW-w64 Win64 toolchain mingw64-x86_64-headers https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1.tar.bz2/download category: Devel requires: sdesc: Mingw-w64 headers for Win64 target. ldesc: Mingw-w64 headers for Win64 target development. This package is for the mingw-w64 toolchain that targets 64bit. mingw64-x86_64-runtime https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1-src.tar.bz2/download category: Devel requires: mingw64-x86_64-headers sdesc: CRT libraries for Win64 target. ldesc: Mingw-w64 CRT libraries for Win64 target development. mingw64-x86_64-binutils https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1.tar.bz2/download category: Devel requires: libgcc1 libintl8 zlib0 sdesc: Binutils for MinGW-w64 Win64 toolchain ldesc: Mingw-w64 Cross binutils for Win64 target. mingw64-x86_64-gcc-fortran https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-fortran/mingw64-x86_64-gcc-fortran-4.5.1-1.tar.bz2/download category: Devel requires: mingw64-x86_64-gcc external-source: mingw64-x86_64-gcc sdesc: GCC gfortran for MinGW-w64 Win64 toolchain mingw64-x86_64-gcc-core https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-core/mingw64-x86_64-gcc-core-4.5.1-1.tar.bz2/download category: Devel requires: libcloog0 libgcc1 libgmp3 libiconv2 libintl8 libmpc1 libmpfr1 libppl mingw64-x86_64-binutils mingw64-x86_64-pthreads mingw64-x86_64-runtime sdesc: GCC for MinGW-w64 Win64 toolchain mingw64-x86_64-gcc-g++ https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-g%2B%2B/mingw64-x86_64-gcc-g%2B%2B-4.5.1-1.tar.bz2/download ategory: Devel requires: mingw64-x86_64-gcc external-source: mingw64-x86_64-gcc mingw64-x86_64-gcc-ada https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-ada/mingw64-x86_64-gcc-ada-4.5.1-1.tar.bz2/download category: Devel requires: mingw64-x86_64-gcc external-source: mingw64-x86_64-gcc sdesc: GCC ada for MinGW-w64 Win64 toolchain mingw64-x86_64-gcc-objc https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-objc/mingw64-x86_64-gcc-objc-4.5.1-1.tar.bz2/download category: Devel requires: mingw64-x86_64-gcc external-source: mingw64-x86_64-gcc sdesc: GCC objc and objc++ for MinGW-w64 Win64 toolchain mingw64-x86_64-gcc https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-4.5.1-1-src.tar.bz2/download
Re: [ITP] mingw-w64
On 05/07/2010 18:38, Charles Wilson wrote: However, the DLLs don't appear to be in the correct locations. opt/mingw64/bin/libobjc-2.dll opt/mingw64/bin32/libgcc_s_sjlj-1.dll opt/mingw64/bin64/libgcc_s_sjlj-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libgfortran-3.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libgomp-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libssp-0.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libstdc++-6.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libgfortran-3.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libgomp-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libssp-0.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libstdc++-6.dll Now, the DLLs buried down in the 4.6.0/ directory I can see (it appears to be a mistake, but that IS where they normally go...even if we choose to put them in toplevel bin32 and bin64 dirs instead.) It looks like the cygport is missing some 'mv' commands. Should be handled by passing -bindir=$bindir to libtool rather than mv'ing them after make install. But how the heck did libobjc-2.dll get into the regular bin/ dir? And why is there only one version of it? I forgot about libobjc when adding -bindir support to GCC(*, didn't make it in time for 4.5 branch. Guess I should see about backporting that for 4.5.1. cheers, DaveK -- (*) - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30445#c3
Re: [ITP] mingw-w64
On 06/07/2010 16:59, JonY wrote:
On 7/6/2010 23:36, Charles Wilson wrote:
I found the problem: configure.ac is patched, but there's no mechanism
to ensure that the corresponding change to configure is included in the
patch (by default, cygport *assumes* you will run autoreconf, and so
explicitly excludes configure, Makefile.in (for automake projects), etc
from the diff.)
Now, in this case you do NOT want to run autoreconf. The gcc codebase
requires careful handling if you want to update the auto* generated
files; autoreconf is not smart enough.
I haven't really checked, but I think that may no longer be true since the
upgrade to 2.64/1.11.1.
I did this too with the libstdc++-v3, libgomp and etc, but only
libobjc-2 is having trouble?
So, there are a couple of ways around this. All are pretty ugly.
Perhaps the simplest is an extra command in src_build:
(cd ${S}/libobjc autoconf)
to just force the end user to fixup THAT configure script only,
without mucking with any other auto* generated files.
If you look at the distro gcc4 cygport, you'll see it carefully does just
the necessary amount of autoconfing and automakeing. (But that may no longer
be necessary, as I mentioned above.)
Another option (one that I've had to use on occasion) is to give up on
letting cygport handle the patch generation for .src.patch. What you do,
is you just don't HAVE a .src.patch. Instead, you make your OWN patch,
ensure it contains all the files you want to include, like
libobjc/configure, and name that patch ANYTHING but ${P}.src.patch.
Then, add this to your cygport:
PATCH_URI=the-name-of-my-custom-patch
I'm switching to this approach for gcc-4.5.0-1, anyway.
cheers,
DaveK
Re: [ITP] mingw-w64
On 7/6/2010 1:10 AM, JonY wrote:
I had a thinko, thanks for the patch. Yeah, cygport moves the libtool
dlls around.
I will recheck on the README file and libobjc-2, I thought I patched up
the configure file.
You did, but...
Alright, I repackaged binutils to add the /etc/profile.d scripts
I'll look at mingw64-binutils again later. But right now I'm looking
only at mingw64-gcc:
and
repackaged gcc to get rid of the wrongly installed objc dll.
With the new libtool restrict, no more moving needed. I can also confirm
that libobjc-2.dll goes into bin32 and bin64 on cygport install.
I found the problem: configure.ac is patched, but there's no mechanism
to ensure that the corresponding change to configure is included in the
patch (by default, cygport *assumes* you will run autoreconf, and so
explicitly excludes configure, Makefile.in (for automake projects), etc
from the diff.)
Now, in this case you do NOT want to run autoreconf. The gcc codebase
requires careful handling if you want to update the auto* generated
files; autoreconf is not smart enough.
So, there are a couple of ways around this. All are pretty ugly.
Perhaps the simplest is an extra command in src_build:
(cd ${S}/libobjc autoconf)
to just force the end user to fixup THAT configure script only,
without mucking with any other auto* generated files.
Another option (one that I've had to use on occasion) is to give up on
letting cygport handle the patch generation for .src.patch. What you
do, is you just don't HAVE a .src.patch. Instead, you make your OWN
patch, ensure it contains all the files you want to include, like
libobjc/configure, and name that patch ANYTHING but ${P}.src.patch.
Then, add this to your cygport:
PATCH_URI=the-name-of-my-custom-patch
But...this cygportism has bugged me for a while. So, I tried to create
a generic facility where you could, for instance, do:
DIFF_NO_EXCLUDES=configure Makefile.in *.m4
and then cygport would ensure that, even if it ordinarily would exclude
a file from the diff, if that file name (or pattern) appears in
$DIFF_NO_EXCLUDES then it would avoid doing so. But that got to be
really hard, what with all the word expansion and shell metacharacter
worries. (Plus, it would have slowed down ALL cygports in a pretty big
way during __pkg_diff, for the benefit of only a few.)
So, instead, I whipped up a different patch to cygport which only tells
cygport to avoid automatically adding the autoconf, automake, and
aclocal-generated files to the diff excludes list. To use it, add this
to your cygport:
RESTRICT+= autoreconf-diff-excludes
However, before you modify your .cygport recipe to rely on un-official
cygport patches, let's make sure Yaakov actually accepts the patch. (I
know from long painful experience that you do NOT want to get ahead of
Yaakov's patch-acceptance process).
Given all that, this remaining issue where libobjc/configure is not kept
in sync with libobjc/configure.ac is the only remaining problem with
rebuilding the mingw64-gcc packages. With that corrected, it rebuilds
fine from source.
--
Chuck
Re: [ITP] mingw-w64
On 7/6/2010 23:36, Charles Wilson wrote:
On 7/6/2010 1:10 AM, JonY wrote:
I had a thinko, thanks for the patch. Yeah, cygport moves the libtool
dlls around.
I will recheck on the README file and libobjc-2, I thought I patched up
the configure file.
You did, but...
Alright, I repackaged binutils to add the /etc/profile.d scripts
I'll look at mingw64-binutils again later. But right now I'm looking
only at mingw64-gcc:
and
repackaged gcc to get rid of the wrongly installed objc dll.
With the new libtool restrict, no more moving needed. I can also confirm
that libobjc-2.dll goes into bin32 and bin64 on cygport install.
I found the problem: configure.ac is patched, but there's no mechanism
to ensure that the corresponding change to configure is included in the
patch (by default, cygport *assumes* you will run autoreconf, and so
explicitly excludes configure, Makefile.in (for automake projects), etc
from the diff.)
Now, in this case you do NOT want to run autoreconf. The gcc codebase
requires careful handling if you want to update the auto* generated
files; autoreconf is not smart enough.
I did this too with the libstdc++-v3, libgomp and etc, but only
libobjc-2 is having trouble?
So, there are a couple of ways around this. All are pretty ugly.
Perhaps the simplest is an extra command in src_build:
(cd ${S}/libobjc autoconf)
to just force the end user to fixup THAT configure script only,
without mucking with any other auto* generated files.
Right now, libtool version difference prevents that from going smoothly.
Another option (one that I've had to use on occasion) is to give up on
letting cygport handle the patch generation for .src.patch. What you do,
is you just don't HAVE a .src.patch. Instead, you make your OWN patch,
ensure it contains all the files you want to include, like
libobjc/configure, and name that patch ANYTHING but ${P}.src.patch.
Then, add this to your cygport:
PATCH_URI=the-name-of-my-custom-patch
Just use diff -ur origsrc src right? I have not actually edited any
files other than the autotool stuff.
But...this cygportism has bugged me for a while. So, I tried to create a
generic facility where you could, for instance, do:
DIFF_NO_EXCLUDES=configure Makefile.in *.m4
and then cygport would ensure that, even if it ordinarily would exclude
a file from the diff, if that file name (or pattern) appears in
$DIFF_NO_EXCLUDES then it would avoid doing so. But that got to be
really hard, what with all the word expansion and shell metacharacter
worries. (Plus, it would have slowed down ALL cygports in a pretty big
way during __pkg_diff, for the benefit of only a few.)
So, instead, I whipped up a different patch to cygport which only tells
cygport to avoid automatically adding the autoconf, automake, and
aclocal-generated files to the diff excludes list. To use it, add this
to your cygport:
RESTRICT+= autoreconf-diff-excludes
However, before you modify your .cygport recipe to rely on un-official
cygport patches, let's make sure Yaakov actually accepts the patch. (I
know from long painful experience that you do NOT want to get ahead of
Yaakov's patch-acceptance process).
I can see his hesitation about accepting the .cygport file, it won't
build cleanly on another machine unless its patched too.
Given all that, this remaining issue where libobjc/configure is not kept
in sync with libobjc/configure.ac is the only remaining problem with
rebuilding the mingw64-gcc packages. With that corrected, it rebuilds
fine from source.
Alright, thanks for the review, I'll get a new upload as soon as possible.
Re: [ITP] mingw-w64
On 7/6/2010 11:59 AM, JonY wrote:
On 7/6/2010 23:36, Charles Wilson wrote:
Now, in this case you do NOT want to run autoreconf. The gcc codebase
requires careful handling if you want to update the auto* generated
files; autoreconf is not smart enough.
I did this too with the libstdc++-v3, libgomp and etc, but only
libobjc-2 is having trouble?
Correct. The reason is because the relevant changes are in Makefile.am
and Makefile.in (or configure.host) for those other libraries. For
libobjc, the change is in configure.ac/configure.
What's even trickier, is that cygport's heuristic for determining
whether to exclude Makefile.in relies on the design of the *top*
directory of the source. For a number of odd reasons, the top level gcc
directory doesn't cause the exclude Makefile.in logic to fire -- but
it DOES cause the exclude configure logic to fire.
So, you end up with the patches to Makefile.am and libobjc/configure.ac
(and configure.host) as expected. You ALSO end up with the Makefile.in
patches (because the exclude Makefile.in logic in cygport did not
fire), but you miss the libobjc/configure change because the exclude
configure logic DID fire.
Perhaps the simplest is an extra command in src_build:
(cd ${S}/libobjc autoconf)
to just force the end user to fixup THAT configure script only,
without mucking with any other auto* generated files.
Right now, libtool version difference prevents that from going smoothly.
Err...I didn't have any problems running *autoconf* in that directory (I
did NOT run autoREconf). But I didn't think this was the best option
anyway...
Another option (one that I've had to use on occasion) is to give up on
letting cygport handle the patch generation for .src.patch. What you do,
is you just don't HAVE a .src.patch. Instead, you make your OWN patch,
ensure it contains all the files you want to include, like
libobjc/configure, and name that patch ANYTHING but ${P}.src.patch.
Then, add this to your cygport:
PATCH_URI=the-name-of-my-custom-patch
Just use diff -ur origsrc src right? I have not actually edited any
files other than the autotool stuff.
Yes (*) -- but not without manually editing the result, because you'd be
quite likely to pick up a lot of cruft that you don't want. That's why
cygport goes to such trouble to build an exclude list.
However, when I use this option...that's exactly what I do:
diff -urN origsrc src foo.patch
and then edit foo.patch to remove those bits I *know* should not be
included.
(*) If you know you added some files to src/*, then also use -N. Also,
for the .src.patch replacement, you'll want to use -x CYGWIN-PATCHES.
However, before you modify your .cygport recipe to rely on un-official
cygport patches, let's make sure Yaakov actually accepts the patch. (I
know from long painful experience that you do NOT want to get ahead of
Yaakov's patch-acceptance process).
I can see his hesitation about accepting the .cygport file, it won't
build cleanly on another machine unless its patched too.
Well, let's be clear: it's not Yaakov that accepts your package .cygport
file. He is in charge of the cygport tool, nothing more (well,
actually, a WHOLE GIANT PILE more of additional packages, but that's not
relevant here).
In the VAST majority of cases, we'd prefer that any package in the
distro that purports to use 'cygport' to build, actually uses THE
official cygport. But there have been exceptions in the past; these
exceptions caused a lot of extra list traffic and pain for the provider
(me!) of the package whose cygport required the modified tool.
So...there will be pain; I advise you to avoid that pain; but...I
*think* you can do it (rely on a custom cygport tool with minor
modifications) if you really think it is necessary. Final decision on
that rests with the consensus of other package maintainers on this
list...not JUST Yaakov (and not just me, either).
Given all that, this remaining issue where libobjc/configure is not kept
in sync with libobjc/configure.ac is the only remaining problem with
rebuilding the mingw64-gcc packages. With that corrected, it rebuilds
fine from source.
Alright, thanks for the review, I'll get a new upload as soon as possible.
No, no...please slow down. You're doing a lot of extra work and
honestly, I can't keep up. Let's bundle changes an only update the
cygwin packages on sf.org when it makes sense to do so. That would save
you a lot of extra unnecessary work, I think.
I think right now, we're waiting on a verdict -- or alternate suggestion
-- from Yaakov about what patches he will accept in (a soon to be
released version of) cygport, the tool.
--
Chuck
Re: [ITP] mingw-w64
On 7/7/2010 04:26, Charles Wilson wrote:
On 7/6/2010 11:59 AM, JonY wrote:
On 7/6/2010 23:36, Charles Wilson wrote:
Now, in this case you do NOT want to run autoreconf. The gcc codebase
requires careful handling if you want to update the auto* generated
files; autoreconf is not smart enough.
I did this too with the libstdc++-v3, libgomp and etc, but only
libobjc-2 is having trouble?
Correct. The reason is because the relevant changes are in Makefile.am
and Makefile.in (or configure.host) for those other libraries. For
libobjc, the change is in configure.ac/configure.
What's even trickier, is that cygport's heuristic for determining
whether to exclude Makefile.in relies on the design of the *top*
directory of the source. For a number of odd reasons, the top level gcc
directory doesn't cause the exclude Makefile.in logic to fire -- but
it DOES cause the exclude configure logic to fire.
So, you end up with the patches to Makefile.am and libobjc/configure.ac
(and configure.host) as expected. You ALSO end up with the Makefile.in
patches (because the exclude Makefile.in logic in cygport did not
fire), but you miss the libobjc/configure change because the exclude
configure logic DID fire.
Perhaps the simplest is an extra command in src_build:
(cd ${S}/libobjc autoconf)
to just force the end user to fixup THAT configure script only,
without mucking with any other auto* generated files.
Right now, libtool version difference prevents that from going smoothly.
Err...I didn't have any problems running *autoconf* in that directory (I
did NOT run autoREconf). But I didn't think this was the best option
anyway...
Another option (one that I've had to use on occasion) is to give up on
letting cygport handle the patch generation for .src.patch. What you do,
is you just don't HAVE a .src.patch. Instead, you make your OWN patch,
ensure it contains all the files you want to include, like
libobjc/configure, and name that patch ANYTHING but ${P}.src.patch.
Then, add this to your cygport:
PATCH_URI=the-name-of-my-custom-patch
Just use diff -ur origsrc src right? I have not actually edited any
files other than the autotool stuff.
Yes (*) -- but not without manually editing the result, because you'd be
quite likely to pick up a lot of cruft that you don't want. That's why
cygport goes to such trouble to build an exclude list.
However, when I use this option...that's exactly what I do:
diff -urN origsrc src foo.patch
and then edit foo.patch to remove those bits I *know* should not be
included.
(*) If you know you added some files to src/*, then also use -N. Also,
for the .src.patch replacement, you'll want to use -x CYGWIN-PATCHES.
However, before you modify your .cygport recipe to rely on un-official
cygport patches, let's make sure Yaakov actually accepts the patch. (I
know from long painful experience that you do NOT want to get ahead of
Yaakov's patch-acceptance process).
I can see his hesitation about accepting the .cygport file, it won't
build cleanly on another machine unless its patched too.
Well, let's be clear: it's not Yaakov that accepts your package .cygport
file. He is in charge of the cygport tool, nothing more (well, actually,
a WHOLE GIANT PILE more of additional packages, but that's not relevant
here).
In the VAST majority of cases, we'd prefer that any package in the
distro that purports to use 'cygport' to build, actually uses THE
official cygport. But there have been exceptions in the past; these
exceptions caused a lot of extra list traffic and pain for the provider
(me!) of the package whose cygport required the modified tool.
So...there will be pain; I advise you to avoid that pain; but...I
*think* you can do it (rely on a custom cygport tool with minor
modifications) if you really think it is necessary. Final decision on
that rests with the consensus of other package maintainers on this
list...not JUST Yaakov (and not just me, either).
Given all that, this remaining issue where libobjc/configure is not kept
in sync with libobjc/configure.ac is the only remaining problem with
rebuilding the mingw64-gcc packages. With that corrected, it rebuilds
fine from source.
Alright, thanks for the review, I'll get a new upload as soon as
possible.
No, no...please slow down. You're doing a lot of extra work and
honestly, I can't keep up. Let's bundle changes an only update the
cygwin packages on sf.org when it makes sense to do so. That would save
you a lot of extra unnecessary work, I think.
I think right now, we're waiting on a verdict -- or alternate suggestion
-- from Yaakov about what patches he will accept in (a soon to be
released version of) cygport, the tool.
OK, I've updated the cygport in the mingw64-tc64-gcc4 source file, no
changes to the other files. I've added the cd ${S}/libojc autoconf calls.
I'll be away for about a week, so do take your time to review too.
Yaakov can also give his opinions.
Re: [ITP] mingw-w64
On 7/2/2010 2:36 AM, JonY wrote:
Here are the GCC links. I hope I got them all.
mingw64-m32-libgcc1-4.6.20100619-1.tar.bz2
mingw64-m32-libgfortran3-4.6.20100619-1.tar.bz2
mingw64-m32-libgomp1-4.6.20100619-1.tar.bz2
mingw64-m32-libobjc2-4.6.20100619-1.tar.bz2
mingw64-m32-libssp0-4.6.20100619-1.tar.bz2
mingw64-m32-libstdc++6-4.6.20100619-1.tar.bz2
mingw64-m64-libgcc1-4.6.20100619-1.tar.bz2
mingw64-m64-libgfortran3-4.6.20100619-1.tar.bz2
mingw64-m64-libgomp1-4.6.20100619-1.tar.bz2
mingw64-m64-libobjc2-4.6.20100619-1.tar.bz2
mingw64-m64-libssp0-4.6.20100619-1.tar.bz2
mingw64-m64-libstdc++6-4.6.20100619-1.tar.bz2
mingw64-tc64-gcc4-4.6.20100619-1.tar.bz2
mingw64-tc64-gcc4-4.6.20100619-1-src.tar.bz2
mingw64-tc64-gcc4-g++-4.6.20100619-1.tar.bz2
mingw64-tc64-gcc4-objc-4.6.20100619-1.tar.bz2
mingw64-tc64-m32-libgfortran3-devel-4.6.20100619-1.tar.bz2
mingw64-tc64-m32-libgomp1-devel-4.6.20100619-1.tar.bz2
mingw64-tc64-m32-libobjc2-devel-4.6.20100619-1.tar.bz2
mingw64-tc64-m32-libssp0-devel-4.6.20100619-1.tar.bz2
mingw64-tc64-m32-libstdc++6-devel-4.6.20100619-1.tar.bz2
mingw64-tc64-m64-libgfortran3-devel-4.6.20100619-1.tar.bz2
mingw64-tc64-m64-libgomp1-devel-4.6.20100619-1.tar.bz2
mingw64-tc64-m64-libobjc2-devel-4.6.20100619-1.tar.bz2
mingw64-tc64-m64-libssp0-devel-4.6.20100619-1.tar.bz2
mingw64-tc64-m64-libstdc++6-devel-4.6.20100619-1.tar.bz2
Packaging looks good, but I haven't reviewed the setup.hints yet.
Rebuiling from -src: well, I ran into a problem.
cygport ... prep: ok
cygport ... build: ok
cygport ... install: errors in postinstall:
cp: cannot stat
`/usr/src/devel/mingw64/gcc/r/mingw64-tc64-gcc4-4.6.20100619-1/inst/opt/mingw64/lib/gcc/x86_64-w64-mingw32/lib/libgcc_s.a':
No such file or directory
cp: cannot stat
`/usr/src/devel/mingw64/gcc/r/mingw64-tc64-gcc4-4.6.20100619-1/inst/opt/mingw64/lib/gcc/x86_64-w64-mingw32/lib32/libgcc_s.a':
No such file or directory
That's from this bit:
# Remove redundant libgcc
rm -f ${D}/opt/mingw64/lib/gcc/x86_64-w64-mingw32/lib/libgcc_s.a
rm -f ${D}/opt/mingw64/lib/gcc/x86_64-w64-mingw32/lib32/libgcc_s.a
# Workaround GCC install bug
cp -pf ${D}/opt/mingw64/lib/gcc/x86_64-w64-mingw32/lib/libgcc_s.a
${D}/opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/
cp -pf ${D}/opt/mingw64/lib/gcc/x86_64-w64-mingw32/lib32/libgcc_s.a
${D}/opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/
I don't onder stand how the first two lines can be followed by the
second two? I mean, how can you copy a file AFTER you remove it? So
maybe the order of those should be reversed.
*** Warning: Cygwin README is missing
You need a README file of some kind in CYGWIN-PATCHES. It will be
installed as /usr/share/doc/Cygwin/mingw64-tc64-gcc4.README, and should
contain cygwin-specific information about the port.
realpath: No such file or directory
/usr/lib/cygport/src_postinst.cygpart: line 586: [: !=: unary operator
expected
opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libgfortran.la
This is part of __prep_libtool_modules(), and happens because:
if [ x${shouldnotlink} != xyes ]
Eg. this is the bit where cygport munges libtool files and you had
already said you want to suppress this behavior -- and are waiting for
my cygport patch.
It looks like you really can't go any further with this until I write
that patch, Yaakov accepts it, and a new cygport is released -- or you
use a different workaround. I wonder what Dave Korn's gcc cygport does
in this case?
Anyway, then cygport goes off and sucks 100% of CPU so I had to kill it.
--
Chuck
Re: [ITP] mingw-w64
OK, a bit further along. With the recently posted patch to cygport:
http://cygwin.com/ml/cygwin/2010-07/msg00117.html
AND the attached patch to your .cygport script, I get a bit further with
the install step. It completes without error (but I still have the
warning about the missing cygwin-specific README file, of course).
However, the DLLs don't appear to be in the correct locations.
opt/mingw64/bin/libobjc-2.dll
opt/mingw64/bin32/libgcc_s_sjlj-1.dll
opt/mingw64/bin64/libgcc_s_sjlj-1.dll
opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libgfortran-3.dll
opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libgomp-1.dll
opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libssp-0.dll
opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libstdc++-6.dll
opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libgfortran-3.dll
opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libgomp-1.dll
opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libssp-0.dll
opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libstdc++-6.dll
Now, the DLLs buried down in the 4.6.0/ directory I can see (it appears
to be a mistake, but that IS where they normally go...even if we
choose to put them in toplevel bin32 and bin64 dirs instead.) It looks
like the cygport is missing some 'mv' commands.
But how the heck did libobjc-2.dll get into the regular bin/ dir? And
why is there only one version of it?
--
Chuck
--- mingw64-tc64-gcc4-4.6.20100619-1.cygport.old2010-07-04
03:35:22.0 -0400
+++ mingw64-tc64-gcc4-4.6.20100619-1.cygport.new2010-07-05
13:35:20.17170 -0400
@@ -27,6 +27,7 @@
SRC_DIR=gcc-4.6-20100619
MAKEOPTS+= -j5
+RESTRICT=postinst-libtool-modules
#libelf not needed for lto-coff
#ADA forth comming, but needs Cygwin GCC 4.6
@@ -48,14 +49,14 @@
# Remove Cygwin libiberty.a
rm -f ${D}/opt/mingw64/lib/libiberty.a
-# Remove redundant libgcc
-rm -f ${D}/opt/mingw64/lib/gcc/x86_64-w64-mingw32/lib/libgcc_s.a
-rm -f ${D}/opt/mingw64/lib/gcc/x86_64-w64-mingw32/lib32/libgcc_s.a
-
# Workaround GCC install bug
cp -pf ${D}/opt/mingw64/lib/gcc/x86_64-w64-mingw32/lib/libgcc_s.a
${D}/opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/
cp -pf ${D}/opt/mingw64/lib/gcc/x86_64-w64-mingw32/lib32/libgcc_s.a
${D}/opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/
+# Remove redundant libgcc
+rm -f ${D}/opt/mingw64/lib/gcc/x86_64-w64-mingw32/lib/libgcc_s.a
+rm -f ${D}/opt/mingw64/lib/gcc/x86_64-w64-mingw32/lib32/libgcc_s.a
+
# Workaround problematic DLL clashes
# libgcc dll missing sometimes due to race condition on install?
dodir /opt/mingw64/bin32 /opt/mingw64/bin64
Re: [ITP] mingw-w64
On 7/6/2010 01:38, Charles Wilson wrote: OK, a bit further along. With the recently posted patch to cygport: http://cygwin.com/ml/cygwin/2010-07/msg00117.html AND the attached patch to your .cygport script, I get a bit further with the install step. It completes without error (but I still have the warning about the missing cygwin-specific README file, of course). However, the DLLs don't appear to be in the correct locations. opt/mingw64/bin/libobjc-2.dll opt/mingw64/bin32/libgcc_s_sjlj-1.dll opt/mingw64/bin64/libgcc_s_sjlj-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libgfortran-3.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libgomp-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libssp-0.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libstdc++-6.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libgfortran-3.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libgomp-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libssp-0.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libstdc++-6.dll Now, the DLLs buried down in the 4.6.0/ directory I can see (it appears to be a mistake, but that IS where they normally go...even if we choose to put them in toplevel bin32 and bin64 dirs instead.) It looks like the cygport is missing some 'mv' commands. But how the heck did libobjc-2.dll get into the regular bin/ dir? And why is there only one version of it? Hi, I had a thinko, thanks for the patch. Yeah, cygport moves the libtool dlls around. I will recheck on the README file and libobjc-2, I thought I patched up the configure file.
Re: [ITP] mingw-w64
On 7/6/2010 09:33, JonY wrote: On 7/6/2010 01:38, Charles Wilson wrote: OK, a bit further along. With the recently posted patch to cygport: http://cygwin.com/ml/cygwin/2010-07/msg00117.html AND the attached patch to your .cygport script, I get a bit further with the install step. It completes without error (but I still have the warning about the missing cygwin-specific README file, of course). However, the DLLs don't appear to be in the correct locations. opt/mingw64/bin/libobjc-2.dll opt/mingw64/bin32/libgcc_s_sjlj-1.dll opt/mingw64/bin64/libgcc_s_sjlj-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libgfortran-3.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libgomp-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libssp-0.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libstdc++-6.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libgfortran-3.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libgomp-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libssp-0.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libstdc++-6.dll Now, the DLLs buried down in the 4.6.0/ directory I can see (it appears to be a mistake, but that IS where they normally go...even if we choose to put them in toplevel bin32 and bin64 dirs instead.) It looks like the cygport is missing some 'mv' commands. But how the heck did libobjc-2.dll get into the regular bin/ dir? And why is there only one version of it? Hi, I had a thinko, thanks for the patch. Yeah, cygport moves the libtool dlls around. I will recheck on the README file and libobjc-2, I thought I patched up the configure file. Alright, I repackaged binutils to add the /etc/profile.d scripts and repackaged gcc to get rid of the wrongly installed objc dll. With the new libtool restrict, no more moving needed. I can also confirm that libobjc-2.dll goes into bin32 and bin64 on cygport install. No changes to pthreads, crt and headers.
Re: [ITP] mingw-w64
Hi, New copies are up, no changes to CRT. All have the same links except for pthreads. libgomp requires: is also fixed due to pthreads change. I hope I'm not getting sloppy. mingw64-tc64-m64-libpthread-devel https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-libpthread/mingw64-tc64-m64-libpthread-devel/mingw64-tc64-m64-libpthread-devel-20100619-1.tar.bz2/download category: Devel requires: mingw64-tc64-libpthread mingw64-tc64-libpthread-headers mingw64-m64-libpthread2 external-source: mingw64-tc64-libpthread sdesc: 64bit libgpthreadGC2 DLL import library. (Devel) ldesc: 64bit pthreads-win32 GC2 DLL import library for use with x86_64-w64-mingw32. (Devel) mingw64-tc64-m32-libpthread-devel https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-libpthread/mingw64-tc64-m32-libpthread-devel/mingw64-tc64-m32-libpthread-devel-20100619-1.tar.bz2/download category: Devel requires: mingw64-tc64-libpthread mingw64-tc64-libpthread-headers mingw64-m32-libpthread2 external-source: mingw64-tc64-libpthread sdesc: 32bit libgpthreadGC2 DLL import library. (Devel) ldesc: 32bit pthreads-win32 GC2 DLL import library for use with x86_64-w64-mingw32. (Devel) mingw64-tc64-libpthread-headers https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-libpthread/mingw64-tc64-libpthread-headers/mingw64-tc64-libpthread-headers-20100619-1.tar.bz2/download category: Devel requires: mingw64-tc64-libpthread mingw64-tc64-gcc4 external-source: mingw64-tc64-libpthread sdesc: libgpthreadGC2 DLL headers. (Devel) ldesc: pthreads-win32 GC2 DLL headers for use with x86_64-w64-mingw32. (Devel) mingw64-m64-libpthread2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-libpthread/mingw64-m64-libpthread2/mingw64-m64-libpthread2-20100619-1.tar.bz2/download category: Devel requires: mingw64-tc64-libpthread external-source: mingw64-tc64-libpthread sdesc: 64bit libgpthreadGC2 DLL. (Runtime) ldesc: 64bit pthreads-win32 GC2 DLL. (Runtime) mingw64-m32-libpthread2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-libpthread/mingw64-m32-libpthread2/mingw64-m32-libpthread2-20100619-1.tar.bz2/download category: Devel requires: mingw64-tc64-libpthread external-source: mingw64-tc64-libpthread sdesc: 32bit libgpthreadGC2 DLL. (Runtime) ldesc: 32bit pthreads-win32 GC2 DLL. (Runtime) https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-libpthread/mingw64-tc64-libpthread-20100619-1.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-libpthread/mingw64-tc64-libpthread-20100619-1-src.tar.bz2/download category: Devel requires: sdesc: libgpthreadGC2 DLL for Windows. (Docs) ldesc: Pthreads DLL for Windows. (Docs) mingw64-tc64-binutils https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-binutils/mingw64-tc64-binutils-2.20.51-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-binutils/mingw64-tc64-binutils-2.20.51-1.tar.bz2/download category: Devel requires: libgcc1 libintl8 sdesc: Binutils for Windows target. ldesc: Mingw-w64 Cross binutils for Win32 and Win64 target.(Mulilib, 64bit default) mingw64-m32-libgomp1 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-m32-libgomp1/mingw64-m32-libgomp1-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m32-libpthread2 mingw64-m32-libgcc1 external-source: mingw64-tc64-gcc4 sdesc: 32bit libgomp DLL. (Runtime) ldesc: 32bit libgomp DLL for use with OpenMP. (Runtime) mingw64-m64-libgomp1 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-m64-libgomp1/mingw64-m64-libgomp1-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m64-libpthread2 external-source: mingw64-tc64-gcc4 sdesc: 64bit libgomp DLL. (Runtime) ldesc: 64bit libgomp DLL for use with OpenMP. (Runtime) mingw64-tc64-m64-libgomp1-devel https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-m64-libgomp1-devel/mingw64-tc64-m64-libgomp1-devel-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m64-libgomp1 mingw64-tc64-m64-libpthread-devel mingw64-tc64-gcc4 external-source: mingw64-tc64-gcc4 sdesc: 64bit libgomp DLL import library. (Devel) ldesc: 64bit libgomp DLL import library for use with x86_64-w64-mingw32 mingw64-tc64-m32-libgomp1-devel https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-m32-libgomp1-devel/mingw64-tc64-m32-libgomp1-devel-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m32-libgomp1 mingw64-tc64-m32-libpthread-devel mingw64-tc64-gcc4 external-source: mingw64-tc64-gcc4 sdesc: 32bit libgomp DLL import library. (Devel) ldesc: 32bit
Re: [ITP] mingw-w64
On Sun, Jul 4, 2010 at 12:26 AM, Andy Koppe andy.ko...@gmail.com wrote:
PERHAPS it makes the most sense to provide two single-target compilers
(but most of the interop issues would remain; the only simplification
would be the elimination of any packages that are explicitly
mingw64-{tc64}-m32-foo or mingw64-{tc64}-m64-foo, in favor of one
that is just mingw64-tc64-foo.
OTOH, I understand the mingw64 guys want to ensure that the multilib
support they've added to gcc/w32 stays in good working order, so they
probably prefer to provide multilib regardless of any minor packaging
confusion.
I'd be termpted to go with two single-target compilers, but as long as
the mingw64 guys are happy to deal with two multilib ones long term, I
guess that's ok.
I personally would prefer two single-target compilers, from a
user-perspective. I find that it just plain works better with
autotools and other stuff, and the -mXX options are really only useful
when doing a quick gcc a.c -m64 manual compile (which few large
projects use). This is purely me and my own preferences.
As an admin of mingw-w64, however, I can definitely say that we need
the multilib toolchains to get as much exposure as possible to keep
them working well. So, I throw my own personal choices out the window
and defer to what's best for our project :) :) (Cal me biased :)
Re: [ITP] mingw-w64
On 3 July 2010 03:07, Charles Wilson wrote: Is mingw64 already part of a major Linux distribution? Otherwise it needs five votes from Cygwin maintainers. AFAICT, mingw64 is the mingw cross compiler provided by fedora. Great. Finally, I'm not sure what the conclusion was about which toolchain(s) will be included. Looks like a single multilib toolchain defaulting to 64 bits to me. If that's the case, is the tc64 bit in the name actually needed? IMO, even if JonY has no *immediate* plans for a default-to-32bit toolchain (whether multilib or single target), I think it makes sense to allow for the possibility in the package naming scheme. And...JonY already said he was saving the /i686-w64-mingw32/* tree for use by the default-to-32bit toolchain, so... What's the use case for having two multilib toolchains instead of either two standalone ones or a single multilib toolchain? Is it worth the extra packaging effort, and, more importantly, the extra scope for user confusion (particularly once the original MinGW is thrown into the mix as well)? Regarding the placement in /opt/mingw64, how do the Linux distributions deal with the problems that lead to that decision? I think this needs to be considered carefully because it sets a precedent for any other cross-compiler packages. Andy
Re: [ITP] mingw-w64
On 7/3/2010 2:28 AM, Andy Koppe wrote:
On 3 July 2010 03:07, Charles Wilson wrote:
Is mingw64 already part of a major Linux distribution? Otherwise it
needs five votes from Cygwin maintainers.
AFAICT, mingw64 is the mingw cross compiler provided by fedora.
Great.
Finally, I'm not sure what the conclusion was about which toolchain(s)
will be included. Looks like a single multilib toolchain defaulting to
64 bits to me. If that's the case, is the tc64 bit in the name
actually needed?
IMO, even if JonY has no *immediate* plans for a default-to-32bit
toolchain (whether multilib or single target), I think it makes sense to
allow for the possibility in the package naming scheme.
And...JonY already said he was saving the /i686-w64-mingw32/* tree for
use by the default-to-32bit toolchain, so...
What's the use case for having two multilib toolchains instead of
either two standalone ones or a single multilib toolchain?
My use case is: I'd like to install one compiler that handles both
targets. But, since my personal PCs are all 32bit, I'd rather that
compiler default to 32bit, and only create 64bit binaries on demand.
E.g. it feels odd to me to ROUTINELY have to say
--host=x86_64-w64-mingw32 CFLAGS=-m32
when I really want i686-w64-mingw32
But if, every once in a while, I have to say
--host=i686-w64-mingw32 CFLAGS=-m64
that's ok.
But I'm not saying that I can't deal with it the other way around. Or
with installing two separate single-target compilers.
However, the mingw64 project is mostly concerned with 64bit support, so
they probably WANT to provide a default-to-64bit compiler, since
that's their bread and butter.
PERHAPS it makes the most sense to provide two single-target compilers
(but most of the interop issues would remain; the only simplification
would be the elimination of any packages that are explicitly
mingw64-{tc64}-m32-foo or mingw64-{tc64}-m64-foo, in favor of one
that is just mingw64-tc64-foo.
OTOH, I understand the mingw64 guys want to ensure that the multilib
support they've added to gcc/w32 stays in good working order, so they
probably prefer to provide multilib regardless of any minor packaging
confusion.
Is it worth
the extra packaging effort, and, more importantly, the extra scope for
user confusion (particularly once the original MinGW is thrown into
the mix as well)?
I think we WILL need a new section in the FAQ. But I think that will be
true regardless of how we solve this conundrum. Cross compilers are
complex pieces of software, and newbies WILL have questions. And
multilib is odd, even on linux.
Regarding the placement in /opt/mingw64, how do the Linux
distributions deal with the problems that lead to that decision? I
think this needs to be considered carefully because it sets a
precedent for any other cross-compiler packages.
Most of the cross toolchains I've installed or used either install into
their owntree, OR are provided as patched source code and the
instructions include building them yourself -- again, installing into
their own tree. I'm not familiar with very many pre-packaged cross
toolchains that attempt to go directly into /usr.
One exception appears to be Fedora's mingw cross compiler. The
*compiler* appears to be compiled with --prefix=/usr with a sysroot.
Most of their build guidelines concern creating mingw packages for
OTHER things than the toolchain itself -- and in THOSE cases, they do
use a separate _mingw_prefix. But, those guidelines also include
statements like In general terms, MinGW packages which provide
cross-compiled versions of packages already natively available in
Fedora, should follow the native Fedora package as closely as possible.
This means they should stay at the same version, include all the same
patches as the native Fedora package, and be built with the same
configuration options.
If the same statement holds true for the compiler itself, then maybe
they either (a) just don't package the share/locale/*/ files and info
files for the cross compiler because it'll always be kept (track) the
same version as the platform compiler. OR (b) they just don't enable
i18n for the mingw cross compiler. Ditto info files? Man pages -- most
of them, anyway -- appear to automatically be renamed with $host- prefixing.
But...
While we should probably take hints from other platforms, cygwin is not
linux. If we have different predicates -- and we do -- then we will
reach different conclusions. And that's ok.
--
Chuck
Re: [ITP] mingw-w64
On 7/3/2010 1:44 PM, JonY wrote: On 7/3/2010 11:27, Charles Wilson wrote: Oddly, my build doesn't appear to depend on zlib0; libgcc1 and libintl8 (and cygwin, of course, but that is never included in requires:). It doesn't? I thought I saw -lz linked in for some executables. OK, will remove zlib0, libintl8 and libgcc. No, I mean that it doesn't appear to depend on zlib0. It *does* depend on libintl8 and libgcc1. So, I'd name these packages like so: mingw64-m32-libpthread2-20100619-1.tar.bz2 mingw64-m64-libpthread2-20100619-1.tar.bz2 mingw64-tc64-libpthread-20100619-1.tar.bz2 mingw64-tc64-libpthread-20100619-1-src.tar.bz2 mingw64-tc64-libpthread-headers-20100619-1.tar.bz2 OK, I'll try to fix this. Thanks for all your work. -- Chuck
Re: [ITP] mingw-w64
On 7/4/2010 04:04, Charles Wilson wrote: On 7/3/2010 1:44 PM, JonY wrote: On 7/3/2010 11:27, Charles Wilson wrote: Oddly, my build doesn't appear to depend on zlib0; libgcc1 and libintl8 (and cygwin, of course, but that is never included in requires:). It doesn't? I thought I saw -lz linked in for some executables. OK, will remove zlib0, libintl8 and libgcc. No, I mean that it doesn't appear to depend on zlib0. It *does* depend on libintl8 and libgcc1. So, in requires:, libgcc1 and libintl8 isn't usually listed? If so, are there any such other libraries not to be listed?
Re: [ITP] mingw-w64
On 7/3/2010 9:17 PM, JonY wrote: On 7/4/2010 04:04, Charles Wilson wrote: On 7/3/2010 1:44 PM, JonY wrote: On 7/3/2010 11:27, Charles Wilson wrote: Oddly, my build doesn't appear to depend on zlib0; libgcc1 and libintl8 (and cygwin, of course, but that is never included in requires:). It doesn't? I thought I saw -lz linked in for some executables. OK, will remove zlib0, libintl8 and libgcc. No, I mean that it doesn't appear to depend on zlib0. It *does* depend on libintl8 and libgcc1. So, in requires:, libgcc1 and libintl8 isn't usually listed? If so, are there any such other libraries not to be listed? No, no. I'm sorry. I must not be expressing myself very well. cygwin is the only actual requirement that we omit from listing explicitly, since EVERYTHING depends on cygwin, and setup.exe knows that. My original statement should have said: Oddly, my build doesn't appear to depend on zlib0[. It does, however, depend on] libgcc1 and libintl8 (and [it also depends on] cygwin, of course, but that is never included in requires:). So, IF your binaries are like mine, and do not depend on zlib (but do depend on the other three packages), then your requirement line should read: requires: libintl8 libgcc1 -- Chuck
Re: [ITP] mingw-w64
On 7/4/2010 12:41, Charles Wilson wrote: On 7/3/2010 9:17 PM, JonY wrote: On 7/4/2010 04:04, Charles Wilson wrote: On 7/3/2010 1:44 PM, JonY wrote: On 7/3/2010 11:27, Charles Wilson wrote: Oddly, my build doesn't appear to depend on zlib0; libgcc1 and libintl8 (and cygwin, of course, but that is never included in requires:). It doesn't? I thought I saw -lz linked in for some executables. OK, will remove zlib0, libintl8 and libgcc. No, I mean that it doesn't appear to depend on zlib0. It *does* depend on libintl8 and libgcc1. So, in requires:, libgcc1 and libintl8 isn't usually listed? If so, are there any such other libraries not to be listed? No, no. I'm sorry. I must not be expressing myself very well. cygwin is the only actual requirement that we omit from listing explicitly, since EVERYTHING depends on cygwin, and setup.exe knows that. My original statement should have said: Oddly, my build doesn't appear to depend on zlib0[. It does, however, depend on] libgcc1 and libintl8 (and [it also depends on] cygwin, of course, but that is never included in requires:). So, IF your binaries are like mine, and do not depend on zlib (but do depend on the other three packages), then your requirement line should read: requires: libintl8 libgcc1 Thanks for clearing that up.
Re: [ITP] mingw-w64
Hi, Here are the GCC links. I hope I got them all. mingw64-tc64-gcc4: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-gcc4-4.6.20100619-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-gcc4-4.6.20100619-1.tar.bz2/download category: Devel requires: libgcc1 libgmp3 libgmpxx4 libppl libmpc1 libstdc++6 libcloog0 libintl8 mingw64-tc64-crt mingw64-tc64-m64-libgomp1-devel mingw64-m64-libgcc1 mingw64-tc64-m64-libssp0-devel sdesc: GCC C frontend for Windows target. ldesc: Mingw-w64 GCC for Windows target development.(C frontend, Mulilib, 64bit default) mingw64-m64-libssp0: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-m64-libssp0/mingw64-m64-libssp0-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m64-libgcc1 external-source: mingw64-tc64-gcc4 sdesc: 64bit libssp DLL. (Runtime) ldesc: 64bit GCC Stack Smash protection DLL. (Runtime) mingw64-tc64-m64-libssp0-devel: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-m64-libssp0-devel/mingw64-tc64-m64-libssp0-devel-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-tc64-gcc4 mingw64-m64-libssp0 external-source: mingw64-tc64-gcc4 sdesc: 64bit libssp DLL import library. (Devel) ldesc: 64bit GCC Stack Smash protection DLL import library for use with x86_64-w64-mingw32. (Devel) mingw64-m64-libssp0: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-m64-libssp0/mingw64-m64-libssp0-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m64-libgcc1 external-source: mingw64-tc64-gcc4 sdesc: 64bit libssp DLL. (Runtime) ldesc: 64bit GCC Stack Smash protection DLL. (Runtime) mingw64-m32-libssp0: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-m32-libssp0/mingw64-m32-libssp0-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m32-libgcc1 external-source: mingw64-tc64-gcc4 sdesc: 32bit libssp DLL. (Runtime) ldesc: 32bit GCC Stack Smash protection DLL. (Runtime) mingw64-tc64-m32-libssp0-devel: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-m32-libssp0-devel/mingw64-tc64-m32-libssp0-devel-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-tc64-gcc4 mingw64-m32-libssp0 external-source: mingw64-tc64-gcc4 sdesc: 32bit libssp DLL import library. (Devel) ldesc: 32bit GCC Stack Smash protection DLL import library for use with x86_64-w64-mingw32. (Devel) mingw64-m64-libgomp1 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-m64-libgomp1/mingw64-m64-libgomp1-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m64-libpthread2 external-source: mingw64-tc64-gcc4 sdesc: 64bit libgomp DLL. (Runtime) ldesc: 64bit libgomp DLL for use with OpenMP. (Runtime) mingw64-m32-libgomp1 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-m32-libgomp1/mingw64-m32-libgomp1-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m32-libpthread2 mingw64-m32-libgcc1 external-source: mingw64-tc64-gcc4 sdesc: 32bit libgomp DLL. (Runtime) ldesc: 32bit libgomp DLL for use with OpenMP. (Runtime) mingw64-tc64-m64-libgomp1-devel https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-m64-libgomp1-devel/mingw64-tc64-m64-libgomp1-devel-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m64-libgomp1 mingw64-tc64-m64-libpthread2-devel mingw64-tc64-gcc4 external-source: mingw64-tc64-gcc4 sdesc: 64bit libgomp DLL import library. (Devel) ldesc: 64bit libgomp DLL import library for use with x86_64-w64-mingw32 mingw64-tc64-m32-libgomp1-devel https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-m32-libgomp1-devel/mingw64-tc64-m32-libgomp1-devel-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m32-libgomp1 mingw64-tc64-m32-libpthread2-devel mingw64-tc64-gcc4 external-source: mingw64-tc64-gcc4 sdesc: 32bit libgomp DLL import library. (Devel) ldesc: 32bit libgomp DLL import library for use with x86_64-w64-mingw32 mingw64-tc64-gcc4-g++ https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-gcc4-g%2B%2B/mingw64-tc64-gcc4-g%2B%2B-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-tc64-gcc4 mingw64-tc64-m64-libstdc++6-devel external-source: mingw64-tc64-gcc4 sdesc: GCC C++ frontend for Windows target. ldesc: Mingw-w64 GCC for Windows target development.(C++ frontend, Mulilib, 64bit default) mingw64-tc64-gcc4-gfortran
Re: [ITP] mingw-w64
I forgot to mention, don't upload GCC first, I need to confirm the nature of the gcc bug with Kai. Some GCC headers are needlessly shadowing the system headers.
Re: [ITP] mingw-w64
On 7/2/2010 14:38, JonY wrote: I forgot to mention, don't upload GCC first, I need to confirm the nature of the gcc bug with Kai. Some GCC headers are needlessly shadowing the system headers. OK to upload if packaging is fine, no changes needed.
Re: [ITP] mingw-w64
On 2 July 2010 08:17, JonY wrote: OK to upload if packaging is fine, no changes needed. Great to see mingw64 coming to Cygwin, but I think the upload should wait until Cygwin gcc maintainer Dave Korn has had a chance to comment on this. Is mingw64 already part of a major Linux distribution? Otherwise it needs five votes from Cygwin maintainers. Also, are you sure that gcc-4.6 is sufficiently stable for release, i.e. that there won't be any more compatibility breaking changes before official release? Finally, I'm not sure what the conclusion was about which toolchain(s) will be included. Looks like a single multilib toolchain defaulting to 64 bits to me. If that's the case, is the tc64 bit in the name actually needed? Andy
Re: [ITP] mingw-w64
On Fri, Jul 2, 2010 at 1:41 PM, Andy Koppe andy.ko...@gmail.com wrote: Is mingw64 already part of a major Linux distribution? Otherwise it needs five votes from Cygwin maintainers. Ubuntu, Debian, and Fedora. Also, are you sure that gcc-4.6 is sufficiently stable for release, i.e. that there won't be any more compatibility breaking changes before official release? It is unlikely given the roadmap of 4.6. Finally, I'm not sure what the conclusion was about which toolchain(s) will be included. Looks like a single multilib toolchain defaulting to 64 bits to me. If that's the case, is the tc64 bit in the name actually needed? I thought it was both.
Re: [ITP] mingw-w64
On 7/2/2010 1:41 PM, Andy Koppe wrote: On 2 July 2010 08:17, JonY wrote: OK to upload if packaging is fine, no changes needed. Great to see mingw64 coming to Cygwin, but I think the upload should wait until Cygwin gcc maintainer Dave Korn has had a chance to comment on this. I agree. Apparently DK has been AFK for a few weeks, but I think he's back now. Is mingw64 already part of a major Linux distribution? Otherwise it needs five votes from Cygwin maintainers. AFAICT, mingw64 is the mingw cross compiler provided by fedora. Also, are you sure that gcc-4.6 is sufficiently stable for release, i.e. that there won't be any more compatibility breaking changes before official release? That...is beyond my ken. Finally, I'm not sure what the conclusion was about which toolchain(s) will be included. Looks like a single multilib toolchain defaulting to 64 bits to me. If that's the case, is the tc64 bit in the name actually needed? IMO, even if JonY has no *immediate* plans for a default-to-32bit toolchain (whether multilib or single target), I think it makes sense to allow for the possibility in the package naming scheme. And...JonY already said he was saving the /i686-w64-mingw32/* tree for use by the default-to-32bit toolchain, so... -- Chuck
Re: [ITP] mingw-w64
I am a little surprised that you got this to work simply by passing
--prefix=/opt/mingw64/... and a few other flags. Last time I looked
closely, cygport assumed /usr in quite a few places. Maybe that's
changed; if so, cool!
On 7/2/2010 1:29 AM, JonY wrote:
mingw64-tc64-headers:
...
category: Devel
requires: mingw64-tc64-gcc4
sdesc: Headers for Windows target.
ldesc: Mingw-w64 headers for Windows target development.
Rebuilds cleanly from source. Packaging looks ok (assuming current
status of naming discussion represents the ultimate consensus view).
I think you should included your branding in the sdesc:
Mingw-w64 headers for Windows target development.
or something. Also, I think you should specify in the ldesc that this
package is for both -m32 and -m64, AND that it's for the
default-to-64bit toolchain.
Mingw-w64 headers for Windows target development, for use with
the Mingw-w64 toolchain that defaults to 64bit output. However, this
package supports that toolchain in both 64bit (-m64) and 32bit (-m32)
mode.
Finally, I don't think this package actually *requires* the compiler,
does it? It may not be of any USE without the compiler, but I could
install it just to look at the files, right?
mingw64-tc64-binutils:
category: Devel
requires: libgcc1 zlib0 libintl8
sdesc: Binutils for Windows target.
ldesc: Cross binutils for Win64 and Win32 target.(Mulilib, 64bit default)
Packaging looks ok (assuming current status of naming discussion
represents the ultimate consensus view).
Rebuilds (almost) fine from source. There is a warning during packaging:
Checking packages for missing or duplicate files
*** Warning: Packages are missing files:
-opt/mingw64/lib/libiberty.a
Now, I know you don't WANT to include libiberty.a in the package, so to
suppress the warning just override src_install():
src_install() {
cd ${B}
cyginstall
rm -f ${D}/opt/mingw64/lib/libiberty.a
}
Again, I'd include the mingw64 branding in sdesc (actually, your
original ldesc is a better sdesc...):
Mingw-w64 cross binutils for windows target (multilib, 64bit default)
And with ldesc:
Mingw-w64 cross binutils for Win64 and Win32 target. This is part
of a multilib toolchain that defaults to 64bit output, but supports both
64bit (-m64) and 32bit (-m32) mode.
Oddly, my build doesn't appear to depend on zlib0; libgcc1 and libintl8
(and cygwin, of course, but that is never included in requires:).
mingw64-tc64-m32-crt:
mingw64-tc64-crt:
mingw64-tc64-m64-crt:
I assume I need the mingw64-tc64-gcc to (re)build these, so I'll have to
verify that later (and comment on the setup.hints)
Packaging looks ok (assuming current status of naming discussion
represents the ultimate consensus view).
One oddity: the -m64 package contains 2112 files, but the -m32 package
contains only 227 files. Is that expected? I would have thought that
the same libraries would be available in both lib/* and lib32/*
mingw64-tc64-libpthread2
mingw64-tc64-libpthread2-headers
mingw64-m64-libpthread2
mingw64-m32-libpthread2
Again, I assume I need the mingw64-tc64-gcc to (re)build these, so I'll
have to verify that later (and comment on the setup.hints)
The packaging needs a few more tweaks. Usually, we only include the
'dll version' in the package name of the packages that actually contain
the DLLs themselves:
mingw64-m64-libpthread2
mingw64-m32-libpthread2
The docs and headers are not really versioned -- it's not as if you
could have two distinct versions installed (for the same bitdepth and
toolchain) at the same time. (it's pthread.h not pthread2.h)
So, I'd name these packages like so:
mingw64-m32-libpthread2-20100619-1.tar.bz2
mingw64-m64-libpthread2-20100619-1.tar.bz2
mingw64-tc64-libpthread-20100619-1.tar.bz2
mingw64-tc64-libpthread-20100619-1-src.tar.bz2
mingw64-tc64-libpthread-headers-20100619-1.tar.bz2
--
Chuck
Re: [ITP] mingw-w64
On 6/30/2010 7:12 PM, Charles Wilson wrote: Do also give the ability to tell cygport to exclude some libtool files from getting fixed up, thanks. Again, I *think* you can suppress this; I'll check tomorrow. No, apparently you can't (yet) do this. It's fairly easy to add, though. I'll try to whip up a patch for cygport in the next week or so. -- Chuck
Re: [ITP] mingw-w64
On 6/30/2010 3:50 PM, Charles Wilson wrote: On 6/30/2010 1:51 PM, JonY wrote: Right now, human intervention still needed. cygport messes up the target dll locations by moving them around and trying to fix libtool files. Its also using cygwin strip(1) to strip 64bit dlls, it fails but doesn't lead to the cygport halting. I think you can set a variable in your cygport to suppress both of these actions -- and then use the correct tool manually in src_install(). I'll check later. OK, you can't (yet) suppress the fixup-libtool step, but you can suppress stripping the DLLs and EXEs (and then explicitly do it manually in src_install). Just add RESTRICT=strip to your cygport. -- Chuck
Re: [ITP] mingw-w64
Hi, new uploads done. GCC links in the next mail. mingw64-tc64-headers: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-headers/mingw64-tc64-headers-20100701-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-headers/mingw64-tc64-headers-20100701-1.tar.bz2/download category: Devel requires: mingw64-tc64-gcc4 sdesc: Headers for Windows target. ldesc: Mingw-w64 headers for Windows target development. mingw64-tc64-m32-crt: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-crt/mingw64-tc64-m32-crt/mingw64-tc64-m32-crt-20100701-1.tar.bz2/download category: Devel requires: mingw64-tc64-crt external-source: mingw64-tc64-crt sdesc: Libraries for Windows target (32bit libraries, for x86_64-w64-mingw32). ldesc: Mingw-w64 libraries for Windows target development. This package contains the 32bit libraries for the x86_64-w64-mingw32 toolchain. See and mingw64-tc64-m64-crt mingw64-tc64-crt: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-crt/mingw64-tc64-crt-20100701-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-crt/mingw64-tc64-crt-20100701-1.tar.bz2/download category: Devel requires: mingw64-tc64-headers mingw64-tc64-m64-crt sdesc: Libraries for Windows target (Docs only). ldesc: Mingw-w64 libraries for Windows target development. Doc package, see mingw64-tc64-m64-crt and mingw64-tc64-m32-crt for libraries. mingw64-tc64-m64-crt: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-crt/mingw64-tc64-m64-crt/mingw64-tc64-m64-crt-20100701-1.tar.bz2/download category: Devel requires: mingw64-tc64-crt external-source: mingw64-tc64-crt sdesc: Libraries for Windows target (64bit libraries, for x86_64-w64-mingw32). ldesc: Mingw-w64 libraries for Windows target development. This package contains the 64bit libraries for the x86_64-w64-mingw32 toolchain. See and mingw64-tc64-m32-crt for 32bit import libraries. mingw64-tc64-binutils: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-binutils/mingw64-tc64-binutils-2.20.51-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-binutils/mingw64-tc64-binutils-2.20.51-1.tar.bz2/download category: Devel requires: libgcc1 zlib0 libintl8 sdesc: Binutils for Windows target. ldesc: Cross binutils for Win64 and Win32 target.(Mulilib, 64bit default) mingw64-tc64-libpthread2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-libpthread2/mingw64-tc64-libpthread2-20100619-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-libpthread2/mingw64-tc64-libpthread2-20100619-1.tar.bz2/download category: Devel requires: sdesc: libgpthreadGC2 DLL for Windows. (Docs) ldesc: Pthreads DLL for Windows. (Docs) mingw64-tc64-libpthread2-headers https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-libpthread2/mingw64-tc64-libpthread2-headers/mingw64-tc64-libpthread2-headers-20100619-1.tar.bz2/download category: Devel requires: mingw64-tc64-libpthread2 mingw64-tc64-gcc4 external-source: mingw64-tc64-libpthread2 sdesc: libgpthreadGC2 DLL headers. (Devel) ldesc: pthreads-win32 GC2 DLL headers for use with x86_64-w64-mingw32. (Devel) mingw64-m64-libpthread2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-libpthread2/mingw64-m64-libpthread2/mingw64-m64-libpthread2-20100619-1.tar.bz2/download category: Devel requires: mingw64-tc64-libpthread2 external-source: mingw64-tc64-libpthread2 sdesc: 64bit libgpthreadGC2 DLL. (Runtime) ldesc: 64bit pthreads-win32 GC2 DLL. (Runtime) mingw64-m32-libpthread2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-libpthread2/mingw64-m32-libpthread2/mingw64-m32-libpthread2-20100619-1.tar.bz2/download category: Devel requires: mingw64-tc64-libpthread2 external-source: mingw64-tc64-libpthread2 sdesc: 32bit libgpthreadGC2 DLL. (Runtime) ldesc: 32bit pthreads-win32 GC2 DLL. (Runtime)
Re: [ITP] mingw-w64
On 6/29/2010 1:13 PM, JonY wrote: On 6/30/2010 00:10, Charles Wilson wrote: 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. Ah. Well, in that case I would think that the origin should come first, rather than the bitdepth. Our existing mingw-runtime package is from (effectively) mingw.org, after all (*). More below. (*) Well, both mingw.org mingwrt and cygwin's mingw-runtime come from a common repository: the winsup/mingw directory on sourceware's CVS server. [note that the mingwrt and w32api parts of mingw.org are hosted by sourceware; all the rest of mingw.org including other source code repos are hosted by sourceFORGE. The reason for the split is historical.] I don't know much about sf's buildbot; I assume that if you can get a cygport to DTRT on your home PC without human intervention except for kicking off the build, then you can convince the buildbot to do it for you? 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). Hmm. So, big picture, we have possibly three different mingw-ish compilers, and you're currently attempting to shepherd the first one, while being mindful of future issues related to simultaneous installation of both of the first two: (1) mingw64-derived, multilib, default 64bit (2) mingw64-derived, multilib, default 32bit (3) mingw.org-derived, non-multilib, only 32bit In the first two cases, they each must deliver some components in both 32 and 64 bit form, while some components (within a single case 1 or 2) are shared. However, NO components are shared BETWEEN any of the three cases, not even between (1) and (2). (**) (**) except for a possible sharing of target runtime DLLs with the same target bitdepth, but that's a small matter, discussed at the end of this email. Correct so far? Now, SOME of the components that cannot be shared between (1) and (2) will be IDENTICAL in content, EXCEPT that they get installed into different locations. This would include, for instance, the runtime DLLs for, say, 32bit libgcc1 (UNLESS the 'share the target runtimes between (1) and (2)' approach is taken, but assume for the moment that we do not; wait until the end of this email for that discussion). So, we need a naming scheme that accounts for: 1) origin 2) default bit depth of the tool chain 3) bit depth of the target I think I would drop 'w64' since that's abiguous. windows 64? is that tool chain default, so I've got to use -m32 if I want 32bit, or is that the actual bit depth of the contents, like import libraries for linking 64bit target executables? (Aside: I pity the organizational nightmare that you have to deal with over at mingw64.org, because you've got yet another set of 32/64 bifurcations: what is the bit depth of the toolchain EXE's themselves: is ld.exe a 32bit or 64bit executable...at least cygwin is just...cygwin.) In fact, for complete clarity, I think I'd use: -tc64- or -tc32-== toolchain default bitdepth 64 or 32 -m64- or -m32- == bit depth 64 or 32(use m as a mnemonic for which -mNN option it corresponds to) (And, returning to the aside, that 'frees up' the 'w64'/'w32' tag for use in distinguishing the bit depth of native windows ld.exe/gcc.exe: w64-gcc4 contains a binary gcc4.exe that runs as a 64bit native windows application. Not that you guys need or want to use an elaborate package naming scheme like it appears we need here. You don't have setup.exe to worry about.) If something is common to BOTH, then just drop that element. E.g. both the -m32 and -m64 mingw headers are provided by the same package, so that package would have only mingw64-tc64-. OTOH, if you split the mingw import libs for the defaults-to-64bit toolchain between the normal ones (for that toolchain, e.g. 64bit) and the lib32/ ones, then you'd have mingw64-tc64-m64 and mingw64-tc64-m32 And, I'd put all that categorization up front, so that
Re: [ITP] mingw-w64
As an aside, to compile with a different prefix using cygport requires a bit of work right now, because AFAIK cygport doesn't support anything but --prefix=/usr. See http://cygwin.osuosl.org/release/autoconf/gcc-tools-epoch2-autoconf/gcc-tools-epoch2-autoconf-2.64-1-src.tar.bz2 for how I did it. Basically I had to copy cygport's cygconf() function and modify it, ditto cygports cyginstall() function. Then, from my src_compile() and src_install() I called my copies. That's what was needed to put autoconf into /opt/gcc-tools/epoch2/ but other, more complex packages -- and they don't get much more complex that gcc! -- might need even more custom overrides. P.S. Hey, Yaakov -- any chance cygport could start supporting custom prefixes? Maybe by inheriting some special cygclass? -- Chuck
Re: [ITP] mingw-w64
On 7/1/2010 00:36, Charles Wilson wrote: On 6/29/2010 1:13 PM, JonY wrote: On 6/30/2010 00:10, Charles Wilson wrote: 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. Ah. Well, in that case I would think that the origin should come first, rather than the bitdepth. Our existing mingw-runtime package is from (effectively) mingw.org, after all (*). More below. (*) Well, both mingw.org mingwrt and cygwin's mingw-runtime come from a common repository: the winsup/mingw directory on sourceware's CVS server. [note that the mingwrt and w32api parts of mingw.org are hosted by sourceware; all the rest of mingw.org including other source code repos are hosted by sourceFORGE. The reason for the split is historical.] I understand, they do use sourceware's combined configure tree. I don't know much about sf's buildbot; I assume that if you can get a cygport to DTRT on your home PC without human intervention except for kicking off the build, then you can convince the buildbot to do it for you? Right now, human intervention still needed. cygport messes up the target dll locations by moving them around and trying to fix libtool files. Its also using cygwin strip(1) to strip 64bit dlls, it fails but doesn't lead to the cygport halting. 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). Hmm. So, big picture, we have possibly three different mingw-ish compilers, and you're currently attempting to shepherd the first one, while being mindful of future issues related to simultaneous installation of both of the first two: (1) mingw64-derived, multilib, default 64bit (2) mingw64-derived, multilib, default 32bit (3) mingw.org-derived, non-multilib, only 32bit In the first two cases, they each must deliver some components in both 32 and 64 bit form, while some components (within a single case 1 or 2) are shared. However, NO components are shared BETWEEN any of the three cases, not even between (1) and (2). (**) (**) except for a possible sharing of target runtime DLLs with the same target bitdepth, but that's a small matter, discussed at the end of this email. Correct so far? Correct, I am attempting the first. Now, SOME of the components that cannot be shared between (1) and (2) will be IDENTICAL in content, EXCEPT that they get installed into different locations. This would include, for instance, the runtime DLLs for, say, 32bit libgcc1 (UNLESS the 'share the target runtimes between (1) and (2)' approach is taken, but assume for the moment that we do not; wait until the end of this email for that discussion). So, we need a naming scheme that accounts for: 1) origin 2) default bit depth of the tool chain 3) bit depth of the target I think I would drop 'w64' since that's abiguous. windows 64? is that tool chain default, so I've got to use -m32 if I want 32bit, or is that the actual bit depth of the contents, like import libraries for linking 64bit target executables? (Aside: I pity the organizational nightmare that you have to deal with over at mingw64.org, because you've got yet another set of 32/64 bifurcations: what is the bit depth of the toolchain EXE's themselves: is ld.exe a 32bit or 64bit executable...at least cygwin is just...cygwin.) Well, Windows is special. It has Cygwin, MinGW, Interix, mingw-w64 and etc, all possibly running on the same time, while Linux is just Linux. It takes some nerve to get them to cooperate :) In fact, for complete clarity, I think I'd use: -tc64- or -tc32- == toolchain default bitdepth 64 or 32 -m64- or -m32- == bit depth 64 or 32(use m as a mnemonic for which -mNN option it corresponds to) (And, returning to the aside, that 'frees up' the 'w64'/'w32' tag for use in distinguishing the bit depth of native windows ld.exe/gcc.exe: w64-gcc4 contains a binary gcc4.exe that runs as a 64bit native windows application. Not that you guys need or want to use an elaborate package naming scheme like it appears we need
Re: [ITP] mingw-w64
On 7/1/2010 00:49, Charles Wilson wrote: As an aside, to compile with a different prefix using cygport requires a bit of work right now, because AFAIK cygport doesn't support anything but --prefix=/usr. See http://cygwin.osuosl.org/release/autoconf/gcc-tools-epoch2-autoconf/gcc-tools-epoch2-autoconf-2.64-1-src.tar.bz2 for how I did it. Basically I had to copy cygport's cygconf() function and modify it, ditto cygports cyginstall() function. Then, from my src_compile() and src_install() I called my copies. That's what was needed to put autoconf into /opt/gcc-tools/epoch2/ but other, more complex packages -- and they don't get much more complex that gcc! -- might need even more custom overrides. Thanks, I will check it out. (btw, libtool too needs to get an epoch version, having problems with macro version mismatches in gcc cygautoreconf). I added --prefix=/somewhere to CYGCONF_ARGS to override cygport defaults by taking advantage of autotool's behavior (...configure...--prefix=/usr...--prefix=/somewhere), but I don't think its appropriate. P.S. Hey, Yaakov -- any chance cygport could start supporting custom prefixes? Maybe by inheriting some special cygclass? Do also give the ability to tell cygport to exclude some libtool files from getting fixed up, thanks.
Re: [ITP] mingw-w64
On Wed, Jun 30, 2010 at 12:36 PM, Charles Wilson cyg...@cwilson.fastmail.fm wrote: Hmm. So, big picture, we have possibly three different mingw-ish compilers, and you're currently attempting to shepherd the first one, while being mindful of future issues related to simultaneous installation of both of the first two: (1) mingw64-derived, multilib, default 64bit (2) mingw64-derived, multilib, default 32bit (3) mingw.org-derived, non-multilib, only 32bit Is there any reason why there wouldn't be non-multilib versions of our stuff? How many permutations do you want to have?
Re: [ITP] mingw-w64
On 6/30/2010 2:53 PM, NightStrike wrote:
On Wed, Jun 30, 2010 at 12:36 PM, Charles Wilson wrote:
Hmm. So, big picture, we have possibly three different mingw-ish compilers,
and you're currently attempting to shepherd the first one, while being
mindful of future issues related to simultaneous installation of both of the
first two:
(1) mingw64-derived, multilib, default 64bit
(2) mingw64-derived, multilib, default 32bit
(3) mingw.org-derived, non-multilib, only 32bit
Is there any reason why there wouldn't be non-multilib versions of our
stuff?
I don't really mind either way. I first raised the question of whether
JonY's package would support -m32 or just -m64. His answer was -m64
only, but then he almost immediately released a revision #2 that was
multilib.
I assumed that would be the only version, but in the NEXT email
exchange, he stated he was saving the /i686-w64-mingw32/ directory
tree for the (multilib?) version that would default to -m32.
Now, maybe his original plan was to propose two separate non-multilib
compilers, and he didn't think through the implications TO that plan
that switching to multilib would cause.
But again, I don't care either way: one multilib with a specific
default: fine.
Two non-multilibs, one for w64 and one for w32: fine.
Two multilibs, basically identical except for the different default (and
the duplicated /{x85_85|i686}-w64-mingw32/ installation trees): also fine.
THAT's up to JonY. He seems to have settled on the third of these
options (especially given how the pthread stuff was packaged), but the
other choices would also be A-OK IMO.
How many permutations do you want to have?
Whatever's necessary to build both 64bit and 32bit binaries using your
stuff. What that actually means in terms of configure options...is
JonY's decision. I'm just trying to help him package what he wants to
provide, in a way that will let setup.exe be happy, and not violate (too
many) cygwin packaging standards.
I'm really not trying to pile extra work on JonY.
--
Chuck
Re: [ITP] mingw-w64
On Wed, Jun 30, 2010 at 3:34 PM, Charles Wilson
cyg...@cwilson.fastmail.fm wrote:
On 6/30/2010 2:53 PM, NightStrike wrote:
On Wed, Jun 30, 2010 at 12:36 PM, Charles Wilson wrote:
Hmm. So, big picture, we have possibly three different mingw-ish
compilers,
and you're currently attempting to shepherd the first one, while being
mindful of future issues related to simultaneous installation of both of
the
first two:
(1) mingw64-derived, multilib, default 64bit
(2) mingw64-derived, multilib, default 32bit
(3) mingw.org-derived, non-multilib, only 32bit
Is there any reason why there wouldn't be non-multilib versions of our
stuff?
I don't really mind either way. I first raised the question of whether
JonY's package would support -m32 or just -m64. His answer was -m64 only,
but then he almost immediately released a revision #2 that was multilib.
I assumed that would be the only version, but in the NEXT email exchange,
he stated he was saving the /i686-w64-mingw32/ directory tree for the
(multilib?) version that would default to -m32.
Now, maybe his original plan was to propose two separate non-multilib
compilers, and he didn't think through the implications TO that plan that
switching to multilib would cause.
But again, I don't care either way: one multilib with a specific default:
fine.
Two non-multilibs, one for w64 and one for w32: fine.
Two multilibs, basically identical except for the different default (and the
duplicated /{x85_85|i686}-w64-mingw32/ installation trees): also fine.
THAT's up to JonY. He seems to have settled on the third of these options
(especially given how the pthread stuff was packaged), but the other choices
would also be A-OK IMO.
How many permutations do you want to have?
Whatever's necessary to build both 64bit and 32bit binaries using your
stuff. What that actually means in terms of configure options...is JonY's
decision. I'm just trying to help him package what he wants to provide, in
a way that will let setup.exe be happy, and not violate (too many) cygwin
packaging standards.
I'm really not trying to pile extra work on JonY.
Ok, sounds good.
Re: [ITP] mingw-w64
On 6/30/2010 1:51 PM, JonY wrote:
On 7/1/2010 00:36, Charles Wilson wrote:
I don't know much about sf's buildbot; I assume that if you can get a
cygport to DTRT on your home PC without human intervention except for
kicking off the build, then you can convince the buildbot to do it for
you?
Right now, human intervention still needed. cygport messes up the target
dll locations by moving them around and trying to fix libtool files. Its
also using cygwin strip(1) to strip 64bit dlls, it fails but doesn't
lead to the cygport halting.
I think you can set a variable in your cygport to suppress both of these
actions -- and then use the correct tool manually in src_install().
I'll check later.
So, we need a naming scheme that accounts for:
1) origin
2) default bit depth of the tool chain
3) bit depth of the target
...
In fact, for complete clarity, I think I'd use:
-tc64- or -tc32- == toolchain default bitdepth 64 or 32
-m64- or -m32- == bit depth 64 or 32(use m as a mnemonic
for which -mNN option it corresponds to)
...
If something is common to BOTH, then just drop that element. E.g. both
the -m32 and -m64 mingw headers are provided by the same package, so
that package would have only mingw64-tc64-. OTOH, if you split the
mingw import libs for the defaults-to-64bit toolchain between the
normal ones (for that toolchain, e.g. 64bit) and the lib32/ ones, then
you'd have mingw64-tc64-m64 and mingw64-tc64-m32
Yes, this is a nice plan, clear and concise naming.
Glad you approve. :-)
The pthreads naming is a bit confusing (to myself as well). I should
change it to something easier. Ideas welcome.
Well, if the ideas above make sense, then it should be pretty
straightforward to extend them to libpthread2.
From the packaging point of view, having them buried in toolchain is a
lot easier than trying to move them around at postinstall.
Hmm...maybe. There are two meanings of the term postinstall. There's
after setup.exe unpacks the tarball on the end-users computer, it runs
a postinstall script. And there's in cygport, within src_install() you
can do additional manipulations of the ${D} tree after calling
cyginstall()/'make install'.
Sure, postinstall scripts in the first sense are a little icky. But I've
never had much trouble manipulating things in src_install().
OK, I will use --prefix=/opt/mingw64 and
--with-sysroot=/opt/mingw64/{x86_64,i686}-w64-mingw32 to avoid stuff
clashing with /usr/share.
Target DLLs will go in /opt/mingw64/bin{32,64}. Users will have a
consistent place to look for them.
I really think this makes sense -- but before haring off on my wild
ideas, wait for some other folks to chime in here. Sounds like
NightStrike isn't too happy with my suggestions.
To consolidate the DLLs, only one copy for 32bit and 64bit will be
packaged from one of the compilers and placed in
/opt/mingw64/bin{32,64}. For example, packaging 32bit libgcc DLL from
the 64bit toolchain, but leaving out the one from the 32bit toolchain
since they're similar.
This leads to the next question, how do I add the /opt/mingw64/bin to
the user's $PATH after installation?
THAT's easy. Just put a couple of files in CYGWIN-PATCHES called
mingw64-tc64.csh
mingw64-tc64.sh
and install them during src_install() into
${D}/etc/profile.d/
They should just add /opt/mingw64/bin/ to the $PATH (front, probably).
Remember, on cygwin we're not too fussed about requiring somebody to
either use a shell (so that .dotfiles can set $PATH and stuff) or to be
knowledgable enough to manually set PATH themselves, if they want to
call cygwin apps from windows directly. Unlike mingw.org and mingw64.
I am currently using this approach, this leads to long and complicated
--exclude lines. Does the list file allow \n delimited list of files to
include in the tarball release?
Yes. cygport basically passes that file to tar via -T. Take a close
look at my gettext cygport: I added functions so that I could use
regexes in the .list file.
That was my first attempt, but I concluded its better to have them
shared according to your replies. There will still be 2 sources (each
for 32bit default and 64bit default), but the runtime target dlls won't
get duplicated.
OK.
I tried fixing up libtool upstream to use w64 and w32 prefix instead
of lib prefix like the cygwin cyg prefix, but maintainers weren't
too welcoming of the idea.
Yeah, I can see that. I think ideally you'd want to leave -m32 alone,
but perhaps modify libtool to use a special prefix only for 64bit dlls.
Or maybe we could extend libtool to allow adding a _64 *suffix* prior
to the DLLNUM: libpng_64-12.dll. That'd be a bigger patch, tho.
As a final shortcut, you tweak both cygports to create
non-tc*-differentiated tarballs for the target runtime dlls to begin
with, so in the end, both cygports create
Good: pick one of each pair of these identically named tarballs.
mingw64-m64-libgcc1-VER-REL.tar.bz2 gen by -tc64- cygport
Re: [ITP] mingw-w64
On 6/30/2010 2:06 PM, JonY wrote: Thanks, I will check it out. (btw, libtool too needs to get an epoch version, having problems with macro version mismatches in gcc cygautoreconf). Oh boy. Yeah, I would imagine so. The gcc-tools-* stuff was added to support Dave Korn's needs when building the cygwin compilers, and since HE didn't need libtool, I didn't package it. I think there was some problem with trying to use full-up 'autoreconf' on the gcc tree, so Dave stuck with manually running the individual tools as needed, but I'm not sure about that. Let's see what suggestions Dave has. P.S. Hey, Yaakov -- any chance cygport could start supporting custom prefixes? Maybe by inheriting some special cygclass? Do also give the ability to tell cygport to exclude some libtool files from getting fixed up, thanks. Again, I *think* you can suppress this; I'll check tomorrow. -- Chuck
Re: [ITP] mingw-w64
On 6/29/2010 12:56, NightStrike wrote: On Mon, Jun 28, 2010 at 11:27 PM, JonYjo...@users.sourceforge.net wrote: 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/ Is FTP specifically required? Or can the files just be wget-able? Files do need to be wget-able, but FTP is not essential. With FTP, wget can walk through the directories recursively and grab the files without the need to specify each file link by hand.
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
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 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/
Re: [ITP] mingw-w64
On 6/27/2010 8:32 PM, JonY wrote: On 6/26/2010 19:59, JonY wrote: Hello, mingw-w64 (mingw-w64.sourceforge.net) is a toolchain to target 64bit windows. It is setup as a cygwin hosted cross compiler. Currently it is split into 4 packages: headers, crt, binutils and gcc. The latter 2 is from FSF. Does this version support multilib? that is, it's a cygwin hosted compiler targeting only -m64, or also -m32? If the latter, then...well, it's just good to know. GCC 4.6 (trunk) was chosen to avoid the ABI change from 4.5.0 biting users. LTO is also enabled. I would admit packaging could be a bit better, I'm open to suggestions for improvement. mingw-w64 headers: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-headers/w64-headers-20100625-1.tar.bz2 I know headers are, by definition, source, but I'm not sure if setup.exe's tiny little brain can grok a package like this, without a corresponding source. Should its setup.hint have an external-source: ??? record? I'm pretty sure all of the w64-gcc-??? language binary packages should have one, specifying w64-gcc as their source provider. And w64-gcc-rt is probably misnamed. If it contains the DLLs (like libgcc*.dll or whatever it is named, plus the corresponding DLLs for g++ fortran), they should be split up into separate libfoo packages. This makes representing dependency information for apps compiled using this compiler more granular. E.g. Consider regular cygwin gcc(4)'s runtime library packages: libgcc1 libstdc++6 libgfortran3 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 I'm anticipating at some point we'll have a mingw.org based (32bit only) cross compiler. We'll need it for some things, once gcc3 -mno-cygwin dies; and IIUC mingw64 won't be directly usable for those purposes because we'd end up with a mixture of windows headers; remember that cygwin itself uses the mingw.org headers. Anyway, the runtime libraries for THAT compiler's languages would probably be something like 'mingw32-libgcc1' (or even mingw-libgcc1, but that might be a bad/confusing choice given w64's presence). Dave K would be the person to chime in on that point, but AFAIK he's been AFK for over a week. I haven't had a chance to validate the packaging (e.g. build-from-source, etc) and probably won't until after the 4th. So...somebody else should probably do that. But I give it +1 for concept. (Actually, since Fedora ships the mingw64 compiler as their official windows cross compiler IIRC, we don't really need to vote.) -- Chuck
Re: [ITP] mingw-w64
On 6/28/2010 14:53, Charles Wilson wrote: On 6/27/2010 8:32 PM, JonY wrote: On 6/26/2010 19:59, JonY wrote: Hello, mingw-w64 (mingw-w64.sourceforge.net) is a toolchain to target 64bit windows. It is setup as a cygwin hosted cross compiler. Currently it is split into 4 packages: headers, crt, binutils and gcc. The latter 2 is from FSF. Does this version support multilib? that is, it's a cygwin hosted compiler targeting only -m64, or also -m32? If the latter, then...well, it's just good to know. Currently, its not setup to be multilib, but it is possible if you want. I fixed up the gcc install process to put target dlls in toolexeclibdir, libgcc_s*.dll still clash though, if installed without manual intervention. GCC 4.6 (trunk) was chosen to avoid the ABI change from 4.5.0 biting users. LTO is also enabled. I would admit packaging could be a bit better, I'm open to suggestions for improvement. mingw-w64 headers: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-headers/w64-headers-20100625-1.tar.bz2 I know headers are, by definition, source, but I'm not sure if setup.exe's tiny little brain can grok a package like this, without a corresponding source. Should its setup.hint have an external-source: ??? record? OK, I'll try to do that. I'm pretty sure all of the w64-gcc-??? language binary packages should have one, specifying w64-gcc as their source provider. And w64-gcc-rt is probably misnamed. If it contains the DLLs (like libgcc*.dll or whatever it is named, plus the corresponding DLLs for g++ fortran), they should be split up into separate libfoo packages. This makes representing dependency information for apps compiled using this compiler more granular. E.g. Consider regular cygwin gcc(4)'s runtime library packages: libgcc1 libstdc++6 libgfortran3 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 Ok, I'll split the DLLs.
Re: [ITP] mingw-w64
On 6/28/2010 15:16, JonY wrote: On 6/28/2010 14:53, Charles Wilson wrote: On 6/27/2010 8:32 PM, JonY wrote: On 6/26/2010 19:59, JonY wrote: Hello, mingw-w64 (mingw-w64.sourceforge.net) is a toolchain to target 64bit windows. It is setup as a cygwin hosted cross compiler. Currently it is split into 4 packages: headers, crt, binutils and gcc. The latter 2 is from FSF. Does this version support multilib? that is, it's a cygwin hosted compiler targeting only -m64, or also -m32? If the latter, then...well, it's just good to know. Currently, its not setup to be multilib, but it is possible if you want. I fixed up the gcc install process to put target dlls in toolexeclibdir, libgcc_s*.dll still clash though, if installed without manual intervention. GCC 4.6 (trunk) was chosen to avoid the ABI change from 4.5.0 biting users. LTO is also enabled. I would admit packaging could be a bit better, I'm open to suggestions for improvement. mingw-w64 headers: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-headers/w64-headers-20100625-1.tar.bz2 I know headers are, by definition, source, but I'm not sure if setup.exe's tiny little brain can grok a package like this, without a corresponding source. Should its setup.hint have an external-source: ??? record? OK, I'll try to do that. I'm pretty sure all of the w64-gcc-??? language binary packages should have one, specifying w64-gcc as their source provider. And w64-gcc-rt is probably misnamed. If it contains the DLLs (like libgcc*.dll or whatever it is named, plus the corresponding DLLs for g++ fortran), they should be split up into separate libfoo packages. This makes representing dependency information for apps compiled using this compiler more granular. E.g. Consider regular cygwin gcc(4)'s runtime library packages: libgcc1 libstdc++6 libgfortran3 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 Ok, I'll split the DLLs. Hi, now the packages are all prefixed with w64-mingw64 for 64bit and w32-mingw64 for 32bit. 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: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/ 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. 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. w64-mingw64-binutils: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-mingw64-binutils/w64-mingw64-binutils-2.20.51-1.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-mingw64-binutils/w64-mingw64-binutils-2.20.51-1-src.tar.bz2/download category: Devel requires: libgcc1 zlib0 sdesc: Bintils for Win64 target. ldesc: Cross bintils for Win64 and Win32 target.(Mulilib, 64bit default) w64-mingw64-headers: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-mingw64-headers/w64-mingw64-headers-20100628-1.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-mingw64-headers/w64-mingw64-headers-20100628-1-src.tar.bz2/download category: Devel requires: sdesc: Headers for Win64 target. ldesc: Mingw-w64 headers for Win64 target development. (Typo in setup.hint, headers should work for both Win32 and Win64) w64-mingw64-crt: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-mingw64-crt/w64-mingw64-crt-20100628-1.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-mingw64-crt/w64-mingw64-crt-20100628-1-src.tar.bz2/download category: Devel requires: sdesc: Libraries for Win64 target. ldesc: Mingw-w64 libraries for Win64 and Win32 target development. (Mulilib, 64bit default) GCC: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-mingw64-gcc4/w64-mingw64-gcc4-4.6.20100619-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-mingw64-gcc4/w64-mingw64-gcc4-4.6.20100619-1.tar.bz2/download category: Devel requires: libgcc1 libgmp3 libgmpxx4 libppl libmpc1
Re: [ITP] mingw-w64
On Mon, Jun 28, 2010 at 11:27 PM, JonY jo...@users.sourceforge.net wrote: 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/ Is FTP specifically required? Or can the files just be wget-able?
Re: [ITP] mingw-w64
On 6/27/2010 21:10, NightStrike wrote: On Sat, Jun 26, 2010 at 7:59 AM, JonYjo...@users.sourceforge.net wrote: mingw-w64 gcc-rt (runtime): https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-gcc/w64-gcc-rt/w64-gcc-rt-4.6.20100619-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-gcc/w64-gcc-rt/setup.hint setup.hint: category: Devel requires: sdesc: GCC for Win64 target (Win64 Runtime components). ldesc: Mingw-w64 GCC for Win64 target development (Win64 Runtime components). Should the gcc rt require the mingw-w64 crt? No, the DLLs do not need the link libs to be available. At least, that is how I interpret requires.
Re: [ITP] mingw-w64
On 6/26/2010 19:59, JonY wrote: Hello, mingw-w64 (mingw-w64.sourceforge.net) is a toolchain to target 64bit windows. It is setup as a cygwin hosted cross compiler. Currently it is split into 4 packages: headers, crt, binutils and gcc. The latter 2 is from FSF. GCC 4.6 (trunk) was chosen to avoid the ABI change from 4.5.0 biting users. LTO is also enabled. I would admit packaging could be a bit better, I'm open to suggestions for improvement. mingw-w64 headers: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-headers/w64-headers-20100625-1.tar.bz2 setup.hint: category: Devel requires: sdesc: Headers for Win64 target. ldesc: Mingw-w64 headers for Win64 target development. mingw-w64 crt: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-crt/w64-crt-20100625-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-crt/w64-crt-20100625-1-src.tar.bz2 setup.hint: ategory: Devel requires: sdesc: Libraries for Win64 target. ldesc: Mingw-w64 libraries for Win64 target development. mingw-w64 binutils: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-binutils/w64-binutils-2.20.51-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-binutils/w64-binutils-2.20.51-1-src.tar.bz2 setup.hint: category: Devel requires: libgcc1 zlib0 sdesc: Bintils for Win64 target. ldesc: Cross bintils for Win64 target. mingw-w64 gcc: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-gcc/w64-gcc-4.6.20100619-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-gcc/w64-gcc-4.6.20100619-1.tar.bz2 setup.hint: category: Devel requires: libgcc1 libgmp3 libgmpxx4 libppl libmpc1 libstdc++6 libcloog0 w64-headers w64-crt w64-binutils w64-gcc-runtime sdesc: GCC for Win64 target. ldesc: Mingw-w64 GCC for Win64 target development. Contains the base C compiler. mingw-w64 gcc-g++: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-gcc/w64-gcc-g%2B%2B/w64-gcc-g%2B%2B-4.6.20100619-1.tar.bz2 setup.hint: category: Devel requires: w64-gcc sdesc: GCC for Win64 target (C++ Frontend components). ldesc: Mingw-w64 GCC for Win64 target development (C++ Frontend components). mingw-w64 gcc-gfortran: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-gcc/w64-gcc-gfortran/w64-gcc-gfortran-4.6.20100619-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-gcc/w64-gcc-gfortran/setup.hint setup.hint: ategory: Devel requires: w64-gcc sdesc: GCC for Win64 target (Fotran Frontend components). ldesc: Mingw-w64 GCC for Win64 target development (Fortran Frontend components). mingw-w64 gcc-rt (runtime): https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-gcc/w64-gcc-rt/w64-gcc-rt-4.6.20100619-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-gcc/w64-gcc-rt/setup.hint setup.hint: category: Devel requires: sdesc: GCC for Win64 target (Win64 Runtime components). ldesc: Mingw-w64 GCC for Win64 target development (Win64 Runtime components). Ping.
