Re: co-maint for gcc
On 8/16/20 5:01 PM, Achim Gratz wrote: > > For the record: JonY has asked on IRC to get help with the release of > gcc-10 for Cygwin. I have built the compilers and are currently running > tests. I think I don't need to update binutils, but that is subject to > further discussion. I have not yet looked at the mingw64 cross > compilation toolchains, although these should eventually be updated too. > > > Regards, > Achim. > Thanks for taking up the offer. signature.asc Description: OpenPGP digital signature
Re: Update isl to 0.16.1?
On 09/28/2017 06:39 PM, Yaakov Selkowitz wrote: > On 2017-07-13 13:49, Achim Gratz wrote: >> Yaakov Selkowitz writes: >>> It looks like GCC 6 would benefit from an update of isl to 0.16.1 (but >>> NOT newer). This would be an ABI bump of libisl to 15, so existing GCC >>> 5 builds would not be affected, as long as we aren't planning any more >>> (and I sure hope we can move on at this point). Achim, if JonY agrees, >>> would you be able to bump this? >> >> If you've confirmed that this is the exact version gcc6 needs, then yes. >> Alternatively, Jon could take over the package to sync with any gcc >> updates, since I believe gcc is the only user anyway. > > JonY? > Sure, I don't mind taking over, and upgrade it as needed. signature.asc Description: OpenPGP digital signature
Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0
I suppose all mingw64-* except mingw64-*-binutils and mingw64-*-gcc. Let me know if I need to list them all down explicitly. signature.asc Description: OpenPGP digital signature
Re: mingw64-*-gcc-g++-4.9.2-1: Missing libatomic.a ?
On 1/14/2016 01:47, Christian Franke wrote: > The MinGW w64 g++ packages lack runtime support for std::atomic. > There is none, also, wrong list, please use the main list. signature.asc Description: OpenPGP digital signature
Re: GCC issue still here?
On 1/17/2015 06:43, Jean-Pierre Flori wrote: Dear all, I once again stumbled on issues reminding me of the ones mentioned here: http://trac.sagemath.org/ticket/15366 and here on the cygwin ml: http://cygwin.com/ml/cygwin/2013-08/msg00201.html http://cygwin.com/ml/cygwin/2013-07/msg00528.html Looking at the tickets on GCC tracker: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57680 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57982 and at the merged fix: https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=libgcc/config/i386/cygming-crtbegin.c;h=53909d2dc145b59958193dd9486b8b5fe01e9246;hp=c34178787c85aa1b980c25beb455d5e9c41d4614;hb=024d645a0db64ac79bdb6cda0339a3d4d26e288b;hpb=0b67965817647f9b73762e147ea125566ee0659d the fix looks slightly different, it does not deregister using the suggested condition... Would you say there still is a problem or should I look further into this? I don't think all the patches made it upstream. Does the same crash happen with 4.8.x? If not, some of the changes may have broke in 4.9.2. signature.asc Description: OpenPGP digital signature
Re: HEADSUP Maintainers: Stale packages on sourceware
On 10/29/2014 21:42, Yaakov Selkowitz wrote: Please find attached a list of old package tarballs which are not listed anywhere in setup.ini, meaning that they are not listed as a previous, current, or test package, and cannot be installed with setup. These files consume a total of over 1.3Gib. Do maintainers have any objections to these being removed? Yaakov Since you looked in the setup.hint, nope, go ahead and remove them. signature.asc Description: OpenPGP digital signature
SSH key for upload access
Name: Jonathan Yong Package: mingw64-i686-runtime SSHkey: ssh-rsa B3NzaC1yc2EDAQABAAACAQCoK9Z86SCD0EbsxFCsI458A97HruAghKeW9Raim+dCP0PyRv+94HmNKBb5eqBcYU/Hhm/LqyYKPYkvYjOaE2F1GrvgDA811BgHZkOyy4SfitkMWGLVLYIh1g2C3pntdz74fB5RemInLNQyTj4KRbDd4Pj94Wds+2zy+fKpa7CrY0N8Vp/o0aeSMWF4X3kFdCXXcPOEIzYkYyIpmT8x923hKOxWu+OxeVOE3U2xvHp8142LSndXMbHSzcolD0V5qqKpvCt76N2CFNZddV7DVAsNqFrul/sHHpEdcxjdxPWZ59g/VrzWejtt3S94wziSDgezx8l1KZCaKw9zmEBEbRymXR6nB06qrwjLlg9xCbtkbskn3YJJtUDuA4HeEK+kSXjOlFMjxovdrNIsfGXYsRK4imlIq7Cwb730iTBH71onSGviNBwLg62JHu/+qmgVlWBOJvV7NQtiKieB3jQwVJCFh2DkdNP5Aw/WoC2KtsqVjy8HilZR2lPmmPxYVz5SOU1/ISKOhKM4j8KqZlvNhq8rBv5zjIQeRlAwVo/yPk1JC4UeNzir++J5ioec0CGmOROmnbYmu/rl72m6j5hDv9s74WNTeGu9lL116kLDlKDasUKa1mvRjkOJEY4JiW0FPT8vluxSSkFC5WUSr2bCzFCjQdyV2h2Z6vjGtYHYKf93SQ== For sourceware signature.asc Description: OpenPGP digital signature
Re: Missing 64 bit packages
On 8/5/2013 17:25, Corinna Vinschen wrote: Hi folks, below's the latest list of packages yet mssing in the 64 bit distro. It got a bit shorter, but there's still a lot of stuff missing. I'll look into generating 64 bit packages for some of them as time permits, but it would be better if the real maintainer could do the job. There's also the problem of missing maintainers again. Some of the names in the below list didn't show up for a long time. Please guys, be so kind as to reply to this mail, so we can check if some packages are orphaned, or if you are just busy. Jon Y gendef libmangle lzip lziprecover Alright, will work on these soon. signature.asc Description: OpenPGP digital signature
[64bit] GCC 4.8.1-3 uploaded
Hi, GCC 4.8.3-1 uploaded to fix a bug in libgcc reported against a pythond crash. You may need rebuild your programs and library for it to take effect. signature.asc Description: OpenPGP digital signature
Re: [64bit] GCC 4.8.1-3 uploaded
On 7/28/2013 20:16, Ken Brown wrote: On 7/28/2013 7:04 AM, JonY wrote: Hi, GCC 4.8.3-1 uploaded to fix a bug in libgcc reported against a pythond crash. You may need rebuild your programs and library for it to take effect. Could you give a little more detail? How do maintainers know whether or not they need to rebuild their packages? If you use static libgcc, you should rebuild. If you use cyggcc_s dll, you should be safe after updating. signature.asc Description: OpenPGP digital signature
[64bit]
Uploaded: gcc-4.8.1-2 mingw64-i686-gcc-4.8.1-1 mingw64-x86_64-gcc-4.8.1-1 w32api-headers-3.0b_svn5962-1 w32api-runtime-3.0b_svn5962-1 mingw64-i686-headers-3.0b_svn5962-1 mingw64-x86_64-headers-3.0b_svn5962-1 mingw64-i686-runtime-3.0b_svn5962-1 mingw64-x86_64-runtime-3.0b_svn5962-1 mingw64-i686-pthreads-20100619-5 mingw64-x86_64-pthreads-20100619-5 mingw64-i686-winpthreads-3.0b_svn5935-1 mingw64-x86_64-winpthreads-3.0b_svn5935-1 w32api-runtime-3.0b_svn5962-1 has some issues, the libs got installed to /usr/lib64/w32api instead of /usr/lib/w32api. Please move it to the latter as a temporary workaround if you installed -1. -2 should be up now. signature.asc Description: OpenPGP digital signature
Re: [setup] KEY_WOW64_64KEY / KEY_WOW64_32KEY not defined
On 7/17/2013 03:47, Achim Gratz wrote: Corinna Vinschen writes: The mingw toolchain on a (32bit only) test machine at work still functions correctly, but the compilation aborts because KEY_WOW64_64KEY and KEY_WOW64_32KEY are not defined. Building with mingw.org toolchain isn't supported anymore. Use the Mingw-w64 toochain. Thanks, it is all clear now: installing the old mingw and mingw64 toolchains on the same installation somehow broke them both. For the mingw64 installation I was missing the header subpackage (this was what originally led me to try the old toolchain again). Last but not least I've linked /bin/cygmpc-1.dll - /bin/cygmpc-3.dll. I will be putting up the runtime -2 release, looks like the dependencies listing did went missing after I moved to the new style cygport. signature.asc Description: OpenPGP digital signature
Re: [64bit] mingw64-*
On 7/15/2013 17:21, Corinna Vinschen wrote: On Jul 14 10:41, JonY wrote: Hi, I noticed some area already there, may I take over? Any thoughts on w32api-* and gcc? Well, you're the maintainer... For gcc I suggest to work closely with Yaakov since we need the 4.8.1 gcc release for the 64 bit version. In theory, maybe you'd like to update the 32 bit version to 4.8.1 as well? 4.7 - 4.8 bump was pretty fast. Yaakov, are there any major issues with 4.8.x? if not, I'll look to bringing 4.8.x to 32bit soon. In the mean time, I'll update mingw64-* the next weekend. signature.asc Description: OpenPGP digital signature
[64bit] mingw64-*
Hi, I noticed some area already there, may I take over? Any thoughts on w32api-* and gcc? signature.asc Description: OpenPGP digital signature
Re: *** setup.ini: warning - package mingw64-i686-gcc-core requires non-existent package mingw64-i686-winpthreads
On 7/11/2013 06:19, JonY wrote: OK, uploading to home directory first. OK, upload complete in $HOME/up. Can I move it now? signature.asc Description: OpenPGP digital signature
Re: *** setup.ini: warning - package mingw64-i686-gcc-core requires non-existent package mingw64-i686-winpthreads
On 7/10/2013 07:06, Christopher Faylor wrote: On Wed, Jul 10, 2013 at 06:11:42AM +0800, JonY wrote: On 7/10/2013 03:45, Christopher Faylor wrote: I changed mingw64-i686-winpthreads to mingw64-i686-pthreads in mingw64-i686-gcc-core's setup.hint. No wrong, it is winpthreads, the upload is still in progress. I don't have fast upload speeds. Bzzt. Wrong answer. You don't install a package with a nonexistent dependency. You broke setup.ini generation for hours. Your upload speeds have nothing to do with this. You should install the packages all at the same time, not piecemeal. As I have said, it is still uploading, at 15KB/s, continuously since 2 days ago, it is not done piecemeal, but yes, I should have uploaded winpthreads first. signature.asc Description: OpenPGP digital signature
Re: *** setup.ini: warning - package mingw64-i686-gcc-core requires non-existent package mingw64-i686-winpthreads
On 7/10/2013 18:06, Chris Sutcliffe wrote: On 10 July 2013 05:51, JonY wrote: On 7/10/2013 07:06, Christopher Faylor wrote: Bzzt. Wrong answer. You don't install a package with a nonexistent dependency. You broke setup.ini generation for hours. Your upload speeds have nothing to do with this. You should install the packages all at the same time, not piecemeal. As I have said, it is still uploading, at 15KB/s, continuously since 2 days ago, it is not done piecemeal, but yes, I should have uploaded winpthreads first. Perhaps (for next time) upload to a staging area (I believe cgf has in the past mentioned using the home directories on sourceware), then when the upload is complete, move the files to the appropriate directory? This would avoid the problems being reported with setup.exe I believe. I don't think I have shell access to move the files after upload is completed, unless there is some way else that I am not aware of. Can you do that with scp? signature.asc Description: OpenPGP digital signature
Re: *** setup.ini: warning - package mingw64-i686-gcc-core requires non-existent package mingw64-i686-winpthreads
On 7/10/2013 22:31, Christopher Faylor wrote: You have login access to sourceware. I try to edit the welcome message when I provide login access but I apparently forgot to do so in your case. I would have thought that since Corinna specifically mentioned that we were giving you login access and since you can use scp to copy and since I have told you REPEATEDLY to use your home directory for staging you might have, you know, USED YOUR HOME DIRECTORY FOR STAGING. What in the world are you thinking? YOU CAN'T BREAK THE CYGWIN INSTALLATION FOR DAYS. It is completely unacceptable to tell people to check back in a day or two if they want a sane Cygwin installation. OK, uploading to home directory first. signature.asc Description: OpenPGP digital signature
Re: *** setup.ini: warning - package mingw64-i686-gcc-core requires non-existent package mingw64-i686-winpthreads
On 7/10/2013 03:45, Christopher Faylor wrote: I changed mingw64-i686-winpthreads to mingw64-i686-pthreads in mingw64-i686-gcc-core's setup.hint. No wrong, it is winpthreads, the upload is still in progress. I don't have fast upload speeds. signature.asc Description: OpenPGP digital signature
Re: [itp] mingw64-{i686,x86_64}-winpthreads-3.0b_svn5935-1
On 7/7/2013 18:48, JonY wrote: Hi, This is the new pthreads implementation from mingw-w64, it will obsolete the pthreads-win32 package. The final release for pthreads-win32 will now only contain the DLL without any headers/libraries to link against, for compatibility sake. Since the mingw-w64-headers package has a few stub headers replaced by winpthreads, I made winpthreads a requirement to the headers package, so the files don't conflict. Here's the setup.hint file for 32bit and 64bit respectively. category: Devel requires: sdesc: MinGW-w64 Win32 POSIX threads ldesc: MinGW-w64 runtime headers for Win32 32bit target category: Devel requires: sdesc: MinGW-w64 Win32 POSIX threads ldesc: MinGW-w64 runtime headers for Win32 64bit target Here are the files: http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/mingw64-i686-winpthreads-3.0b_svn5935-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/mingw64-i686-winpthreads-3.0b_svn5935-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/mingw64-i686-winpthreads-debuginfo/mingw64-i686-winpthreads-debuginfo-3.0b_svn5935-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/mingw64-i686-winpthreads-debuginfo/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/mingw64-x86_64-winpthreads-3.0b_svn5935-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/mingw64-x86_64-winpthreads-3.0b_svn5935-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/mingw64-x86_64-winpthreads-debuginfo/mingw64-x86_64-winpthreads-debuginfo-3.0b_svn5935-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/mingw64-x86_64-winpthreads-debuginfo/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/setup.hint Everything OK? Ping. signature.asc Description: OpenPGP digital signature
Re: [itp] mingw64-{i686,x86_64}-winpthreads-3.0b_svn5935-1
On 7/9/2013 06:10, JonY wrote: Here are the files: http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/mingw64-i686-winpthreads-3.0b_svn5935-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/mingw64-i686-winpthreads-3.0b_svn5935-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/mingw64-i686-winpthreads-debuginfo/mingw64-i686-winpthreads-debuginfo-3.0b_svn5935-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/mingw64-i686-winpthreads-debuginfo/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/mingw64-x86_64-winpthreads-3.0b_svn5935-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/mingw64-x86_64-winpthreads-3.0b_svn5935-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/mingw64-x86_64-winpthreads-debuginfo/mingw64-x86_64-winpthreads-debuginfo-3.0b_svn5935-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/mingw64-x86_64-winpthreads-debuginfo/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/setup.hint Everything OK? Fixed the setup.hint descriptions. Sorry, copy paste typo. Files at same URL. category: Devel requires: sdesc: MinGW-w64 Win32 POSIX threads ldesc: MinGW-w64 POSIX threads for Win32 64bit target category: Devel requires: sdesc: MinGW-w64 Win32 POSIX threads ldesc: MinGW-w64 runtime headers for Win32 64bit target signature.asc Description: OpenPGP digital signature
[itp] mingw64-{i686,x86_64}-winpthreads-3.0b_svn5935-1
Hi, This is the new pthreads implementation from mingw-w64, it will obsolete the pthreads-win32 package. The final release for pthreads-win32 will now only contain the DLL without any headers/libraries to link against, for compatibility sake. Since the mingw-w64-headers package has a few stub headers replaced by winpthreads, I made winpthreads a requirement to the headers package, so the files don't conflict. Here's the setup.hint file for 32bit and 64bit respectively. category: Devel requires: sdesc: MinGW-w64 Win32 POSIX threads ldesc: MinGW-w64 runtime headers for Win32 32bit target category: Devel requires: sdesc: MinGW-w64 Win32 POSIX threads ldesc: MinGW-w64 runtime headers for Win32 64bit target Here are the files: http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/mingw64-i686-winpthreads-3.0b_svn5935-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/mingw64-i686-winpthreads-3.0b_svn5935-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/mingw64-i686-winpthreads-debuginfo/mingw64-i686-winpthreads-debuginfo-3.0b_svn5935-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/mingw64-i686-winpthreads-debuginfo/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-i686-winpthreads/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/mingw64-x86_64-winpthreads-3.0b_svn5935-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/mingw64-x86_64-winpthreads-3.0b_svn5935-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/mingw64-x86_64-winpthreads-debuginfo/mingw64-x86_64-winpthreads-debuginfo-3.0b_svn5935-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/mingw64-x86_64-winpthreads-debuginfo/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads/setup.hint Everything OK? signature.asc Description: OpenPGP digital signature
Re: Preparation for gcc 4.7.3-1
On 6/24/2013 13:44, Yaakov (Cygwin/X) wrote: On 2013-06-19 18:15, JonY wrote: I see, should have uploaded the earlier version from your cygport. I am uploading it now and should take a day or so to complete. Hopefully, my internet connection doesn't die when I'm away. Ping? Hi, The upload should be complete last week. signature.asc Description: OpenPGP digital signature
Re: Preparation for gcc 4.7.3-1
On 6/20/2013 13:46, Christopher Faylor wrote: On Thu, Jun 20, 2013 at 06:18:23AM +0800, JonY wrote: On 6/19/2013 07:39, Yaakov (Cygwin/X) wrote: On 2013-06-18 17:32, JonY wrote: On 6/19/2013 06:17, Yaakov (Cygwin/X) wrote: As for the logistics, how about you put this in a temporary location (not under release) that I can access, and then I can deal with all the necessary transitioning. Where do I put the files at? /sourceware/cygwin-gcc/ sounds OK? You can put them in your HOME (or a subdirectory thereof). I put the upload at /sourceware1/home/jyong/gcc-new, but cgf says I shouldn't be using the home directory. It seems to be world readable though. I told you to use your home directory on irc. We had a discussion about this in this mailing list a few weeks ago. You should not be creating directories outside of your home directory. Isn't that in the home directory? signature.asc Description: OpenPGP digital signature
Re: Preparation for gcc 4.7.3-1
On 6/29/2013 19:10, marco atzeri wrote: Il 6/29/2013 1:03 PM, JonY ha scritto: On 6/20/2013 13:46, Christopher Faylor wrote: On Thu, Jun 20, 2013 at 06:18:23AM +0800, JonY wrote: On 6/19/2013 07:39, Yaakov (Cygwin/X) wrote: On 2013-06-18 17:32, JonY wrote: On 6/19/2013 06:17, Yaakov (Cygwin/X) wrote: As for the logistics, how about you put this in a temporary location (not under release) that I can access, and then I can deal with all the necessary transitioning. Where do I put the files at? /sourceware/cygwin-gcc/ sounds OK? You can put them in your HOME (or a subdirectory thereof). I put the upload at /sourceware1/home/jyong/gcc-new, but cgf says I shouldn't be using the home directory. It seems to be world readable though. I told you to use your home directory on irc. We had a discussion about this in this mailing list a few weeks ago. You should not be creating directories outside of your home directory. Isn't that in the home directory? I would say yes I see, FileZilla client probably likes to use pwd or realpath $PWD to find the working dir. signature.asc Description: OpenPGP digital signature
Re: Preparation for gcc 4.7.3-1
On 6/19/2013 07:39, Yaakov (Cygwin/X) wrote: On 2013-06-18 17:32, JonY wrote: On 6/19/2013 06:17, Yaakov (Cygwin/X) wrote: As for the logistics, how about you put this in a temporary location (not under release) that I can access, and then I can deal with all the necessary transitioning. Where do I put the files at? /sourceware/cygwin-gcc/ sounds OK? You can put them in your HOME (or a subdirectory thereof). Hi, I put the upload at /sourceware1/home/jyong/gcc-new, but cgf says I shouldn't be using the home directory. It seems to be world readable though. I still build gcc with the -4 suffix, but it no longer does the gcc alternative switch. The next version should remove those. I'll be out until July, so I can't do much until then. I hope I built gcc correctly. Please wrap up for me, thanks. signature.asc Description: OpenPGP digital signature
Re: Preparation for gcc 4.7.3-1
On 6/20/2013 06:47, Yaakov (Cygwin/X) wrote: On 2013-06-19 17:18, JonY wrote: I still build gcc with the -4 suffix, but it no longer does the gcc alternative switch. The next version should remove those. That's not going to work. With the -4 suffix but without the symlinks, this will never be found as *the* gcc/g++/etc. We have already agreed to make this unversioned and remove 3.x, so there's really no reason not to do so now (as in my cygport(5)). I see, should have uploaded the earlier version from your cygport. I am uploading it now and should take a day or so to complete. Hopefully, my internet connection doesn't die when I'm away. signature.asc Description: OpenPGP digital signature
Re: Preparation for gcc 4.7.3-1
On 6/18/2013 06:21, JonY wrote: Sounds doable? Alternatively, the current experimental gcc 4.7.2 and its dep be made stable before 4.7.3 is pushed, after all, I did use 4.7.2 to build the new gcc, it is stable enough. Doable? Hey, can you guys decide? I'll be off in a few days until July. signature.asc Description: OpenPGP digital signature
Re: Preparation for gcc 4.7.3-1
On 6/18/2013 19:27, Corinna Vinschen wrote: Whom are you asking? Not me, I hope. If so, whatever you guys think is right, is right, as long as gcc just works and the Cygwin DLL builds. As a sidepoint, you won't get as much testing as you like as long as the stuff is in test. Most people don't install test versions anyway. If 4.7.3 is to be considered stable, I need all the cooperation from all the gcc deps maintainers, clearly gcc-4.7.2 experimental is stable enough since I am able to build 4.7.3 with it. All the new ppl/mpc/mpfr/gmp that were marked experimental needs to be switched to stable at the same time gcc-4.7.x or else gcc would be broken for awhile without those DLLs. signature.asc Description: OpenPGP digital signature
Re: Preparation for gcc 4.7.3-1
On 6/19/2013 06:17, Yaakov (Cygwin/X) wrote: As for the logistics, how about you put this in a temporary location (not under release) that I can access, and then I can deal with all the necessary transitioning. Where do I put the files at? /sourceware/cygwin-gcc/ sounds OK? signature.asc Description: OpenPGP digital signature
Re: Preparation for gcc 4.7.3-1
On 6/17/2013 06:24, JonY wrote: Oops, sorry dropped the list. On 6/17/2013 00:48, Yaakov (Cygwin/X) wrote: On 2013-06-16 06:48, JonY wrote: I noticed some deps are still marked as experimental, eg cloog/ppl/mpc/mpfr/gmp. Parts of the experimental ppl even requires experimental 4.7.x libstdc++. For gcc-4.7, we need the test versions of all those deps. setup constantly tries to revert it to stable versions. That's just how setup (mis)handles test releases. Should I still put gcc 4.7.3-1 as experimental? No, I think we just need to stabilize it and its deps, obsoleting 'gcc4', 'gcc' 3.x and 'gcc-mingw-' in the process. gcc4? Anyway, like Achim says, I was thinking to push to experimental. Once upload is complete, someone will change the setup.hint files, gcc and its deps over to stable, so there won't be any gaps when gcc install will potentially be broken. For the record, here are the deps stated by cygport: On 6/17/2013 00:48, Yaakov (Cygwin/X) wrote: gcc requires: gcc-core gcc-g++ gcc-core requires: bash libcloog0 libgcc1 libgmp3 libgomp1 libiconv2 libintl8 libmpc3 libmpfr4 libppl_c4 libquadmath0 libssp0 zlib0 binutils w32api-headers w32api-runtime gcc-g++ requires: libcloog0 libgmp3 libiconv2 libintl8 libmpc3 libmpfr4 libppl_c4 libstdc++6 python python3 zlib0 gcc-core gcc-java requires: bash libcloog0 libgcc1 libgcj13 libgmp3 libiconv2 libintl8 libmpc3 libmpfr4 libppl_c4 python python3 zlib0 gcc-core java-ecj gcc-fortran requires: libcloog0 libgfortran3 libgmp3 libiconv2 libintl8 libmpc3 libmpfr4 libppl_c4 zlib0 gcc-core gcc-objc requires: libcloog0 libgmp3 libiconv2 libintl8 libmpc3 libmpfr4 libobjc4 libppl_c4 zlib0 gcc-core gcc-objc++ requires: libcloog0 libgmp3 libiconv2 libintl8 libmpc3 libmpfr4 libppl_c4 zlib0 gcc-core gcc-g++ gcc-objc gcc-ada requires: libcloog0 libgmp3 libiconv2 libintl8 libmpc3 libmpfr4 libppl_c4 zlib0 gcc-core libgcc1 requires: libgomp1 requires: libgcc1 libssp0 requires: libgfortran3 requires: libgcc1 libquadmath0 libgcj-common requires: libobjc4 requires: libgcc1 libstdc++6 requires: libgcc1 libstdc++6-devel requires: libgnat4.7 requires: libgcc1 libgcj13 requires: libgcc1 libiconv2 zlib0 libgcj-common libquadmath0 requires: libgcc1 Sounds doable? Alternatively, the current experimental gcc 4.7.2 and its dep be made stable before 4.7.3 is pushed, after all, I did use 4.7.2 to build the new gcc, it is stable enough. Doable? signature.asc Description: OpenPGP digital signature
Preparation for gcc 4.7.3-1
Hi, I noticed some deps are still marked as experimental, eg cloog/ppl/mpc/mpfr/gmp. Parts of the experimental ppl even requires experimental 4.7.x libstdc++. setup constantly tries to revert it to stable versions. Should I still put gcc 4.7.3-1 as experimental? signature.asc Description: OpenPGP digital signature
Cygwin libtool update
Hi Charles, Care to put up 2.4.2? It's been out for some time now. Thanks. signature.asc Description: OpenPGP digital signature
Re: GCC 4.7.3 stabilization
On 5/27/2013 10:52, Yaakov (Cygwin/X) wrote: Dave, It's been a month since we last discussed the GCC upgrade. What, if anything, is holding up a stable 4.7.3? Dave, ping. signature.asc Description: OpenPGP digital signature
Re: [ITP] mingw64-x86_64-winpthreads 3.0b_svn5726-1
On 4/9/2013 06:17, JonY wrote: On 4/9/2013 03:58, Charles Wilson wrote: Yes. I'm not sure how that should be handled. If you want to force the switch, for that particular toolchain, then the cygwin package of the mingw-w64-headers for that toolchain should probably stop shipping those files, so that the (new) winpthreads package for that toolchain can start shipping them. If you DON'T want to force the switch, then...? Use the alternatives framework for those particular headers? Good point, I'll simply remove the headers on my next header/CRT refresh if I ship winpthreads. It's not something that can be switched easily as it changes the underlying libgomp ABI, requiring GCC to be recompiled to work with pthreads-win32. Uploaded mingw64-x86_64-winpthreads-3.0b_svn5726-1, along with mingw64-x86_64-gcc-4.8-20130310-2. The new GCC is a rebuild of the -1, with dependency on winpthreads. I plan to make a new mingw-w64-headers/crt release in the near future and fix the conflicts. For now, these will suffice. New mingw-w64-headers/crt for 32bit cygwin next weekend, and maybe for the 64bit cygwin too if I get enough time. signature.asc Description: OpenPGP digital signature
Re: [ITP] mingw64-x86_64-winpthreads 3.0b_svn5726-1
On 4/8/2013 15:57, Corinna Vinschen wrote: On Apr 7 17:47, JonY wrote: winpthreads is a pthreads implementation from mingw-w64. The ABI is incompatible with pthreads-win32. One of the major differences is that winpthreads uses scalar handles, so it is a bit more compatible to other packages that assume int type handles. I have successfully built the 64bit cross compiler for cygwin64. There are no changes to the -1 release other than some .cygport modifications. For now, I intend to push it to 64bit Cygwin only, once gcc 4.7 for the 32bit cygwin hits release, I will push it there too. There are some files in the package that replaces some of the mingw-w64-headers CRT headers, this is done on purpose. will cygcheck/setup have any issues? Since it is not in any major distros, I guess it will have to go through a vote. Isn't that rather just a necessary library extensions to the cross toolchain? I'm not so sure we really need a vote here. Feel free to upload. Btw., would you mind to release new 32 bit w32api headers and runtime? The latest changes to include the intrinsics in kernel32.a were pretty important fixes for the Cygwin toolchain I think. OK, I'll only be free to do it this weekend though. signature.asc Description: OpenPGP digital signature
Re: [ITP] mingw64-x86_64-winpthreads 3.0b_svn5726-1
On 4/9/2013 03:58, Charles Wilson wrote: Yes. I'm not sure how that should be handled. If you want to force the switch, for that particular toolchain, then the cygwin package of the mingw-w64-headers for that toolchain should probably stop shipping those files, so that the (new) winpthreads package for that toolchain can start shipping them. If you DON'T want to force the switch, then...? Use the alternatives framework for those particular headers? Good point, I'll simply remove the headers on my next header/CRT refresh if I ship winpthreads. It's not something that can be switched easily as it changes the underlying libgomp ABI, requiring GCC to be recompiled to work with pthreads-win32. signature.asc Description: OpenPGP digital signature
[ITP] mingw64-x86_64-winpthreads 3.0b_svn5726-1
winpthreads is a pthreads implementation from mingw-w64. The ABI is incompatible with pthreads-win32. One of the major differences is that winpthreads uses scalar handles, so it is a bit more compatible to other packages that assume int type handles. I have successfully built the 64bit cross compiler for cygwin64. There are no changes to the -1 release other than some .cygport modifications. For now, I intend to push it to 64bit Cygwin only, once gcc 4.7 for the 32bit cygwin hits release, I will push it there too. There are some files in the package that replaces some of the mingw-w64-headers CRT headers, this is done on purpose. will cygcheck/setup have any issues? Since it is not in any major distros, I guess it will have to go through a vote. setup.hint: category: Devel requires: sdesc: winpthreads for MinGW-w64 (64bit) toolchain ldesc: winpthreads (pthreads) for MinGW-w64 (64bit) target. signature.asc Description: OpenPGP digital signature
Re: [ITP] mingw64-x86_64-winpthreads 3.0b_svn5726-1
On 4/7/2013 17:47, JonY wrote: winpthreads is a pthreads implementation from mingw-w64. The ABI is incompatible with pthreads-win32. One of the major differences is that winpthreads uses scalar handles, so it is a bit more compatible to other packages that assume int type handles. I have successfully built the 64bit cross compiler for cygwin64. There are no changes to the -1 release other than some .cygport modifications. For now, I intend to push it to 64bit Cygwin only, once gcc 4.7 for the 32bit cygwin hits release, I will push it there too. There are some files in the package that replaces some of the mingw-w64-headers CRT headers, this is done on purpose. will cygcheck/setup have any issues? Since it is not in any major distros, I guess it will have to go through a vote. setup.hint: category: Devel requires: sdesc: winpthreads for MinGW-w64 (64bit) toolchain ldesc: winpthreads (pthreads) for MinGW-w64 (64bit) target. Oops, forgot to include link. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads-3.0b_svn5726-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads-3.0b_svn5726-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads-debuginfo/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/mingw64-x86_64-winpthreads-debuginfo/mingw64-x86_64-winpthreads-debuginfo-3.0b_svn5726-1.tar.bz2 signature.asc Description: OpenPGP digital signature
Re: new 64 bit w32api packages
On 4/5/2013 20:00, Corinna Vinschen wrote: Hi guys, I just uploaded new 64 bit w32api-headers and w32api-runtime packages along the lines of JonY's 32 bit packages, but with new cygport description files which allow building and installing the stuff with the 64 bit Cygwin compiler as well. I have just applied a patch to the mingw-w64 upstream repo, which was necessary to get this running on 64 bit. This should fix the broken dependencies when installing the 64 bit gcc. The w32api package I created before is now obsoleted. The cross compilers? I was about to make a new gcc release with winpthreads/openMP this weekend, can I still go forwards with it? signature.asc Description: OpenPGP digital signature
Re: new 64 bit w32api packages
On 4/6/2013 00:31, Corinna Vinschen wrote:
On Apr 6 00:26, JonY wrote:
On 4/5/2013 20:00, Corinna Vinschen wrote:
Hi guys,
I just uploaded new 64 bit w32api-headers and w32api-runtime packages
along the lines of JonY's 32 bit packages, but with new cygport
description files which allow building and installing the stuff with
the 64 bit Cygwin compiler as well. I have just applied a patch to
the mingw-w64 upstream repo, which was necessary to get this running
on 64 bit. This should fix the broken dependencies when installing
the 64 bit gcc. The w32api package I created before is now obsoleted.
The cross compilers? I was about to make a new gcc release with
winpthreads/openMP this weekend, can I still go forwards with it?
I don't understand the question. Can you elaborate a bit?
I was planning to use winpthreads instead of pthreadGC2.dll for the
{i686,x86_64}-w64-mingw32 cross compilers, the pthread API is supposed
to be compatible but ABI is different. Is that still OK to go forwards
with? libgomp openMP in gcc particularly uses it.
Originally, I was waiting for gcc 4.7.x in 32bit cygwin to be released
before breaking ABI, but 64bit cygwin still does not have a big user
base so changing ABI is going to be less disruptive there.
signature.asc
Description: OpenPGP digital signature
Re: new 64 bit w32api packages
On 4/6/2013 06:50, JonY wrote:
On 4/6/2013 00:31, Corinna Vinschen wrote:
On Apr 6 00:26, JonY wrote:
On 4/5/2013 20:00, Corinna Vinschen wrote:
Hi guys,
I just uploaded new 64 bit w32api-headers and w32api-runtime packages
along the lines of JonY's 32 bit packages, but with new cygport
description files which allow building and installing the stuff with
the 64 bit Cygwin compiler as well. I have just applied a patch to
the mingw-w64 upstream repo, which was necessary to get this running
on 64 bit. This should fix the broken dependencies when installing
the 64 bit gcc. The w32api package I created before is now obsoleted.
The cross compilers? I was about to make a new gcc release with
winpthreads/openMP this weekend, can I still go forwards with it?
I don't understand the question. Can you elaborate a bit?
I was planning to use winpthreads instead of pthreadGC2.dll for the
{i686,x86_64}-w64-mingw32 cross compilers, the pthread API is supposed
to be compatible but ABI is different. Is that still OK to go forwards
with? libgomp openMP in gcc particularly uses it.
Originally, I was waiting for gcc 4.7.x in 32bit cygwin to be released
before breaking ABI, but 64bit cygwin still does not have a big user
base so changing ABI is going to be less disruptive there.
Now that I reread the your original message, looks like I was jumping to
conclusions. Your update was just about the win32api, not the mingw-w64
cross compilers.
Anyway, I'm working on the new mingw-w64 cross compilers that uses
winpthreads instead of pthreads-win32, do voice out if there are any
concerns.
signature.asc
Description: OpenPGP digital signature
Re: Maintainers please weigh in on 64-bit Cygwin
On 3/18/2013 00:45, Christopher Faylor wrote: I'd like to have a feel for how the 64-bit version of Cygwin will impact package maintainers. So, I'd appreciate some discussion about this. 1) Do you have a 64-bit version of Windows available? Yes. 2) If no, would you be willing to install one? N/A. 3) Are you willing to download the current 64-bit Cygwin and start porting your stuff, knowing that there are still bugs? Yes. 4) Or, would you rather wait for 64-bit to be completely stable before attempting anything? N/A. 5) Does the existence of two different architectures make you think that it is time for you to stop offering the package? No. 6) Would you be willing to have another person doing the 64-bit port for you? No. 7) Are you ok with a 64-bit alpha release being made available which contains your packages built by someone else? No. signature.asc Description: OpenPGP digital signature
Re: Anyone know who copied a rogue binutils package to the release?
On 3/7/2013 03:14, Christopher Faylor wrote: On Wed, Mar 06, 2013 at 11:54:21AM -0500, Christopher Faylor wrote: There was a cygport themed binutils in the release area. Anyone know who put it there? Wow. Strange delay there. I thought this message had disappeared into the ether. Sorry, I uploaded it as I thought it was also done by Dave. I asked over IRC if I should remove it, but got no response. Well, since it is breaking things, go ahead and remove it. Anyway, gcc 4.7.2 may need a binutils update, so care to bump it? Thanks. signature.asc Description: OpenPGP digital signature
Re: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj
On 3/4/2013 16:34, Yaakov (Cygwin/X) wrote: On Fri, 01 Mar 2013 06:10:19 +0800, JonY wrote: On 3/1/2013 03:42, Yaakov (Cygwin/X) wrote: On Thu, 28 Feb 2013 11:14:22 -0500, Christopher Faylor wrote: Could someone fix this please? I removed the require for the moment, but the proper solution is to provide the jar in the distro. If you want, I could do that in a way that doesn't require pulling in the entire GNU Classpath environment from Ports. Strange, I don't remember adding that requirement into Dave's hint files. I'll make a test announcement later today. They were already there because he copied them from Ports, which does provide a java-ecj package. It was there all these while and nobody noticed until now? BTW, I think I found the problem with building libjava; I'm juggling a lot of projects right now, but I should be able to post an updated .cygport and patchset soon. Cool, thanks a bunch. I wasn't too sure what those register threads were. GCJ for windows and Cygwin is in poor shape. signature.asc Description: OpenPGP digital signature
Re: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj
On 3/1/2013 03:42, Yaakov (Cygwin/X) wrote: On Thu, 28 Feb 2013 11:14:22 -0500, Christopher Faylor wrote: Could someone fix this please? I removed the require for the moment, but the proper solution is to provide the jar in the distro. If you want, I could do that in a way that doesn't require pulling in the entire GNU Classpath environment from Ports. Strange, I don't remember adding that requirement into Dave's hint files. I'll make a test announcement later today. signature.asc Description: OpenPGP digital signature
Re: GCC maintainer volunteer?
On 2/25/2013 22:40, JonY wrote: On 2/24/2013 12:55, Christopher Faylor wrote: On Sun, Feb 24, 2013 at 10:01:56AM +0800, JonY wrote: On 2/24/2013 09:39, Ken Brown wrote: But isn't all this irrelevant for you? There's no reason to keep gcc3 around anymore, is there? I don't know, I'll leave that to the core Cygwin devs to decide. I'd be happy to get rid of it but don't people still use it? We can't have the gcc4 package overwriting someone's gcc3 if so. OK. Anyway, packaging is taking longer than expected, still working on packaging bugs. I'm thinking of releasing a test version without Java, not all the patches have been integrated yet. I now have gcc4-4.7.2-1 built with all the patches integrated but Java doesn't build, it is a separate issue. I'm hesitant to push it directly to the download servers, might break things. I've put the following in the hits file: curr: 4.5.3-3 prev: 4.3.4-4 test: 4.7.2-1 Any staging areas or advice? signature.asc Description: OpenPGP digital signature
Re: GCC maintainer volunteer?
On 2/27/2013 21:10, Corinna Vinschen wrote Just upload the test release to the release area and write a TEST mail to cygwin-announce. Or is there anything special you'd like to do? I'm worried that I might break gcc installs if I overlooked something obvious. The upload will be overwriting the .hint files, java and libffi are empty packages (I could not get java to build yet). I can't figure out how to pack the debuginfo package, it is always empty. Will you be able to rollback my uploads in case something does go wrong? signature.asc Description: OpenPGP digital signature
Re: GCC maintainer volunteer?
On 2/27/2013 21:59, Corinna Vinschen wrote: On Feb 27 21:29, JonY wrote: On 2/27/2013 21:10, Corinna Vinschen wrote Just upload the test release to the release area and write a TEST mail to cygwin-announce. Or is there anything special you'd like to do? I'm worried that I might break gcc installs if I overlooked something obvious. The upload will be overwriting the .hint files, java and libffi are empty packages (I could not get java to build yet). I'm not concerend about java (dum di dum), but why is libffi missing? libffi only gets built when Java is enabled. I can't figure out how to pack the debuginfo package, it is always empty. Yaakov might be able to help here. Hi Yaakov, I have gcc4_debuginfo_CONTENTS=usr/lib/debug/ in the cygport file, any ideas? Will you be able to rollback my uploads in case something does go wrong? In theory, yes. If you leave the dependencies in place for the curr release, then the test release shouldn't interfere and testers will have to care for the stuff themselves. Let's assume for a start, that downmloaders of a gcc test package know what they are doing. Now this brings up a good question. libgnat4.5 became libgnat4.7 in 4.7.2, likewise for libobjc2 to libobjc4. So you are saying that I should leave the runtime depends for 4.5.x? Another way to distinguish the new gcc from the current on would be perhaps to create a gcc472 package set, distinct from the other gcc packages. It could install itself into /usr/local, just for the test period. Yeah, I know, I know, no official package should install into /usr/local. Maybe /opt would be fine for once, too. That might be a saner approach to testing. Do I need to use postinstall to add it to PATH? If so, how do I do that? signature.asc Description: OpenPGP digital signature
Re: GCC maintainer volunteer?
On 2/24/2013 12:55, Christopher Faylor wrote: On Sun, Feb 24, 2013 at 10:01:56AM +0800, JonY wrote: On 2/24/2013 09:39, Ken Brown wrote: But isn't all this irrelevant for you? There's no reason to keep gcc3 around anymore, is there? I don't know, I'll leave that to the core Cygwin devs to decide. I'd be happy to get rid of it but don't people still use it? We can't have the gcc4 package overwriting someone's gcc3 if so. OK. Anyway, packaging is taking longer than expected, still working on packaging bugs. I'm thinking of releasing a test version without Java, not all the patches have been integrated yet. signature.asc Description: OpenPGP digital signature
Re: GCC maintainer volunteer?
I feel I am missing something obvious here. Dave's cygport references set-gcc-default-3.sh and set-gcc-default-4.sh but never creates them... I'll probably upload an experimental version soon-ish, once I can figure out how the packaging work. signature.asc Description: OpenPGP digital signature
Re: GCC maintainer volunteer?
On 2/23/2013 23:45, Ken Brown wrote: On 2/23/2013 10:04 AM, JonY wrote: I feel I am missing something obvious here. Dave's cygport references set-gcc-default-3.sh and set-gcc-default-4.sh but never creates them... They're created when gcc4-4.5.3-3.cygwin.patch is applied. After that, how does it get installed? cygport install package did not seem to package it. signature.asc Description: OpenPGP digital signature
Re: GCC maintainer volunteer?
On 2/24/2013 09:39, Ken Brown wrote: But isn't all this irrelevant for you? There's no reason to keep gcc3 around anymore, is there? I don't know, I'll leave that to the core Cygwin devs to decide. signature.asc Description: OpenPGP digital signature
Re: GCC maintainer volunteer?
On 2/22/2013 15:00, Yaakov (Cygwin/X) wrote: On Thu, 21 Feb 2013 17:59:07 +0100, Corinna Vinschen wrote: Exactly. The question is then, what patches from the 4.5.3 gcc were not applied upstream and still make sense today. I have a copy of the patchset here with a few additions of my own: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc4;a=tree classpath-0.98-*.patch: patches carried over from my port of GNU Classpath; these are required. Only classpath-0.98-build.patch applies. config-rpath.patch: IIUC can be avoided with --without-libiconv-prefix --without-libintl-prefix configure flags. Still applies. gcc45-ada.diff: switches Cygwin GNAT from a Windows hybrid to pure *NIX code, and enable shared libgnat. Last time I tried it, code linked with the libgnat DLL didn't exit properly, so this may need more work. gcc45-ehdebug.diff: just some debugging printf()s AFAICS. gcc45-java-FIONREAD.diff: important fix a bug in NIO; this is a must. gcc45-libffi.diff: makes FFI lib and header install in GCC dirs instead of system dirs. Perhaps this version shouldn't be installed at all (only the convenience library is actually used in libjava) and ship the standalone libffi-3.0.11 instead. gcc45-libstdc.diff: The -no-undefined hunks are required, but the -bindir flags aren't necessary with cygport. -Wl,--enable-auto-import is already the default, but it seems that is insufficient, hence all the dllimport/dllexport. Honestly I'm not sure why though. gcc45-misc-core.diff: not sure what this is for. Does not currently apply. gcc45-mnocygwin.diff: obsolete. Noted. gcc45-peflags.diff: link only executables with --tsaware, and also use --large-address-aware. This too is a must. Not upstream yet. Does not apply, but simple enough to fix. gcc45-sig-unwind.diff: explained therein; may have been upstreamed already. Does not apply. gcc45-skiptest.diff: test is ELF-specific. Still applies. There is one more patch required from the Fedora Cygwin toolchain: http://fedora-cygwin.git.sourceforge.net/git/gitweb.cgi?p=fedora-cygwin/cygwin-gcc;a=tree gcc45-gc-win32-threads.diff: the native gcc4 was last built before pthread_getaddr_np() was added, so this is a new requirement. OK, I'll look into that. I have not look closely how the patches fail to apply, just took a glance at cygport prep output. signature.asc Description: OpenPGP digital signature
Re: GCC maintainer volunteer? (was Re: Changing dependent library version numbers vs. test packages vs. requires: lines.)
On 2/19/2013 20:53, JonY wrote: On 2/19/2013 19:46, Yaakov (Cygwin/X) wrote: On Tue, 19 Feb 2013 18:21:56 +0800, JonY wrote: I can give Cygwin GCC a try over the weekends. Not sure if it is too complicated. Well, if someone else wants to take maintainership, feel free to over take me :) Please let me know if I can help; I have a fair amount of experience with building and packaging GCC, but no so much with the internals. Actually neither do I, just enough to make minor changes. I've started looking at the patches, they definitely aren't trivial. I'll probably be releasing it as experimental. signature.asc Description: OpenPGP digital signature
Re: GCC maintainer volunteer?
On 2/21/2013 20:40, NightStrike wrote: I've started looking at the patches, they definitely aren't trivial. I'll probably be releasing it as experimental. There are local cygwin patches to gcc? Yes, about 100KB of it. I confess I don't know what most of is for, my understanding of the gcc internals are limited. signature.asc Description: OpenPGP digital signature
Re: GCC maintainer volunteer?
On 2/21/2013 21:42, Corinna Vinschen wrote: On Feb 21 21:33, JonY wrote: On 2/21/2013 20:40, NightStrike wrote: I've started looking at the patches, they definitely aren't trivial. I'll probably be releasing it as experimental. There are local cygwin patches to gcc? Yes, about 100KB of it. I confess I don't know what most of is for, my understanding of the gcc internals are limited. I assume some (or all) of them are already upstream, but they were not backported into the 4.5.x branch. It might be a good idea to start out with a clean upstream build and then look into the patches if they still make some sense. OK, will do. signature.asc Description: OpenPGP digital signature
Re: GCC maintainer volunteer?
On 2/22/2013 00:59, Corinna Vinschen wrote: On Feb 21 11:31, Chris Sutcliffe wrote: On 21 February 2013 10:38, NightStrike wrote: On Thu, Feb 21, 2013 at 3:42 AM, Corinna Vinschen wrote: On Feb 21 21:33, JonY wrote: On 2/21/2013 20:40, NightStrike wrote: I've started looking at the patches, they definitely aren't trivial. I'll probably be releasing it as experimental. There are local cygwin patches to gcc? Yes, about 100KB of it. I confess I don't know what most of is for, my understanding of the gcc internals are limited. I assume some (or all) of them are already upstream, but they were not backported into the 4.5.x branch. It might be a good idea to start out with a clean upstream build and then look into the patches if they still make some sense. Are they in 4.6? If so, why not just start fresh and clean with a 4.6 'chain that needs zero patching? I believe Corinna means going to later version of GCC, preferably straight to 4.7 would be great. Exactly. The question is then, what patches from the 4.5.3 gcc were not applied upstream and still make sense today. I have not looked at all the patches closely, but some of them were not merged in gcc-4.7.2, at least the peflags patch did not. Who is the upstream GCC maintainer for Cygwin anyway? signature.asc Description: OpenPGP digital signature
Re: GCC maintainer volunteer? (was Re: Changing dependent library version numbers vs. test packages vs. requires: lines.)
On 2/19/2013 15:46, Corinna Vinschen wrote: On Feb 18 18:59, Chris Sutcliffe wrote: On 4 February 2013 05:16, Corinna Vinschen wrote: I think we're now waiting for a sign of progress on GCC for too long. I don't think we can wait much longer. If you're still happy to maintain Cygwin's GCC, please provide a new package within the next two weeks. Otherwise, from my point of view GCC is up for grabs. I believe it's been 2 weeks, any chance someone will lead the charge and provide a new GCC? Yeah, it's really too bad. I had so hoped that Dave would still be with us. I now orphaned all gcc packages in cygwin-pkg-maint. If anybody feels bold enough to take up gcc maintainership, please step forward. It would be most appreciated if you would also be willing to take over maintainership of the 64 bit compiler, as soon as we start the official 64 bit distro (later this year). But that's an entirely different beast, so we could also split maintainership, especially given the requirement to provide cross compilers 32-64 and 64-32 bit, too. I can give Cygwin GCC a try over the weekends. Not sure if it is too complicated. Well, if someone else wants to take maintainership, feel free to over take me :) signature.asc Description: OpenPGP digital signature
Re: GCC maintainer volunteer? (was Re: Changing dependent library version numbers vs. test packages vs. requires: lines.)
On 2/19/2013 19:46, Yaakov (Cygwin/X) wrote: On Tue, 19 Feb 2013 18:21:56 +0800, JonY wrote: I can give Cygwin GCC a try over the weekends. Not sure if it is too complicated. Well, if someone else wants to take maintainership, feel free to over take me :) Please let me know if I can help; I have a fair amount of experience with building and packaging GCC, but no so much with the internals. Actually neither do I, just enough to make minor changes. signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw64-* crt and headers update, including win32api
On 11/16/2012 00:56, Christopher Faylor wrote: On Thu, Nov 15, 2012 at 04:00:32PM +0100, Corinna Vinschen wrote: On Nov 15 22:40, JonY wrote: On 11/15/2012 22:26, Corinna Vinschen wrote: Hi, is there some sort of staging area? Or do I go in and upload the tarballs directly? You can use the staging area at /sourceware/snapshot-tmp/cygwin/release It's used by the get-cygwin-package script as well. It will push it to the main area after a few hours? It depends. If you use the get-cygwin-package script it will (baring network or script problems) do the entire job. Right, but obviously it pays to check your work after letting get-cygwin-package do things since it still has some kinks. If you upload to the staging area manually, you also have to move your stuff over manually, using cpio -p, for instance. I usually use cp -a --link . ~release/whereever . Then remove the original directory. cgf OK, uploaded, how long do I wait to find out if I screwed up? :) Also, do I need to manually update the md5? 0xF266FE90.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw64-* crt and headers update, including win32api
On 11/15/2012 01:48, Christopher Faylor wrote: On Wed, Nov 14, 2012 at 05:42:27PM +0100, Corinna Vinschen wrote: On Nov 14 07:55, NightStrike wrote: On Wed, Nov 14, 2012 at 2:08 AM, Yaakov (Cygwin/X) Also, SF.net's FRS is notorious for serving up the wrong file when more than one file the same name in different directories (e.g. setup.hint). That has long since been fixed. You may wish to find another location for temporary posting of patches for upload (mingw-w64.sf.net project web space should work). Project web space has a total size limit of 100MB. Also, it is mirrored just like the FRS, though it's a lot more transparent. Given the size, it might be helpful if JonY has upload rights on sourceware. Jon, if you think that's helpful, you can request an account on sourceware using the form at http://sourceware.org/cgi-bin/pdw/ps_form.cgi Please note that this is supposed to be used *only* to upload stuff and copying over to the Cygwin release area. i.e., please don't use your home directory here as a place to store stuff. Space on /home on sourceware is kept intentionally small to discourage people from using it for backups, scripts, etc. cgf Hi, is there some sort of staging area? Or do I go in and upload the tarballs directly? Likewise, do I simply delete the old uploads? signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw64-* crt and headers update, including win32api
On 11/15/2012 22:26, Corinna Vinschen wrote: Hi, is there some sort of staging area? Or do I go in and upload the tarballs directly? You can use the staging area at /sourceware/snapshot-tmp/cygwin/release It's used by the get-cygwin-package script as well. It will push it to the main area after a few hours? Likewise, do I simply delete the old uploads? You can delete old versions which you don't want to provide anymore. Usuaully the user can see only two anyway, except you use the test marker in setup.hint to provide a third one. Noted, I'll upload tomorrow after I get back from work. signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw64-* crt and headers update, including win32api
On 11/15/2012 01:48, Christopher Faylor wrote: On Wed, Nov 14, 2012 at 05:42:27PM +0100, Corinna Vinschen wrote: On Nov 14 07:55, NightStrike wrote: On Wed, Nov 14, 2012 at 2:08 AM, Yaakov (Cygwin/X) Also, SF.net's FRS is notorious for serving up the wrong file when more than one file the same name in different directories (e.g. setup.hint). That has long since been fixed. You may wish to find another location for temporary posting of patches for upload (mingw-w64.sf.net project web space should work). Project web space has a total size limit of 100MB. Also, it is mirrored just like the FRS, though it's a lot more transparent. Given the size, it might be helpful if JonY has upload rights on sourceware. Jon, if you think that's helpful, you can request an account on sourceware using the form at http://sourceware.org/cgi-bin/pdw/ps_form.cgi Please note that this is supposed to be used *only* to upload stuff and copying over to the Cygwin release area. i.e., please don't use your home directory here as a place to store stuff. Space on /home on sourceware is kept intentionally small to discourage people from using it for backups, scripts, etc. cgf OK, sent a request, I put Corinna as approver. signature.asc Description: OpenPGP digital signature
[RFU] mingw64-* crt and headers update, including win32api
Here's a new update, Some of the uploads are still missing, I presume it is still mirroring. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5452-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5452-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-debuginfo/mingw64-i686-runtime-debuginfo-3.0b_svn5452-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-debuginfo/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn5452-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn5452-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-debuginfo/mingw64-x86_64-runtime-debuginfo-3.0b_svn5452-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-debuginfo/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn5452-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn5452-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5452-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5452-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn5452-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn5452-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5452-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5452-1.tar.bz2 Delete old copies: find -name mingw64-x86_64*4725-1* -type f | xargs rm -v find -name mingw64-i686*4725-1* -type f | xargs rm -v signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw64-* crt and headers update, including win32api
On 11/14/2012 03:37, Christopher Faylor wrote: On Tue, Nov 13, 2012 at 11:36:38PM +0800, JonY wrote: Here's a new update, Some of the uploads are still missing, I presume it is still mirroring. That's some slow mirroring if so: *** retrieval for https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn5452-1-src.tar.bz2 failed, status 256. *** retrieval for https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn5452-1.tar.bz2 failed, status 256. *** retrieval for https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5452-1-src.tar.bz2 failed, status 256. *** retrieval for https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5452-1.tar.bz2 failed, status 256. cgf I just checked, those should be up now. Not sure why SF was so slow. signature.asc Description: OpenPGP digital signature
[RFU] w32api-runtime-3.0b_svn5431-2
Hi, Quick fix for iphlpapi.def exports having double or missing stdcall decorators. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-2-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-2.tar.bz2 Should be OK to remove previous. Thanks. signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/18/2012 16:08, Corinna Vinschen wrote: On Oct 17 23:09, Yaakov (Cygwin/X) wrote: On Thu, 2012-10-18 at 06:17 +0800, JonY wrote: OK, renamed, I hope I did not mess it up this time. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1.tar.bz2 Uploaded. I have also switched the Fedora Cygwin toolchain to the mingw-w64 w32api packages. Thanks, guys! Awesome, and now to wait for the avalanche of complaints :) signature.asc Description: OpenPGP digital signature
Re: gold stars Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/19/2012 00:00, Corinna Vinschen wrote: On Oct 18 11:19, Christopher Faylor wrote: On Thu, Oct 18, 2012 at 12:32:00PM +0200, Corinna Vinschen wrote: On Oct 18 17:21, JonY wrote: On 10/18/2012 16:08, Corinna Vinschen wrote: On Oct 17 23:09, Yaakov (Cygwin/X) wrote: On Thu, 2012-10-18 at 06:17 +0800, JonY wrote: OK, renamed, I hope I did not mess it up this time. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1.tar.bz2 Uploaded. I have also switched the Fedora Cygwin toolchain to the mingw-w64 w32api packages. Thanks, guys! Awesome, and now to wait for the avalanche of complaints :) You should probably break the news to the announce list gently. :) But, in the meantime, could we get some gold stars for this? This is a significant achievement. Jon already got a gold star for taking over w32api. But this is *still* a significant achievement, so we probably should take another one out of the vault for Jon. Thanks guys. signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/17/2012 16:20, Corinna Vinschen wrote: On Oct 16 20:02, Yaakov (Cygwin/X) wrote: On Sat, 2012-10-13 at 13:36 +0800, JonY wrote: I decided do a simpler split out version due to the way the source package is built, with w32api as a meta package. If required I can redo it into a single package. Preference? Comments? http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 I think the sdesc: is confusing. How about: sdesc: Windows API headers http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 sdesc: Windows API import libraries But wouldn't w32api-headers be a better name? You have a point there, Yaakov. In fact, you already set a precedent with your mingw packages, Jon. We have mingw64-headers and mingw64-runtime packages. I'm not *that* sure about the runtime name, but a consistent naming sounds like a good idea. Alright, will rename it. signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/17/2012 17:23, JonY wrote: On 10/17/2012 16:20, Corinna Vinschen wrote: In fact, you already set a precedent with your mingw packages, Jon. We have mingw64-headers and mingw64-runtime packages. I'm not *that* sure about the runtime name, but a consistent naming sounds like a good idea. Alright, will rename it. OK, renamed, I hope I did not mess it up this time. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1.tar.bz2 signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/14/2012 02:12, Christopher Faylor wrote: On Sat, Oct 13, 2012 at 12:45:43PM -0400, Christopher Faylor wrote: On Sun, Oct 14, 2012 at 12:28:42AM +0800, JonY wrote: On 10/14/2012 00:08, Corinna Vinschen wrote: Sounds really interesting. I just tried it, but it fails to download the w32api-libs and w32api-includes packages: generating package name - package directory mapping... Done couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint - /sourceware/snapshot-tmp/cygwin/release/w32api/setup.hint Corinna It doesn't handle new packages? Nope. Only old packages. Should have made that clear. However, if you make the appropriate subdirectories in cygwin's release ^ first area it will then work. Ping. signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/16/2012 23:32, Corinna Vinschen wrote: On Oct 16 18:05, JonY wrote: On 10/14/2012 02:12, Christopher Faylor wrote: On Sat, Oct 13, 2012 at 12:45:43PM -0400, Christopher Faylor wrote: On Sun, Oct 14, 2012 at 12:28:42AM +0800, JonY wrote: On 10/14/2012 00:08, Corinna Vinschen wrote: Sounds really interesting. I just tried it, but it fails to download the w32api-libs and w32api-includes packages: generating package name - package directory mapping... Done couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint - /sourceware/snapshot-tmp/cygwin/release/w32api/setup.hint Corinna It doesn't handle new packages? Nope. Only old packages. Should have made that clear. However, if you make the appropriate subdirectories in cygwin's release ^ first area it will then work. Ping. Are you waiting for more feedback or shall we upload? Are you mentally and ethically prepared to take the loads of complaints on the Cygwin ML? It's good to go if the Cygwin maintainers are OK with split out packages and a meta package. As for complaints, well, we'll see how it goes. signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/17/2012 06:19, JonY wrote: On 10/16/2012 23:32, Corinna Vinschen wrote: Are you waiting for more feedback or shall we upload? Are you mentally and ethically prepared to take the loads of complaints on the Cygwin ML? It's good to go if the Cygwin maintainers are OK with split out packages and a meta package. As for complaints, well, we'll see how it goes. I mean to say I'll try my best, within mortal limits :) signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/14/2012 00:08, Corinna Vinschen wrote: Sounds really interesting. I just tried it, but it fails to download the w32api-libs and w32api-includes packages: generating package name - package directory mapping... Done couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint - /sourceware/snapshot-tmp/cygwin/release/w32api/setup.hint Corinna It doesn't handle new packages? signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 10/12/2012 01:10, Yaakov (Cygwin/X) wrote: On Wed, 2012-10-10 at 23:55 -0500, Yaakov (Cygwin/X) wrote: On Wed, 2012-10-10 at 11:09 +0200, Corinna Vinschen wrote: Other than that, was there any other roadblock on the way to the Mingw64 headers? I think there's still one issue wrt xorg-server; I need to check that again. SVN trunk (r5430) is GTG, but AFAICS at least r5384 should do. Any thoughts on if I should put up multilib w32api? I'm having second thoughts now since I realize you can't simply build them with ootb Cygwin tools. signature.asc Description: OpenPGP digital signature
[ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/12/2012 18:57, Yaakov (Cygwin/X) wrote: On Fri, 2012-10-12 at 18:27 +0800, JonY wrote: Any thoughts on if I should put up multilib w32api? I'm having second thoughts now since I realize you can't simply build them with ootb Cygwin tools. Not only that, but they are also useless with the cygwin compiler, with is currently 32-bit only. IMO w32api should be built with the native gcc4, and configured --enable-lib32 --disable-lib64 until such time that we have a 64-bit Cygwin. OK, I decided do a simpler split out version due to the way the source package is built, with w32api as a meta package. If required I can redo it into a single package. Preference? Comments? http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 10/9/2012 18:06, Corinna Vinschen wrote: On Oct 2 16:54, JonY wrote: On 9/24/2012 12:27, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? jturney, did you patch(es) get committed yet? Unfortunately, I did find another regression, this time with bind. The mingw-w64 inaddr.h header conflicts with Cygwin's netinet/in.h: In file included from /usr/include/w32api/ras.h:11:0, from /usr/include/w32api/mprapi.h:10, from /usr/include/w32api/iprtrmib.h:9, from /usr/include/w32api/iphlpapi.h:13, from test.c:4: /usr/include/w32api/inaddr.h:17:16: error: redefinition of ‘struct in_addr’ /usr/include/cygwin/in.h:116:8: note: originally defined here Yaakov Ping, anything new? Why does bind include iphlpapi.h at all? As a Cygwin application it's not supposed to use Windows and Cygwin network functions in parallel. Corinna I gathered from Yaakov that he wanted some fallback to the Windows DNS settings when /etc/resolv.conf isn't found. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 9/24/2012 12:27, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? jturney, did you patch(es) get committed yet? Unfortunately, I did find another regression, this time with bind. The mingw-w64 inaddr.h header conflicts with Cygwin's netinet/in.h: In file included from /usr/include/w32api/ras.h:11:0, from /usr/include/w32api/mprapi.h:10, from /usr/include/w32api/iprtrmib.h:9, from /usr/include/w32api/iphlpapi.h:13, from test.c:4: /usr/include/w32api/inaddr.h:17:16: error: redefinition of ‘struct in_addr’ /usr/include/cygwin/in.h:116:8: note: originally defined here Yaakov Ping, anything new? signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 9/4/2012 00:05, Jon TURNEY wrote: On 03/09/2012 16:59, Jon TURNEY wrote: So, how about the attached (minimal) change? (where NOBOOLTYPE is named whatever you think is appropriate) This time with correct patch attached... Done in trunk, used _NOBOOLTYPEDEF. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 9/4/2012 18:21, JonY wrote: On 9/4/2012 00:05, Jon TURNEY wrote: On 03/09/2012 16:59, Jon TURNEY wrote: So, how about the attached (minimal) change? (where NOBOOLTYPE is named whatever you think is appropriate) This time with correct patch attached... Done in trunk, used _NOBOOLTYPEDEF. I just made a last second change to _NO_BOOL_TYPEDEF for readability, sorry if I caused any inconvenience. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 9/3/2012 18:34, Corinna Vinschen wrote: New version up. Was the first uploaded? http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1-src.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint/download None have been uploaded so far. I'm not sure of the current state of the discussion. Are the above w32api headers good to go or is a new version in the loop? Corinna Jon Turney says he's working on a patch for xorg-server to build with mingw-w64. Jon, any comments? signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 8/29/2012 14:14, Yaakov (Cygwin/X) wrote: On Thu, 2012-08-23 at 19:45 +0100, Jon TURNEY wrote: Yaakov, you might like to try the attached patch. With an appropriate change to prevent BOOL redefinition errors, this builds X server for me. WFM. Once your _PROTECT_BOOL_MACRO patch for windef.h is accepted, I can roll an xproto update and this will be GTG. No problems with ddraw.h status? signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw64 headers and runtime refresh
On 8/27/2012 23:09, Jon TURNEY wrote: On 27/08/12 09:44, JonY wrote: On 8/26/2012 02:18, JonY wrote: I notice that the source package for mingw64-i686-runtime seems to have got a lot smaller, you might want to check that is correct. Looks like something is wrong with the upload, refreshed, same link. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/setup.hint Sorry for the inconvenience. Please increment the package release number to -2, so we don't have packages with the same identifier but different contents. OK, http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/setup.hint/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5373-2.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5373-2-src.tar.bz2/download Release bumped. signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw64 headers and runtime refresh
On 8/26/2012 02:18, JonY wrote: I notice that the source package for mingw64-i686-runtime seems to have got a lot smaller, you might want to check that is correct. Looks like something is wrong with the upload, refreshed, same link. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/setup.hint Sorry for the inconvenience. Ping. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 8/24/2012 00:51, Jon TURNEY wrote: On 22/08/2012 10:08, JonY wrote: On 8/22/2012 06:26, JonY wrote: According to mingw.org basetyps.h, GUID_SECT was only necessary for ancient GCC versions. At a minimum, we should be able to just remove the GUID_SECT from those defines. Unfortunately just ifndef _W64 those defines entirely leads to link errors: hw/xwin/winengine.c:107: undefined reference to `_IID_IDirectDraw4' winshaddd.o: In function `winAllocateFBShadowDD': hw/xwin/winshaddd.c:253: undefined reference to `_IID_IDirectDraw2' winshadddnl.o: In function `winAllocateFBShadowDDNL': hw/xwin/winshadddnl.c:285: undefined reference to `_IID_IDirectDraw4' winpfbdd.o: In function `winAllocateFBPrimaryDD': hw/xwin/winpfbdd.c:89: undefined reference to `_IID_IDirectDraw2' It's pretty easy to adapt for this in the existing X server code either by simply defining GUID_SECT as empty if it is not already defined, or removing GUID_SECT. mingw-w64 ddraw.h already has them, though they're inlined, gcc doesn't like inlined data. DEFINE_GUID may need fixing, or at least instanced in libuuid or libddraw. I'll need to talk to to the Jacek from Wine to get a solution. Here's a quick and dirty workaround, add and compile the following file and link it with the failing executable: = #define INITGUID 1 #include ddraw.h = It's tempting to conclude that the brokeness alluded to in the comment in the X server source is that the author didn't know about INITGUID. It seems that GUID_SECT is defined by the current w32api headers, but only had any contents for ancient gcc (prior to 2.95) However, Google seems to indicate that we are not totally alone in assuming the existence of GUID_SECT, so you might want to consider providing an empty definition for compatibility. OK, found the proper lib to link with, add -ldxguid for libdxguid.a. I did not know of this until Jacek told me about it. signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw64 headers and runtime refresh
On 8/25/2012 22:02, Jon TURNEY wrote: On 22/08/12 22:59, JonY wrote: On 8/19/2012 21:53, JonY wrote: Hi, New uploads at: http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/setup.hint Please remove 4694: find mingw64-*/ -name '*svn4694-1*' -type f | xargs rm Thanks. Done and done. I notice that the source package for mingw64-i686-runtime seems to have got a lot smaller, you might want to check that is correct. Looks like something is wrong with the upload, refreshed, same link. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/setup.hint Sorry for the inconvenience. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 8/22/2012 06:26, JonY wrote: According to mingw.org basetyps.h, GUID_SECT was only necessary for ancient GCC versions. At a minimum, we should be able to just remove the GUID_SECT from those defines. Unfortunately just ifndef _W64 those defines entirely leads to link errors: hw/xwin/winengine.c:107: undefined reference to `_IID_IDirectDraw4' winshaddd.o: In function `winAllocateFBShadowDD': hw/xwin/winshaddd.c:253: undefined reference to `_IID_IDirectDraw2' winshadddnl.o: In function `winAllocateFBShadowDDNL': hw/xwin/winshadddnl.c:285: undefined reference to `_IID_IDirectDraw4' winpfbdd.o: In function `winAllocateFBPrimaryDD': hw/xwin/winpfbdd.c:89: undefined reference to `_IID_IDirectDraw2' mingw-w64 ddraw.h already has them, though they're inlined, gcc doesn't like inlined data. DEFINE_GUID may need fixing, or at least instanced in libuuid or libddraw. I'll need to talk to to the Jacek from Wine to get a solution. Here's a quick and dirty workaround, add and compile the following file and link it with the failing executable: = #define INITGUID 1 #include ddraw.h = signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw64 headers and runtime refresh
On 8/19/2012 21:53, JonY wrote: Hi, New uploads at: http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/setup.hint Please remove 4694: find mingw64-*/ -name '*svn4694-1*' -type f | xargs rm Thanks. Ping. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 8/21/2012 19:11, Jon TURNEY wrote: On 21/08/2012 05:47, JonY wrote: On 8/21/2012 11:46, Christopher Faylor wrote: On Tue, Aug 21, 2012 at 11:31:23AM +0800, JonY wrote: On 8/21/2012 10:23, JonY wrote: On 8/21/2012 09:15, JonY wrote: On 8/21/2012 07:22, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: So I built this from SVN trunk myself, and xorg-server still FTBFS: In file included from /usr/include/w32api/windows.h:69:0, from /usr/include/X11/Xwindows.h:60, from ../../../hw/xwin/winms.h:42, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/windef.h:107:13: error: conflicting types for 'BOOL' /usr/include/X11/Xmd.h:143:16: note: previous declaration of 'BOOL' was Yaakov, try this change: Index: include/windef.h === --- include/windef.h(revision 5374) +++ include/windef.h(working copy) @@ -101,6 +101,7 @@ #ifndef _DEF_WINBOOL_ #define _DEF_WINBOOL_ typedef int WINBOOL; +#ifndef XFree86Server /* For xorg-server */ #pragma push_macro(BOOL) #undef BOOL #if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) @@ -110,6 +111,7 @@ typedef BOOL *PBOOL; typedef BOOL *LPBOOL; #pragma pop_macro(BOOL) +#endif /* XFree86Server */ #endif /* _DEF_WINBOOL_ */ I'm not sure if things will explode horribly. Maybe this is just a sanity check/proof of concept thing but do we really want to have specific ifdef's like this in shipping headers? That would suggest a neverending cascade of ifdefs. If we really need something like this then I'd suggest something more generic like a #ifdef __PROTECT_PROTECT_BOOL_MACRO. yeah, it is just a proof of concept, it is copied from the existing w32api package. If this works, I'll talk to Kai about untangling the ifdefs. I've never been really sure what historical accidents are behind the #ifdef XFree86Server in w32api. It doesn't do anything useful, since in the X server, windows header files are always included via a header which wraps them to avoid name collisions [1], which carefully arranges for XFree86Server to be undefined. [1] http://cgit.freedesktop.org/xorg/proto/xproto/tree/Xwindows.h Here's the part from mingw-w64 windef.h: #ifndef _DEF_WINBOOL_ #define _DEF_WINBOOL_ typedef int WINBOOL; #pragma push_macro(BOOL) #undef BOOL #if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) typedef int BOOL; #endif #define BOOL WINBOOL typedef BOOL *PBOOL; typedef BOOL *LPBOOL; #pragma pop_macro(BOOL) #endif /* _DEF_WINBOOL_ */ Note the pragma push and undef, the Xwindows.h macro tricks no longer works. Perhaps guarding against _XFree86Server instead of XFree86Server will work? signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 8/22/2012 02:58, Yaakov (Cygwin/X) wrote:
On 2012-08-21 09:13, Jon TURNEY wrote:
There are a also couple of other issues which prevent X server from
compiling
successfully with these headers, which should probably be fixed in the
X server:
DEFINE_GUID is defined in terms of GUID_SECT, which no longer exists.
I'm not
sure what the broken-ness referred to here is, or if it still exists...
/*
* FIXME: Headers are broken, DEFINE_GUID doesn't work correctly,
* so we have to redefine it here.
*/
#ifdef DEFINE_GUID
#undef DEFINE_GUID
#define DEFINE_GUID(n,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) const GUID n
GUID_SECT
= {l,w1,w2,{b1,b2,b3,b4,b5,b6,b7,b8}}
#endif /* DEFINE_GUID */
According to mingw.org basetyps.h, GUID_SECT was only necessary for
ancient GCC versions. At a minimum, we should be able to just remove
the GUID_SECT from those defines. Unfortunately just ifndef _W64 those
defines entirely leads to link errors:
hw/xwin/winengine.c:107: undefined reference to `_IID_IDirectDraw4'
winshaddd.o: In function `winAllocateFBShadowDD':
hw/xwin/winshaddd.c:253: undefined reference to `_IID_IDirectDraw2'
winshadddnl.o: In function `winAllocateFBShadowDDNL':
hw/xwin/winshadddnl.c:285: undefined reference to `_IID_IDirectDraw4'
winpfbdd.o: In function `winAllocateFBPrimaryDD':
hw/xwin/winpfbdd.c:89: undefined reference to `_IID_IDirectDraw2'
mingw-w64 ddraw.h already has them, though they're inlined, gcc doesn't
like inlined data. DEFINE_GUID may need fixing, or at least instanced in
libuuid or libddraw.
I'll need to talk to to the Jacek from Wine to get a solution.
'Status' is used as formal parameter name in some w32api headers, but
as a
typename in xkbsrv.h. We wrap this in Xwindows.h to avoid conflict,
(The difference being that mingw.org's rpc*.h don't use parameter
names, only types.)
These may also need cooperation from Jacek.
but objbase.h is included outside of that wrapper when we are defining
directdraw
interface GUIDs, leading to a conflict in rpcdce.h
Once we get past those, there are a few more:
In file included from winmultiwindowwm.c:74:0:
taskbar.h:34:16: error: redefinition of ‘struct _tagpropertykey’
/usr/include/w32api/wtypes.h:762:16: note: originally defined here
taskbar.h:37:3: error: conflicting types for ‘PROPERTYKEY’
/usr/include/w32api/wtypes.h:765:3: note: previous declaration of
‘PROPERTYKEY’ was here
taskbar.h:39:0: warning: REFPROPVARIANT redefined
/usr/include/w32api/propidl.h:266:0: note: this is the location of the
previous definition
In file included from winmultiwindowwm.c:74:0:
taskbar.h:67:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘const’
winmultiwindowwm.c: In function ‘winSetAppID’:
winmultiwindowwm.c:2064:44: error: ‘PKEY_AppUserModel_ID’ undeclared
(first use in this function)
This would appear to be fixable by using propkey.h in
hw/xwin/taskbar.h instead of defining this stuff ourselves, but that
header is _W64-specific.
The header details are actually scrapped from MSDN.
signature.asc
Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 8/14/2012 16:02, Kai Tietz wrote: 2012/8/14 Corinna Vinschen: On Aug 14 08:46, Andy Koppe wrote: Yep, mintty builds fine with that, and appears to work. For some reason it's 9K bigger than with the current w32api though. I think this is because the mingw-w64 libs come with a couple more static elements built into the libs (GUIDs and stuff). Kai, can you explain the difference? Corinna Well, major difference here is - as you already mentioned - the fact that mingw-w64 provides some helper-routines (as described by msdn) in ws2_32 and some other libraries. Also the uuid-library is a bit bigger. Also we provide some of the intrinsic-function as inline-code, which might be responsible for some size-improvment - but better optimization - you notice. Btw have you checked size with debugging-information, or without? Regards, Kai New version up. Was the first uploaded? http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1-src.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint/download signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 8/21/2012 09:15, JonY wrote: On 8/21/2012 07:22, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? No, nor can it until packages which depend on w32api build correctly. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1-src.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint/download The binary package contains only the headers; the libs are missing. My bad, I did not notice the build stage error, cygport proceeded to install and package. So I built this from SVN trunk myself, and xorg-server still FTBFS: In file included from /usr/include/w32api/windows.h:69:0, from /usr/include/X11/Xwindows.h:60, from ../../../hw/xwin/winms.h:42, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/windef.h:107:13: error: conflicting types for 'BOOL' /usr/include/X11/Xmd.h:143:16: note: previous declaration of 'BOOL' was iirc the BOOL workaround was removed, I'm not sure if I remember it correctly. If so, it could be reintroduced. Sorry, dropped cygwin-apps by accident from the recipient list. Anyway, new build up, same URL for the 3 files. These are the same revisions, so the BOOL problem is still there, if anybody wants to try their hands on it for anything other Xorg, please do. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 8/21/2012 10:23, JonY wrote: On 8/21/2012 09:15, JonY wrote: On 8/21/2012 07:22, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? No, nor can it until packages which depend on w32api build correctly. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1-src.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint/download The binary package contains only the headers; the libs are missing. My bad, I did not notice the build stage error, cygport proceeded to install and package. So I built this from SVN trunk myself, and xorg-server still FTBFS: In file included from /usr/include/w32api/windows.h:69:0, from /usr/include/X11/Xwindows.h:60, from ../../../hw/xwin/winms.h:42, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/windef.h:107:13: error: conflicting types for 'BOOL' /usr/include/X11/Xmd.h:143:16: note: previous declaration of 'BOOL' was Yaakov, try this change: Index: include/windef.h === --- include/windef.h(revision 5374) +++ include/windef.h(working copy) @@ -101,6 +101,7 @@ #ifndef _DEF_WINBOOL_ #define _DEF_WINBOOL_ typedef int WINBOOL; +#ifndef XFree86Server /* For xorg-server */ #pragma push_macro(BOOL) #undef BOOL #if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) @@ -110,6 +111,7 @@ typedef BOOL *PBOOL; typedef BOOL *LPBOOL; #pragma pop_macro(BOOL) +#endif /* XFree86Server */ #endif /* _DEF_WINBOOL_ */ I'm not sure if things will explode horribly. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 8/21/2012 11:46, Christopher Faylor wrote: On Tue, Aug 21, 2012 at 11:31:23AM +0800, JonY wrote: On 8/21/2012 10:23, JonY wrote: On 8/21/2012 09:15, JonY wrote: On 8/21/2012 07:22, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? No, nor can it until packages which depend on w32api build correctly. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1-src.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint/download The binary package contains only the headers; the libs are missing. My bad, I did not notice the build stage error, cygport proceeded to install and package. So I built this from SVN trunk myself, and xorg-server still FTBFS: In file included from /usr/include/w32api/windows.h:69:0, from /usr/include/X11/Xwindows.h:60, from ../../../hw/xwin/winms.h:42, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/windef.h:107:13: error: conflicting types for 'BOOL' /usr/include/X11/Xmd.h:143:16: note: previous declaration of 'BOOL' was Yaakov, try this change: Index: include/windef.h === --- include/windef.h(revision 5374) +++ include/windef.h(working copy) @@ -101,6 +101,7 @@ #ifndef _DEF_WINBOOL_ #define _DEF_WINBOOL_ typedef int WINBOOL; +#ifndef XFree86Server /* For xorg-server */ #pragma push_macro(BOOL) #undef BOOL #if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) @@ -110,6 +111,7 @@ typedef BOOL *PBOOL; typedef BOOL *LPBOOL; #pragma pop_macro(BOOL) +#endif /* XFree86Server */ #endif /* _DEF_WINBOOL_ */ I'm not sure if things will explode horribly. Maybe this is just a sanity check/proof of concept thing but do we really want to have specific ifdef's like this in shipping headers? That would suggest a neverending cascade of ifdefs. If we really need something like this then I'd suggest something more generic like a #ifdef __PROTECT_PROTECT_BOOL_MACRO. yeah, it is just a proof of concept, it is copied from the existing w32api package. If this works, I'll talk to Kai about untangling the ifdefs. signature.asc Description: OpenPGP digital signature
[RFU] mingw64 headers and runtime refresh
Hi, New uploads at: http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-headers/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn5373-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn5373-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/setup.hint Please remove 4694: find mingw64-*/ -name '*svn4694-1*' -type f | xargs rm Thanks. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 8/14/2012 10:51, Yaakov (Cygwin/X) wrote: On 2012-08-12 01:49, JonY wrote: New w32api preliminary upload, now with mingw-w64 parts. Nack. Both mintty and xorg-server FTBFS with this w32api. It contains the headers and win32 and win64 DLL import libraries. It does require multilib capable GCC to build. Why? What is the purpose of 64-bit libs with a 32-bit-only Cygwin GCC? Like Corinna says, 64bit Cygwin has to start somewhere. Yaakov: Can cygport implement a new inherit where it is similar to cross, except it uses --prefix=/usr? Right now, I'm setting CC/CXX manually to get around it. To bootstrap, you could just unset CC/CXX and configure with --host=x86_64-w64-mingw32. But once the new w32api is installed, if you configure with --disable-lib64, this should be buildable with Cygwin's native GCC. I did not think of that, thanks. signature.asc Description: OpenPGP digital signature
[ITA] w32api-3.0b_svn5368-1
Hi, New w32api preliminary upload, now with mingw-w64 parts. It contains the headers and win32 and win64 DLL import libraries. It does require multilib capable GCC to build. Special thanks to Corinna for making this possible. Comments? Yaakov: Can cygport implement a new inherit where it is similar to cross, except it uses --prefix=/usr? Right now, I'm setting CC/CXX manually to get around it. setup.hint same as before: sdesc: Win32 API header and library import files category: Libs Links: http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5368-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5368-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint signature.asc Description: OpenPGP digital signature
Re: Restart discussion: Where to put the SDK headers and libs when switching to Mingw64 SDK?
On 7/10/2012 16:10, Corinna Vinschen wrote:
On Jul 9 17:39, Corinna Vinschen wrote:
[...]
The question I'd like to discuss now is, how do we organize the access
to the Platform SDK headers and libs from the Mingw64 project, so that a
native Cygwin compiler has access to them?
Please note that I'm only talking about the PSDK stuff. We don't need
access to the Mingw CRT headers and libs (with a minor number of
exceptions), so the Mingw CRT stuff should continue to be isolated in
the /usr/${cpu}-w64-mingw32/sys-root/mingw/{include,lib} paths.
There are two obvious choices:
- The Platform SDK headers and libs are directly installed into
/usr/include/w32api, /usr/lib/w32api, and /usr/lib64/w32api, just
as today.
- Alternatively, the PSDK stuff is installed into a shared directory
which can be used not only by a Cygwin compiler, but also by the
Mingw64 cross compilers. Potential paths are
- /usr/share/w32api/{include,lib/lib64}
- /usr/share/psdk/{include,lib/lib64}
- Some other path which I can't think of right now
The package containing these files creates symlinks /usr/include/w32api,
/usr/lib/w32api, and /usr/lib64/w32api in a postinstall script which
point to the real locations. Analog for the mingw64 cross compiler
packages.
Here's another idea which requires to change GCC and the configury of all
packages accessing Windows functionality, but adds cleanliness:
- As I said in my previous mail, the only reason we must have access to
libkernel32.a is the fact that the crtbegin.o file calls GetModuleHandle
and GetProcAddress.
So we can store the PSDK files whereever we want, but *drop* the
/usr/include/w32api and /usr/lib/w32api paths from the default search
paths of GCC.
We change GCC's __gcc_register_frame and __gcc_deregister_frame
functions to call a function within the Cygwin DLL instead, which
provides the combined functionality of GetModuleHandle and
GetProcAddress for the sole purpose to support GCC:
cygwin_internal (CW_FETCH_GCC_FUNC, libname, funcname);
Yes, this looks like dlopen Mark 2, but dlopen in Cygwin is a bit
heavyweight and we want the crtbegin.o functionality to be fast in
the first place. Just a call to GetModuleHandle and a call to
GetProcAddress, nothing else.
Additionally we change the spec file to drop the default linking of
-ladvapi32 -lshell32 -luser32 -lkernel32.
The result of this operation is that we don't have to link against
libkernel32.a. This in turn means when compiling Cygwin executables,
no access to the PSDK is required anymore, unless the application
itself calls Windows functionality. This in turn means we can drop
the default w32api paths from the GCC default spec file, too.
Applications using Windows functions would just have to add the new
PSDK paths to their configury.
Anyway, that's just a side idea. I'm curious what you think.
Obviously, even with this change we still have to agree on a path where
to store the PSDK headers.
Not sure about the technical details, Kai will have to answer that. Kai
did mention about using interrupt call gates to get around kernel32.dll,
not sure if it is even practical.
As for the install path, I think sharing headers will be a problem,
since the mingw-w64 cross compiler will need the all CRT headers.
Sharing libs between the cross compilers and Cygwin w32api/libxx should
be fine though, with clever use of symlinks.
signature.asc
Description: OpenPGP digital signature
Re: [RFU] mingw-w64
On 7/2/2012 17:22, Corinna Vinschen wrote: Hi Jon, On Jul 1 01:08, JonY wrote: Hi, Here are the new builds, please remove the oldest versions from each category, thanks. may I ask you a favor? It would be really helpful if you could add a statement what versions exactly to remove, perhaps even in the form of an easy `rm' command. Otherwise the uploader has to figure this out one directory after the other, which is kind of arduous, given that almost all packages have another version number. OK, Will this suffice? find mingw64-i686/mingw64-i686-gcc -name *4.5.3-2* | xargs rm find mingw64-i686/mingw64-i686-binutils -name *2.21.53-1* | xargs rm find mingw64-i686/mingw64-i686-headers -name *svn4430-1* | xargs rm find mingw64-i686/mingw64-i686-runtime -name *svn4430-1* | xargs rm find mingw64-x86_64/mingw64-x86_64-binutils -name *2.21.53-1* | xargs rm find mingw64-x86_64/mingw64-x86_64-gcc -name *4.5.3-2* | xargs rm find mingw64-x86_64/mingw64-x86_64-headers -name *svn4430-1* | xargs rm find mingw64-x86_64/mingw64-x86_64-runtime -name *svn4430-1* | xargs rm signature.asc Description: OpenPGP digital signature
