Re: a.out.h for 64-bit Cygwin?
On 3/10/2013 4:52 PM, Corinna Vinschen wrote:
On Mar 10 09:06, Ken Brown wrote:
On 3/10/2013 7:18 AM, Corinna Vinschen wrote:
On Mar 9 22:43, Ken Brown wrote:
It may be too soon to expect this to work, but I'm trying to build
emacs for 64-bit Cygwin. Part of the build process involves direct
manipulation of a .exe file, based on the structures defined in
/usr/include/a.out.h. I'm wondering whether this file needs to be
updated before it will work with 64-bit .exe files.
Yes, absolutely!
It's not very tricky. AFAIK only a single header part is different, the
one called IMAGE_OPTIONAL_HEADER in MSDN. Given the age of a.out.h,
there are also a couple of defines missing, all of them are documented
in MSDN and available in the Mingw headers. Patches most welcome.
OK, I'll work on this. One question: Is it OK for a.out.h to
include windows.h so that I can use macros like WORD, DWORD,... as
in the Mingw headers? Or is it better to just use standard types as
in the current a.out.h?
No, we shouldn't include windows.h. Some of the values are already
defined using another name in a.out.h, see I386MAGIC, DOSMAGIC, or
NT_SIGNATURE.
I'm pretty open to add definitions for other values, as long as they
either match the already used naimg scheme, or, if they are entirely
new, are similar, but not exactly named like the original Windows
definitions. I don't think anything speaks against adding stuff like
#define AMD64MAGIC 0x8664
[...]
#define IMG_NT_OPTIONAL_HDR32_MAGIC 0x10b
[...]
#define IMG_SUBSYS_NATIVE 1
OK, my patch is attached. I'm also attaching the program I used to test
it, based on the emacs code I sent in my first post. (And I'm able to
build 64-bit emacs with this patch.)
It turned out that the most important thing I had to do was change most
occurrences of unsigned long to uint32_t to keep DWORDs from
becoming 64 bits wide on AMD64.
Ken
#include stdio.h
#include unistd.h
#include assert.h
#include fcntl.h
#include a.out.h
typedef struct
{
FILHDR file_header;
PEAOUTHDR file_optional_header;
SCNHDR section_header[32];
} exe_header_t;
static exe_header_t *
read_exe_header (int fd, exe_header_t * exe_header_buffer)
{
int i;
int ret;
assert (exe_header_buffer != 0);
ret = lseek (fd, 0L, SEEK_SET);
assert (ret != -1);
ret =
read (fd, exe_header_buffer-file_header,
sizeof (exe_header_buffer-file_header));
assert (ret == sizeof (exe_header_buffer-file_header));
assert (exe_header_buffer-file_header.e_magic == 0x5a4d);
assert (exe_header_buffer-file_header.nt_signature == 0x4550);
#ifdef __x86_64__
assert (exe_header_buffer-file_header.f_magic == 0x8664);
#else
assert (exe_header_buffer-file_header.f_magic == 0x014c);
#endif
assert (exe_header_buffer-file_header.f_nscns 0);
assert (exe_header_buffer-file_header.f_nscns =
sizeof (exe_header_buffer-section_header) /
sizeof (exe_header_buffer-section_header[0]));
assert (exe_header_buffer-file_header.f_opthdr 0);
ret =
read (fd, exe_header_buffer-file_optional_header,
sizeof (exe_header_buffer-file_optional_header));
assert (ret == sizeof (exe_header_buffer-file_optional_header));
#ifdef __x86_64__
assert (exe_header_buffer-file_optional_header.magic == 0x020b);
#else
assert (exe_header_buffer-file_optional_header.magic == 0x010b);
#endif
for (i = 0; i exe_header_buffer-file_header.f_nscns; ++i)
{
ret =
read (fd, exe_header_buffer-section_header[i],
sizeof (exe_header_buffer-section_header[i]));
assert (ret == sizeof (exe_header_buffer-section_header[i]));
}
return (exe_header_buffer);
}
int
main ()
{
int fd;
exe_header_t exe_header_buffer;
printf (Type PEAOUTHDR has size %u bytes.\n, sizeof (PEAOUTHDR));
fd = open (/bin/ls.exe, O_RDONLY);
assert (fd = 0);
read_exe_header (fd, exe_header_buffer);
}
--- a.out.h.orig2013-03-11 05:25:59.339893700 -0400
+++ a.out.h 2013-03-11 12:03:48.509132100 -0400
@@ -1,6 +1,6 @@
/* a.out.h
- Copyright 1997, 1998, 1999, 2001 Red Hat, Inc.
+ Copyright 1997, 1998, 1999, 2001, 2013 Red Hat, Inc.
This file is part of Cygwin.
@@ -14,10 +14,13 @@
#ifdef __cplusplus
extern C {
#endif
+
+#include stdint.h
+
#define COFF_IMAGE_WITH_PE
#define COFF_LONG_SECTION_NAMES
-/*** coff information for Intel 386/486. */
+/*** coff information for Intel 386/486 and AMD64. */
/** FILE HEADER **/
@@ -25,9 +28,9 @@
struct external_filehdr {
short f_magic; /* magic number */
short f_nscns; /* number of sections */
- unsigned long f_timdat; /* time date stamp*/
- unsigned long f_symptr; /* file pointer to symtab */
- unsigned long f_nsyms; /* number of symtab entries */
+ uint32_t f_timdat; /* time date stamp*/
+ uint32_t f_symptr; /* file pointer to symtab */
+
Re: a.out.h for 64-bit Cygwin?
On Mar 11 12:13, Ken Brown wrote:
On 3/10/2013 4:52 PM, Corinna Vinschen wrote:
No, we shouldn't include windows.h. Some of the values are already
defined using another name in a.out.h, see I386MAGIC, DOSMAGIC, or
NT_SIGNATURE.
I'm pretty open to add definitions for other values, as long as they
either match the already used naimg scheme, or, if they are entirely
new, are similar, but not exactly named like the original Windows
definitions. I don't think anything speaks against adding stuff like
#define AMD64MAGIC 0x8664
[...]
#define IMG_NT_OPTIONAL_HDR32_MAGIC 0x10b
[...]
#define IMG_SUBSYS_NATIVE 1
OK, my patch is attached. I'm also attaching the program I used to
test it, based on the emacs code I sent in my first post. (And I'm
able to build 64-bit emacs with this patch.)
It turned out that the most important thing I had to do was change
most occurrences of unsigned long to uint32_t to keep DWORDs
from becoming 64 bits wide on AMD64.
Ken
Hi Ken. Thanks for the patch, but I guess you misunderstood me
concerning the names of the defines:
#define I386MAGIC 0x14c
#define I386PTXMAGIC 0x154
#define I386AIXMAGIC 0x175
+#define IMAGE_FILE_MACHINE_I386 0x014c
+#define IMAGE_FILE_MACHINE_AMD64 0x8664
+#define IMAGE_NT_OPTIONAL_HDR32_MAGIC 0x10b
+#define IMAGE_NT_OPTIONAL_HDR64_MAGIC 0x20b
+#define IMAGE_SIZEOF_STD_OPTIONAL_HEADER 28
+#define IMAGE_SIZEOF_NT_OPTIONAL32_HEADER 224
+#define IMAGE_SIZEOF_NT_OPTIONAL64_HEADER 240
+#define IMAGE_SUBSYSTEM_NATIVE 1
+#define IMAGE_SUBSYSTEM_WINDOWS_GUI 2
+#define IMAGE_SUBSYSTEM_WINDOWS_CUI 3
The idea was to use names different from the original Windows defines.
IMAGE_FILE_MACHINE_I386 already exists as I386MAGIC, so the AMD64
definition should follow the lead:
#define AMD64MAGIC 0x8664
And the IMAGE_foo definitions would collide with Windows if the
Windows headers are included as well, so we should better use
IMG_foo rather than IMAGE_foo.
The rest of the patch looks good to me. I'm just wondering what to
do with the mix of `unsigned {short,long}' and uint32_t. Wouldn't
it be better if we replace all unsigned short with uint16_t and all
unsigned long with uintptr_t?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
Re: a.out.h for 64-bit Cygwin?
On Mar 11 18:43, Corinna Vinschen wrote:
On Mar 11 12:13, Ken Brown wrote:
OK, my patch is attached. I'm also attaching the program I used to
test it, based on the emacs code I sent in my first post. (And I'm
able to build 64-bit emacs with this patch.)
It turned out that the most important thing I had to do was change
most occurrences of unsigned long to uint32_t to keep DWORDs
from becoming 64 bits wide on AMD64.
Ken
Hi Ken. Thanks for the patch, but I guess you misunderstood me
concerning the names of the defines:
#defineI386MAGIC 0x14c
#define I386PTXMAGIC 0x154
#define I386AIXMAGIC 0x175
+#define IMAGE_FILE_MACHINE_I386 0x014c
+#define IMAGE_FILE_MACHINE_AMD64 0x8664
+#define IMAGE_NT_OPTIONAL_HDR32_MAGIC 0x10b
+#define IMAGE_NT_OPTIONAL_HDR64_MAGIC 0x20b
+#define IMAGE_SIZEOF_STD_OPTIONAL_HEADER 28
+#define IMAGE_SIZEOF_NT_OPTIONAL32_HEADER 224
+#define IMAGE_SIZEOF_NT_OPTIONAL64_HEADER 240
+#define IMAGE_SUBSYSTEM_NATIVE 1
+#define IMAGE_SUBSYSTEM_WINDOWS_GUI 2
+#define IMAGE_SUBSYSTEM_WINDOWS_CUI 3
The idea was to use names different from the original Windows defines.
IMAGE_FILE_MACHINE_I386 already exists as I386MAGIC, so the AMD64
definition should follow the lead:
#define AMD64MAGIC 0x8664
And the IMAGE_foo definitions would collide with Windows if the
Windows headers are included as well, so we should better use
IMG_foo rather than IMAGE_foo.
The rest of the patch looks good to me. I'm just wondering what to
do with the mix of `unsigned {short,long}' and uint32_t. Wouldn't
it be better if we replace all unsigned short with uint16_t and all
unsigned long with uintptr_t?
If that's not clear, I mean the unsigned long's which are still unsigned
long after your patch, because they are 32 bit on i686 and 64 bit on
x86_64...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
Re: a.out.h for 64-bit Cygwin?
On 3/11/2013 1:43 PM, Corinna Vinschen wrote:
On Mar 11 12:13, Ken Brown wrote:
On 3/10/2013 4:52 PM, Corinna Vinschen wrote:
No, we shouldn't include windows.h. Some of the values are already
defined using another name in a.out.h, see I386MAGIC, DOSMAGIC, or
NT_SIGNATURE.
I'm pretty open to add definitions for other values, as long as they
either match the already used naimg scheme, or, if they are entirely
new, are similar, but not exactly named like the original Windows
definitions. I don't think anything speaks against adding stuff like
#define AMD64MAGIC 0x8664
[...]
#define IMG_NT_OPTIONAL_HDR32_MAGIC 0x10b
[...]
#define IMG_SUBSYS_NATIVE 1
OK, my patch is attached. I'm also attaching the program I used to
test it, based on the emacs code I sent in my first post. (And I'm
able to build 64-bit emacs with this patch.)
It turned out that the most important thing I had to do was change
most occurrences of unsigned long to uint32_t to keep DWORDs
from becoming 64 bits wide on AMD64.
Ken
Hi Ken. Thanks for the patch, but I guess you misunderstood me
concerning the names of the defines:
Yes, I did misunderstand. Re-reading what you wrote, it was quite clear.
The rest of the patch looks good to me. I'm just wondering what to
do with the mix of `unsigned {short,long}' and uint32_t. Wouldn't
it be better if we replace all unsigned short with uint16_t and all
unsigned long with uintptr_t?
Yes, that's much better. I also changed a couple of occurrences of
`short' (without `unsigned') that should have been unsigned to begin with.
A revised patch is attached.
Ken
--- a.out.h.orig2013-03-11 05:25:59.339893700 -0400
+++ a.out.h 2013-03-11 15:05:56.968204200 -0400
@@ -1,6 +1,6 @@
/* a.out.h
- Copyright 1997, 1998, 1999, 2001 Red Hat, Inc.
+ Copyright 1997, 1998, 1999, 2001, 2013 Red Hat, Inc.
This file is part of Cygwin.
@@ -14,22 +14,25 @@
#ifdef __cplusplus
extern C {
#endif
+
+#include stdint.h
+
#define COFF_IMAGE_WITH_PE
#define COFF_LONG_SECTION_NAMES
-/*** coff information for Intel 386/486. */
+/*** coff information for Intel 386/486 and AMD64. */
/** FILE HEADER **/
struct external_filehdr {
- short f_magic; /* magic number */
- short f_nscns; /* number of sections */
- unsigned long f_timdat; /* time date stamp*/
- unsigned long f_symptr; /* file pointer to symtab */
- unsigned long f_nsyms; /* number of symtab entries */
- short f_opthdr; /* sizeof(optional hdr) */
- short f_flags; /* flags*/
+ uint16_t f_magic;/* magic number */
+ uint16_t f_nscns;/* number of sections */
+ uint32_t f_timdat; /* time date stamp*/
+ uint32_t f_symptr; /* file pointer to symtab */
+ uint32_t f_nsyms;/* number of symtab entries */
+ uint16_t f_opthdr; /* sizeof(optional hdr) */
+ uint16_t f_flags;/* flags*/
};
/* Bits for f_flags:
@@ -50,6 +53,16 @@
#defineI386MAGIC 0x14c
#define I386PTXMAGIC 0x154
#define I386AIXMAGIC 0x175
+#define AMD64MAGIC 0x8664
+
+#define IMG_NT_OPTIONAL_HDR32_MAGIC 0x10b
+#define IMG_NT_OPTIONAL_HDR64_MAGIC 0x20b
+#define IMG_SIZEOF_STD_OPTIONAL_HEADER 28
+#define IMG_SIZEOF_NT_OPTIONAL32_HEADER 224
+#define IMG_SIZEOF_NT_OPTIONAL64_HEADER 240
+#define IMG_SUBSYSTEM_NATIVE 1
+#define IMG_SUBSYSTEM_WINDOWS_GUI 2
+#define IMG_SUBSYSTEM_WINDOWS_CUI 3
/* This is Lynx's all-platform magic number for executables. */
@@ -70,14 +83,14 @@
typedef struct
{
- unsigned short magic;/* type of file
*/
- unsigned short vstamp; /* version stamp*/
- unsigned longtsize; /* text size in bytes, padded to FW
bdry*/
- unsigned longdsize; /* initialized data
*/
- unsigned longbsize; /* uninitialized data
*/
- unsigned longentry; /* entry pt.
*/
- unsigned long text_start;/* base of text used for this file */
- unsigned long data_start;/* base of data used for this file=
+ uint16_t magic; /* type of file */
+ uint16_t vstamp; /* version stamp*/
+ uint32_t tsize; /* text size in bytes, padded to FW bdry*/
+ uint32_t dsize; /* initialized data */
+ uint32_t bsize; /* uninitialized data */
+ uint32_t entry; /* entry pt.*/
+ uint32_t text_start; /* base of text used for this file */
+ uint32_t data_start; /* base of data used for this file=
*/
}
AOUTHDR;
@@ -103,16 +116,16 @@
struct external_scnhdr {
Re: GCC 4.7 and dependencies
On 11/03/2013 23:40, Yaakov (Cygwin/X) wrote: JonY, Achim, and others, I have updated .cygport and patch files for GCC and its dependencies: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc I'm trying to look at this, but all I get is errors: $ git clone git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/gcc4 Cloning into gcc4... fatal: The remote end hung up unexpectedly $ Is there something wrong with the format of the git: URL I'm using? cheers, DaveK
Re: [ITA] mpfr (libmpfr-devel / libmpfr4)
On 10/03/2013 15:43, Achim Gratz wrote: - TLS disabled since it doesn't work with current gcc I just debugged that over on the mpfr list. It can be made to work by adding LDFLAGS=-shared-libgcc to your configure line. (I'm going to patch upstream GCC to make that the default, and I'm also rolling a 4.7.2-2 with that patch included.) cheers, DaveK
Re: GCC 4.7 and dependencies
On Tue, 12 Mar 2013 00:57:45 +, Dave Korn wrote: I have updated .cygport and patch files for GCC and its dependencies: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc I'm trying to look at this, but all I get is errors: $ git clone git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/gcc4 That was a typo in gitweb; the correct URL is: git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/gcc Yaakov
Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On Sun, 10 Mar 2013 16:36:05 +0100, Achim Gratz wrote: Packages orphaned by David Billinghurst. - no update due to compatibility issues with existing applications GCC 4.8 uses isl/cloog-isl for Graphite, which require GMP 5.x. So we need to update now; packages which depend on libgmp3 will be rebuilt in due course. Can you please spin 5.1.1 instead and rebuild the other packages? Yaakov
Re: [ITA] mpclib (mpclib-devel / libmpc1 / libmpc3)
On Sun, 10 Mar 2013 16:50:04 +0100, Achim Gratz wrote: - provide libmpc1 for compatibility with existing packages (the old package pinned the library version to -1 even though the API version was -3), the actual library content is identical This was a mistake then; please don't propagate it any further. libmpc1 should be left as is, and will be able to be removed from the distro once all cross-GCCs are updated. Yaakov
Re: GCC 4.7 and dependencies
On Mon, 11 Mar 2013 18:40:55 -0500, Yaakov (Cygwin/X) wrote: JonY, Achim, and others, I have updated .cygport and patch files for GCC and its dependencies: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc I forgot to mention that this requires cygport git master. Yaakov
[ANNOUNCEMENT] Updated: xorg-server-1.13.3-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.13.3-1 These packages contain XWin and the other X.Org X11 servers. There are no cygwin-specific changes in addition to the upstream fixes [1][2] since 1.13.2-1. a4313eee43692ad211c65c08778934dc *xorg-server-1.13.3-1.tar.bz2 d2f2bd5910cf6beeb78ace8e387f7ae2 *xorg-server-1.13.3-1-src.tar.bz2 301350ad8279f21330e4599ae04e4a3e *xorg-server-common-1.13.3-1.tar.bz2 ce64627c5c182f1deb826b4a2ee7e8a2 *xorg-server-debuginfo-1.13.3-1.tar.bz2 595b7e7b1ba17b905f3c34221b071f2d *xorg-server-devel-1.13.3-1.tar.bz2 084d2a21ea4fdca58485e74b3224ed39 *xorg-server-dmx-1.13.3-1.tar.bz2 ab320fa123ee1579e686311f3dc8a46e *xorg-server-extra-1.13.3-1.tar.bz2 6688ed291ccf70bdb164498e00ea5ba9 *xserver-cygwin-1.13.3-1.tar.bz2 [1] http://lists.x.org/archives/xorg-announce/2013-February/002173.html [2] http://lists.x.org/archives/xorg-announce/2013-February/002178.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog cygtls.h exceptions.cc
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2013-03-11 08:59:19 Modified files: winsup/cygwin : ChangeLog cygtls.h exceptions.cc Log message: Pull in changes from HEAD Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.5939.2.59r2=1.5939.2.60 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygtls.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.80.2.15r2=1.80.2.16 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/exceptions.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.391.2.21r2=1.391.2.22
src/winsup/cygwin ChangeLog.64bit gendef
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2013-03-11 11:37:51 Modified files: winsup/cygwin : ChangeLog.64bit gendef Log message: * gendef: Add SEH information to sigfe entry points, as well as to _sigfe and _sigbe. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.64bit.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.1.2.121r2=1.1.2.122 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/gendef.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.41.2.14r2=1.41.2.15
src/winsup/cygwin ChangeLog.64bit fhandler.cc
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2013-03-11 16:30:44 Modified files: winsup/cygwin : ChangeLog.64bit fhandler.cc Log message: * fhandler.cc (fhandler_base::raw_read): Replace accidentally left in Win32 error codes with equivalent status codes. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.64bit.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.1.2.123r2=1.1.2.124 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.428.2.9r2=1.428.2.10
Re: deadlock with busy waiting on sigfe
On 2013-01-20 PM 3:54, Christopher Faylor wrote: On Sun, Jan 20, 2013 at 02:23:23PM +0900, jojelino wrote: Once again: don't care about your backtraces. Submit a proper bug report. cgf And found another livelock with CYGWIN_NT-5.2 F8G6S6D42HGDY4 1.7.18s(0.263/5/3) 20130309 21:57:01 i686 Cygwin provided in http://cygwin.org/snapshots/cygwin1-20130309.dll.bz2 I can't submit proper bug report. it just hangs during CTRL+C for arbitrary cygwin executable and there is nothing i can do except dumping backtrace. If you don't care about it, it's ok to ignore this. please pass by. Thread 2 (Thread 7596.0x104): #0 0x7c96845c in ntdll!KiFastSystemCallRet () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c9678c9 in ntdll!ZwSetInformationThread () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c8324f9 in SetThreadPriority () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x6108790d in yield () at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/miscfuncs.cc:253 #4 0x610d7354 in _cygtls::lock() () from /usr/bin/cygwin1.dll #5 0x6103096e in sigpacket::setup_handler (this=0x6aac34, handler=0x6102fe00 signal_exit(int, siginfo_t*), siga=..., tls=0x22ce64) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:796 #6 0x610318ff in sigpacket::process (this=0x6aac34) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:1245 ---Type return to continue, or q return to quit--- #7 0x610dd74c in wait_sig () at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/sigproc.cc:1389 #8 0x61003ea5 in cygthread::callfunc (this=0x6118b420 threads, issimplestub=optimized out) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygthread.cc:51 #9 0x6100442f in cygthread::stub (arg=0x6118b420 threads) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygthread.cc:93 #10 0x6100537d in _cygtls::call2 (this=optimized out, func=0x610043e0 cygthread::stub(void*), arg=0x6118b420 threads, buf=0x6100551b _cygtls::call(unsigned long (*)(void*, void*), void*)+91) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygtls.cc:99 #11 0x006affb8 in ?? () #12 0x7c82484f in KERNEL32!GetModuleHandleA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #13 0x in ?? () Thread 1 (Thread 7596.0x190): #0 0x7c96845c in ntdll!KiFastSystemCallRet () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c9678c9 in ntdll!ZwSetInformationThread () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c8324f9 in SetThreadPriority () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x610878cb in yield () ---Type return to continue, or q return to quit--- at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/miscfuncs.cc:244 #4 0x610d7354 in _cygtls::lock() () from /usr/bin/cygwin1.dll #5 0x61031297 in _cygtls::call_signal_handler ( this=0x610d7354 _cygtls::lock()+23) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:1265 #6 0x61007689 in _cygwin_exit_return () at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/dcrt0.cc:1012 #7 0x6100537d in _cygtls::call2 (this=optimized out, func=0x61006c50 dll_crt0_1(void*), arg=0x0, buf=0x6100551b _cygtls::call(unsigned long (*)(void*, void*), void*)+91) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygtls.cc:99 #8 0x0022ff78 in ?? () #9 0x004011d2 in ?? () #10 0x00401015 in ?? () #11 0x7c82f243 in ProcessIdToSessionId () from /cygdrive/c/WINDOWS/system32/kernel32.dll -- Regards. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: getting the right setup.bz2
If you just want to download all the packages to a local directory and install from there, you don't need a setup.ini (setup.bz2) file. THat's good news. However, it seems to lead to the packages being lumped under Misc as I said earlier. This would seem to make deselection by groups of packages impossible, so is there a way to bring back the hierarchy in a way that finds the files as well? Paul King Actually, I found a way to coax group selection/deselection in a certain way, and that was using the search feature in package selection. I still end up with a lot more stuff than I intended in the distro. It installed overnight and it is has just stopped installing after 7 hours or so (mostly due to postinstall, I'm guessing). Paul -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Standardizing installs
Greetings. I am getting some help at work (finally!), and need to be able to install cygwin on multiple machines, the same way each time. Is there a way to tell setup which packages to install so I don't have to go through the whole list each time, comparing it with the one on my box? Any help would be very much appreciated (especially if I can somehow create a setup file from my install instead of having to go through it manually :-). Thanks, Richard. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Standardizing installs
On 3/11/2013 8:08 PM, Richard Gribble wrote: Greetings. I am getting some help at work (finally!), and need to be able to install cygwin on multiple machines, the same way each time. Is there a way to tell setup which packages to install so I don't have to go through the whole list each time, comparing it with the one on my box? Any help would be very much appreciated (especially if I can somehow create a setup file from my install instead of having to go through it manually :-). Thanks, Richard. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Check the cygwin faq for automated install. http://cygwin.com/faq-nochunks.html#faq.setup.automated If you want to dump all the packages you have installed, try cygcheck -c. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: X11 capturing DISPLAY value
On 10/03/2013 22:17, wynfi...@gmail.com wrote: I wanted to capture the X11 DISPLAY value that shows on the console when 'startx ' in invoked and successful. I've tried: startx 21 | grep DISPLAY\= /tmp/xwin.txt startx 21 | grep DISPLAY /tmp/xwin.txt but neither worked. I could check files in /tmp/.X11-unix/* for date, owner, etc, and hope that the newest one is the right one and extract the number from the name, however if another user started an X window in the meantime I'd get the wrong DISPLAY v alue. Is there a preferred standard way to get this value? If you cannot explicitly specify a display number, I would say, use the '-displayfd' X server option [1], for example: xinit -- -displayfd 3 3~/.display export DISPLAY=:`cat ~/.display` Unfortunately, while this works with xinit, it seems there are bugs not noticed until now which prevents this from working correctly with startx (startx ends up supplying both :display and -displayfd, which doesn't work correctly, and the xauthority generated may reference the wrong display number, leaving clients unable to connect) [1] http://x.cygwin.com/docs/ug/using-terminal-server.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: deadlock with busy waiting on sigfe
On Mon, Mar 11, 2013 at 05:53:50PM +0900, jojelino wrote: On 2013-01-20 PM 3:54, Christopher Faylor wrote: On Sun, Jan 20, 2013 at 02:23:23PM +0900, jojelino wrote: Once again: don't care about your backtraces. Submit a proper bug report. cgf And found another livelock with CYGWIN_NT-5.2 F8G6S6D42HGDY4 1.7.18s(0.263/5/3) 20130309 21:57:01 i686 Cygwin provided in http://cygwin.org/snapshots/cygwin1-20130309.dll.bz2 I can't submit proper bug report. it just hangs during CTRL+C for arbitrary cygwin executable and there is nothing i can do except dumping backtrace. If you don't care about it, it's ok to ignore this. please pass by. A proper bug report would at least include what you were actually doing to trigger this problem. Are you sure that there are only two threads executing here? It seems like this is a symptom of another thread holding the lock. cgf Thread 2 (Thread 7596.0x104): #0 0x7c96845c in ntdll!KiFastSystemCallRet () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c9678c9 in ntdll!ZwSetInformationThread () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c8324f9 in SetThreadPriority () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x6108790d in yield () at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/miscfuncs.cc:253 #4 0x610d7354 in _cygtls::lock() () from /usr/bin/cygwin1.dll #5 0x6103096e in sigpacket::setup_handler (this=0x6aac34, handler=0x6102fe00 signal_exit(int, siginfo_t*), siga=..., tls=0x22ce64) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:796 #6 0x610318ff in sigpacket::process (this=0x6aac34) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:1245 ---Type return to continue, or q return to quit--- #7 0x610dd74c in wait_sig () at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/sigproc.cc:1389 #8 0x61003ea5 in cygthread::callfunc (this=0x6118b420 threads, issimplestub=optimized out) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygthread.cc:51 #9 0x6100442f in cygthread::stub (arg=0x6118b420 threads) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygthread.cc:93 #10 0x6100537d in _cygtls::call2 (this=optimized out, func=0x610043e0 cygthread::stub(void*), arg=0x6118b420 threads, buf=0x6100551b _cygtls::call(unsigned long (*)(void*, void*), void*)+91) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygtls.cc:99 #11 0x006affb8 in ?? () #12 0x7c82484f in KERNEL32!GetModuleHandleA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #13 0x in ?? () Thread 1 (Thread 7596.0x190): #0 0x7c96845c in ntdll!KiFastSystemCallRet () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c9678c9 in ntdll!ZwSetInformationThread () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c8324f9 in SetThreadPriority () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x610878cb in yield () ---Type return to continue, or q return to quit--- at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/miscfuncs.cc:244 #4 0x610d7354 in _cygtls::lock() () from /usr/bin/cygwin1.dll #5 0x61031297 in _cygtls::call_signal_handler ( this=0x610d7354 _cygtls::lock()+23) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:1265 #6 0x61007689 in _cygwin_exit_return () at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/dcrt0.cc:1012 #7 0x6100537d in _cygtls::call2 (this=optimized out, func=0x61006c50 dll_crt0_1(void*), arg=0x0, buf=0x6100551b _cygtls::call(unsigned long (*)(void*, void*), void*)+91) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygtls.cc:99 #8 0x0022ff78 in ?? () #9 0x004011d2 in ?? () #10 0x00401015 in ?? () #11 0x7c82f243 in ProcessIdToSessionId () from /cygdrive/c/WINDOWS/system32/kernel32.dll -- Regards. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why libquadmath0-4.7.2
On 05/03/2013 16:22, Christopher Faylor wrote: On Tue, Mar 05, 2013 at 05:11:34PM +0100, Angelo Graziosi wrote: I have GCC-4.5.3 installed and I am not going to install the test version 4.7.2-1, but setup.exe *wants* to install libquadmath0-4.7.2-1 even if I have selected Curr packages (which should exclude any reference to 4.7.2 version...). Have we sure it isn't a packaging bug? The crude dependency handling in setup.exe isn't up to the task of allowing per-version dependencies. So this probably came along because it's required for a newer version of gcc. When last we spoke (on the -apps list), it was suggested that the dependencies should remain correct for the curr: version, and people installing the test: version should manually install the required dependencies. If it would help, I could upload a 4.7.2-2 later tonight which restores java and has the original 4.5.3-3 dependencies? (Many thanks to JonY for stepping up to the plate while I've been away.) cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: deadlock with busy waiting on sigfe
On 2013-03-11 PM 11:36, Christopher Faylor wrote: A proper bug report would at least include what you were actually doing to trigger this problem. I was trying to CTRL+C cygwin python process that is executing some operation and fell asleep for 60 seconds repeatedly. I'm pretty sure that the process was sleeping as i tried interrupt it. Are you sure that there are only two threads executing here? It seems like this is a symptom of another thread holding the lock. It's unlikely the case because there was two thread running when livelock observed. cgf Thread 2 (Thread 7596.0x104): #0 0x7c96845c in ntdll!KiFastSystemCallRet () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c9678c9 in ntdll!ZwSetInformationThread () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c8324f9 in SetThreadPriority () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x6108790d in yield () at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/miscfuncs.cc:253 #4 0x610d7354 in _cygtls::lock() () from /usr/bin/cygwin1.dll #5 0x6103096e in sigpacket::setup_handler (this=0x6aac34, handler=0x6102fe00 signal_exit(int, siginfo_t*), siga=..., tls=0x22ce64) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:796 #6 0x610318ff in sigpacket::process (this=0x6aac34) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:1245 ---Type return to continue, or q return to quit--- #7 0x610dd74c in wait_sig () at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/sigproc.cc:1389 #8 0x61003ea5 in cygthread::callfunc (this=0x6118b420 threads, issimplestub=optimized out) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygthread.cc:51 #9 0x6100442f in cygthread::stub (arg=0x6118b420 threads) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygthread.cc:93 #10 0x6100537d in _cygtls::call2 (this=optimized out, func=0x610043e0 cygthread::stub(void*), arg=0x6118b420 threads, buf=0x6100551b _cygtls::call(unsigned long (*)(void*, void*), void*)+91) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygtls.cc:99 #11 0x006affb8 in ?? () #12 0x7c82484f in KERNEL32!GetModuleHandleA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #13 0x in ?? () Thread 1 (Thread 7596.0x190): #0 0x7c96845c in ntdll!KiFastSystemCallRet () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c9678c9 in ntdll!ZwSetInformationThread () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c8324f9 in SetThreadPriority () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x610878cb in yield () ---Type return to continue, or q return to quit--- at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/miscfuncs.cc:244 #4 0x610d7354 in _cygtls::lock() () from /usr/bin/cygwin1.dll #5 0x61031297 in _cygtls::call_signal_handler ( this=0x610d7354 _cygtls::lock()+23) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:1265 #6 0x61007689 in _cygwin_exit_return () at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/dcrt0.cc:1012 #7 0x6100537d in _cygtls::call2 (this=optimized out, func=0x61006c50 dll_crt0_1(void*), arg=0x0, buf=0x6100551b _cygtls::call(unsigned long (*)(void*, void*), void*)+91) at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygtls.cc:99 #8 0x0022ff78 in ?? () #9 0x004011d2 in ?? () #10 0x00401015 in ?? () #11 0x7c82f243 in ProcessIdToSessionId () from /cygdrive/c/WINDOWS/system32/kernel32.dll -- Regards. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Regards. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: deadlock with busy waiting on sigfe
On 2013-03-12 AM 4:35, jojelino wrote:
I was trying to CTRL+C cygwin python process that is executing some
operation and fell asleep for 60 seconds repeatedly. I'm pretty sure
that the process was sleeping as i tried interrupt it.
And some operation includes making connection to localhost tcp server
and sending some command to that. so another thread would be
mswsock!SockAsyncThread.
this case was very rare and i rarely saw the livelock except this time.
#! /usr/bin/python
from telnetlib import *
import re,sys,time,datetime
t=Telnet()
t.open('127.0.0.1','9051')
def burst(inp):
for e in inp.split('\n'):
prep=e
print prep
t.write (e+'\n')
ds=t.expect([re.compile('\n')])
print ds[2].strip()
#login for tor control protocol
burstcommand=
burst(burstcommand)
if len(sys.argv)1:
f=open(sys.argv[1],'r')
good=f.readline().split(',')
others=f.readline().split(',')
good=filter(lambda x:x not in others,good)
exclude=f.readline().split(',')
others=filter(lambda x:x not in exclude,others);
assert(len(good)0)
assert(len(others)0)
f.close()
else: raise Exception(list needed)
import random
cont=True
while cont:
for j in range(10):
if cont:
s=list()
if len(others)1:
xx=good[random.randint(0,len(good)-1)]
s.append(xx)
s.append(others.pop(random.randint(0,len(others)-1)))
else:
print 'others insufficient'
cont=False
break
if cont==True:
#print extendcircuit 0, ,.join(s)
burst(extendcircuit 0 {0}.format(,.join(s)))
else:
break
print =
time.sleep(60)
t.close()
--
Regards.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: deadlock with busy waiting on sigfe
On Tue, Mar 12, 2013 at 04:35:41AM +0900, jojelino wrote: On 2013-03-11 PM 11:36, Christopher Faylor wrote: A proper bug report would at least include what you were actually doing to trigger this problem. I was trying to CTRL+C cygwin python process that is executing some operation and fell asleep for 60 seconds repeatedly. I'm pretty sure that the process was sleeping as i tried interrupt it. Are you sure that there are only two threads executing here? It seems like this is a symptom of another thread holding the lock. It's unlikely the case because there was two thread running when livelock observed. How about if you humor me and do a show threads rather than just asserting that it was unlikely? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why libquadmath0-4.7.2
On 3/12/2013 02:03, Dave Korn wrote: On 05/03/2013 16:22, Christopher Faylor wrote: On Tue, Mar 05, 2013 at 05:11:34PM +0100, Angelo Graziosi wrote: I have GCC-4.5.3 installed and I am not going to install the test version 4.7.2-1, but setup.exe *wants* to install libquadmath0-4.7.2-1 even if I have selected Curr packages (which should exclude any reference to 4.7.2 version...). Have we sure it isn't a packaging bug? The crude dependency handling in setup.exe isn't up to the task of allowing per-version dependencies. So this probably came along because it's required for a newer version of gcc. When last we spoke (on the -apps list), it was suggested that the dependencies should remain correct for the curr: version, and people installing the test: version should manually install the required dependencies. If it would help, I could upload a 4.7.2-2 later tonight which restores java and has the original 4.5.3-3 dependencies? You'll be retaking maintainership again? I don't mind that, but please push as much of the patches as possible upstream, it was kind of hard to wrap my head around the patches to manually apply them. Thanks. signature.asc Description: OpenPGP digital signature
Re: Why libquadmath0-4.7.2
On Mon, Mar 11, 2013 at 06:03:08PM +, Dave Korn wrote: On 05/03/2013 16:22, Christopher Faylor wrote: On Tue, Mar 05, 2013 at 05:11:34PM +0100, Angelo Graziosi wrote: I have GCC-4.5.3 installed and I am not going to install the test version 4.7.2-1, but setup.exe *wants* to install libquadmath0-4.7.2-1 even if I have selected Curr packages (which should exclude any reference to 4.7.2 version...). Have we sure it isn't a packaging bug? The crude dependency handling in setup.exe isn't up to the task of allowing per-version dependencies. So this probably came along because it's required for a newer version of gcc. When last we spoke (on the -apps list), it was suggested that the dependencies should remain correct for the curr: version, and people installing the test: version should manually install the required dependencies. Dave, I've pinged you on the -apps list and you haven't responded. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why libquadmath0-4.7.2
On 11/03/2013 23:21, Christopher Faylor wrote: On Mon, Mar 11, 2013 at 06:03:08PM +, Dave Korn wrote: On 05/03/2013 16:22, Christopher Faylor wrote: On Tue, Mar 05, 2013 at 05:11:34PM +0100, Angelo Graziosi wrote: I have GCC-4.5.3 installed and I am not going to install the test version 4.7.2-1, but setup.exe *wants* to install libquadmath0-4.7.2-1 even if I have selected Curr packages (which should exclude any reference to 4.7.2 version...). Have we sure it isn't a packaging bug? The crude dependency handling in setup.exe isn't up to the task of allowing per-version dependencies. So this probably came along because it's required for a newer version of gcc. When last we spoke (on the -apps list), it was suggested that the dependencies should remain correct for the curr: version, and people installing the test: version should manually install the required dependencies. Dave, I've pinged you on the -apps list and you haven't responded. How recently? I've got a backlog of 2400 unread mails there (and 8682 mails here). Yes, I've been away, but I can now commit to being back on the case; the project I've been working on for the past god-knows-how-long is done. I've already got back to work on upstream GCC and would like to get back to work on Cygwin. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why libquadmath0-4.7.2
On 11/03/2013 22:12, JonY wrote: On 3/12/2013 02:03, Dave Korn wrote: On 05/03/2013 16:22, Christopher Faylor wrote: On Tue, Mar 05, 2013 at 05:11:34PM +0100, Angelo Graziosi wrote: I have GCC-4.5.3 installed and I am not going to install the test version 4.7.2-1, but setup.exe *wants* to install libquadmath0-4.7.2-1 even if I have selected Curr packages (which should exclude any reference to 4.7.2 version...). Have we sure it isn't a packaging bug? The crude dependency handling in setup.exe isn't up to the task of allowing per-version dependencies. So this probably came along because it's required for a newer version of gcc. When last we spoke (on the -apps list), it was suggested that the dependencies should remain correct for the curr: version, and people installing the test: version should manually install the required dependencies. If it would help, I could upload a 4.7.2-2 later tonight which restores java and has the original 4.5.3-3 dependencies? You'll be retaking maintainership again? I don't mind that, but please push as much of the patches as possible upstream, it was kind of hard to wrap my head around the patches to manually apply them. I would like to resume maintaining it, subject to any discussions necessary. Being an upstream maintainer makes it easier for me to push patches. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
