Re: GCC-4.7.2-2: Go/No-go?

2013-04-12 Thread Dave Korn
On 11/04/2013 21:42, Thomas Wolff wrote: Am 11.04.2013 14:34, schrieb Dave Korn: Also, I don't plan on doing it unless there's significant demand. I would appreciate to keep it as gcc-3. Fancy being the maintainer for it then? ;-) The reason is quite peculiar; gcc-4 changed the order of

Re: GCC-4.7.2-2: Go/No-go?

2013-04-12 Thread Yaakov (Cygwin/X)
On 2013-04-11 23:24, Dave Korn wrote: I usually recommend using cygport git master, and a number of maintainers track it. I want to ship packages that the general public can rebuild using the standard distro really. Do you have any idea of a schedule for releasing these features? Most of

Re: [64bit] type conflict for INT32

2013-04-12 Thread Charles Wilson
On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote: It does mean that Win32API (or X11, for that matter) headers must be #include'd before jpeglib.h. Before I spin a new release, could you test if this works with emacs? Would this problem go away if we switched to jpeg-turbo? -- Chuck

Re: Recent cygport and cygwin-specific READMEs

2013-04-12 Thread Charles Wilson
On 4/11/2013 6:37 PM, Yaakov (Cygwin/X) wrote: No, cygport(1) doesn't generate README content. Too bad. Well, maintaining the READMEs in my local git repo side-by-side with the cygport(5) is not that big a deal -- especially with the other cygport(1) improvements, incl #3 below. #2) Is

Re: [64bit] type conflict for INT32

2013-04-12 Thread Ken Brown
On 4/12/2013 10:04 AM, Charles Wilson wrote: On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote: It does mean that Win32API (or X11, for that matter) headers must be #include'd before jpeglib.h. Before I spin a new release, could you test if this works with emacs? Would this problem go away if we

Re: [64bit] type conflict for INT32

2013-04-12 Thread Corinna Vinschen
On Apr 12 10:24, Ken Brown wrote: On 4/12/2013 10:04 AM, Charles Wilson wrote: On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote: It does mean that Win32API (or X11, for that matter) headers must be #include'd before jpeglib.h. Before I spin a new release, could you test if this works with

Re: [64bit] type conflict for INT32

2013-04-12 Thread Ken Brown
On 4/12/2013 11:07 AM, Corinna Vinschen wrote: On Apr 12 10:24, Ken Brown wrote: On 4/12/2013 10:04 AM, Charles Wilson wrote: On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote: It does mean that Win32API (or X11, for that matter) headers must be #include'd before jpeglib.h. Before I spin a new

Re: 64bit: cygstdc++-6.dll

2013-04-12 Thread Corinna Vinschen
Dave? Ping? On Apr 11 15:37, Corinna Vinschen wrote: On Apr 11 12:16, Corinna Vinschen wrote: On Apr 10 18:16, Corinna Vinschen wrote: On Apr 10 16:49, Dave Korn wrote: On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote: Could you explain the necessity of the dllimport's in the

64 bit Cygwin 1.7.18-19

2013-04-12 Thread Corinna Vinschen
Hi again kiddies, I'm just uploading the 64 bit cygwin 1.7.18-19 package. While testing something ugly with sockets, I accidentally stumbled over another bug based on the size difference between DWORD and {s}size_t. I fixed that a couple of days ago for recv/send and most of read/write, but I

Re: GCC-4.7.2-2: Go/No-go?

2013-04-12 Thread Dave Korn
On 12/04/2013 11:44, Yaakov (Cygwin/X) wrote: On 2013-04-11 23:24, Dave Korn wrote: Most of the discussed features are already in the latest release. Right now, the major difference between the release and git master is full support for x86_64-pc-cygwin, but there are a number of other

Re: 64bit: cygstdc++-6.dll

2013-04-12 Thread Dave Korn
On 12/04/2013 16:57, Corinna Vinschen wrote: Dave? Ping? Heh, don't panic, I'm still here! Just needed some sleep :) On Apr 11 15:37, Corinna Vinschen wrote: On Apr 11 12:16, Corinna Vinschen wrote: On Apr 10 18:16, Corinna Vinschen wrote: On Apr 10 16:49, Dave Korn wrote: On

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

2013-04-12 Thread Andy Koppe
On 11 April 2013 23:37, Yaakov (Cygwin/X) wrote: On 2013-04-11 07:37, Charles Wilson wrote: #2) Is it possible to use the auto-setup.hint-generator functionality for multi-part package sets (e.g. which contain multiple separate tarballs, in addition to -src and -debuginfo)? If so, how? Yes;