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.
