Re: Newbie needs help using mingw with cygwin
On Tue, May 06, 2008 at 06:49:06PM -0700, Brian Dessent wrote: If you really want to use Cygwin as a host to build MinGW (native windows) programs you need to treat it like cross compiling and specify --host=i686-pc-mingw32. But this is most likely NOT what you intended to accomplish at all in this case. Hi Brian, I've been wondering about this. Why is it necessary to cross-compile from cygwin to mingw when the cygwin environment has the native mingw compiler? To me, it seems like if the mingw compiler is capable of running in the build environment, it should just be called and work. Is the cygwin mingw compiler a cross compiler? or is it the actual native mingw compiler? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SIGTSTP and select
On Fri, Apr 13, 2007 at 03:25:01PM +0200, Corinna Vinschen wrote:
On Apr 3 10:13, Bob Rossi wrote:
On Mon, Apr 02, 2007 at 08:37:53PM -0400, Christopher Faylor wrote:
On Mon, Apr 02, 2007 at 08:07:23PM -0400, Bob Rossi wrote:
When ctrl-z is typed, CGDB receives a SIGTSTP on both linux and cygwin.
When CGDB is at the select loop and this happens on linux select returns
-1 and errno is set to EINTR. My code simple does a 'continue' when this
happens and the select loop is reentered. All works well. On cygwin,
select does not return with -1. (I didn't check the return value but I
can, I just compare to -1 in an if statement). In fact, select also
detects that input is ready on stdin. This causes CGDB to get to a read
system call (which is non blocking) and the read system call fails with
errno set to EAGAIN. This causes CGDB to exit.
The main loop looks something like this,
if (select (max + 1, rset, NULL, NULL, NULL) == -1)
{
if (errno == EINTR)
continue;
..
}
if (FD_ISSET (STDIN_FILENO, rset)) {
handle_stdin
}
So, my question is, is there a bug with select on cygwin? Is select
working properly and I should handle the read call differently? Why does
it act differently than linux?
You say that something changed between different releases but you don't
mention what those releases are. Is this releases of Cygwin? If so,
what releases?
If this is as easy to demonstrate as you say, then a simple test case
is definitely called for.
Hi Christopher,
Attached is the test case. If I run it under linux, and then type ctrl-z, I
never get into the user_input_loop call. If I run it in cygwin, I do.
Hopefully I'm doing something wrong here. Please advise!
I'm a bit puzzled. I don't see any difference in behaviour on Linux and
Cygwin related to your testcase. I have no problems to trigger the
user_input_loop call on Linux and Cygwin. After I press ctrl-z, I don't
get into it on both systems. After unsuspending the process, I get into
user_input_loop on both systems again. Either your testcase is wrong,
or you should exactly specify what has to be typed to trigger the
problem. I tested this with Cygwin 1.5.24 and Linux 2.6.20.5, btw.
Hi Corinna,
Thanks for testing this! I definately do not get the same results as
you. On ubuntu linux,
$ uname -a
Linux black 2.6.17-11-386 #2 Thu Feb 1 19:50:13 UTC 2007 i686
GNU/Linux
I'm running cygwin version 1.5.24 and have attached cygcheck.out.
I've modified the main program slightly to better show the problem.
On both platforms I do,
gcc -g main.c -o main
On cygwin when I type './main' and then I type 'ctrl-z', I see this,
$ ./main.exe
Select return value:1
In user_input_loop
On linux when I type './main' and then I type 'ctrl-z', I see this,
$ ./main
[1]+ Stopped ./main
$ fg
./main
In fact, I never see the user_input_loop on linux.
What's interesting and annoying is that when I tested this last time on
linux, I was sure that after the SIGTSTP was sent, the select loop
returned. The value of val was -1 and errno was EINTR and I did a
continue to the loop again. However, with the example I just posted, it
appears that linux never breaks free of the select loop. I am still
seeing a difference between linux and cygwin as shown above.
I'm curious to know if this is a programming error on my part or if it
is a bug in the select call on cygwin.
Thanks!
Bob Rossi
#include unistd.h
#include stdlib.h
#include stdio.h
#include sys/select.h
#include sys/ioctl.h
#include errno.h
#include termios.h
static struct termios term_attributes;
int
tty_cbreak (int fd, struct termios *orig)
{
struct termios buf;
if (tcgetattr (fd, buf) 0)
return -1;
/* Save the original state, for resetting later */
*orig = buf;
buf.c_lflag = ~(ECHO | ICANON);
buf.c_iflag = ~(ICRNL | INLCR);
buf.c_cc[VMIN] = 1;
buf.c_cc[VTIME] = 0;
#if defined (VLNEXT) defined (_POSIX_VDISABLE)
buf.c_cc[VLNEXT] = _POSIX_VDISABLE;
#endif
#if defined (VDSUSP) defined (_POSIX_VDISABLE)
buf.c_cc[VDSUSP] = _POSIX_VDISABLE;
#endif
if (tcsetattr (fd, TCSAFLUSH, buf) 0)
return -1;
return 0;
}
int
tty_set_attributes (int fd, struct termios *buf)
{
if (tcsetattr (fd, TCSAFLUSH, buf) 0)
return -1;
return 0;
}
int
user_input_loop ()
{
fprintf (stderr, In user_input_loop\r\n);
return 0;
}
static int
main_loop (void)
{
fd_set rset;
int max = STDIN_FILENO;
int val;
for (;;)
{
/* Reset the fd_set, and watch for input from GDB or stdin */
FD_ZERO (rset);
FD_SET (STDIN_FILENO, rset);
/* Wait for input */
val =select (max + 1, rset, NULL, NULL, NULL);
fprintf (stderr, Select return value:%d\r\n, val);
if (val == -1)
{
if (errno == EINTR)
continue;
else
Re: SIGTSTP and select
On Fri, Apr 13, 2007 at 03:25:01PM +0200, Corinna Vinschen wrote:
On Apr 3 10:13, Bob Rossi wrote:
On Mon, Apr 02, 2007 at 08:37:53PM -0400, Christopher Faylor wrote:
On Mon, Apr 02, 2007 at 08:07:23PM -0400, Bob Rossi wrote:
When ctrl-z is typed, CGDB receives a SIGTSTP on both linux and cygwin.
When CGDB is at the select loop and this happens on linux select returns
-1 and errno is set to EINTR. My code simple does a 'continue' when this
happens and the select loop is reentered. All works well. On cygwin,
select does not return with -1. (I didn't check the return value but I
can, I just compare to -1 in an if statement). In fact, select also
detects that input is ready on stdin. This causes CGDB to get to a read
system call (which is non blocking) and the read system call fails with
errno set to EAGAIN. This causes CGDB to exit.
The main loop looks something like this,
if (select (max + 1, rset, NULL, NULL, NULL) == -1)
{
if (errno == EINTR)
continue;
..
}
if (FD_ISSET (STDIN_FILENO, rset)) {
handle_stdin
}
So, my question is, is there a bug with select on cygwin? Is select
working properly and I should handle the read call differently? Why does
it act differently than linux?
You say that something changed between different releases but you don't
mention what those releases are. Is this releases of Cygwin? If so,
what releases?
If this is as easy to demonstrate as you say, then a simple test case
is definitely called for.
Hi Christopher,
Attached is the test case. If I run it under linux, and then type ctrl-z, I
never get into the user_input_loop call. If I run it in cygwin, I do.
Hopefully I'm doing something wrong here. Please advise!
I'm a bit puzzled. I don't see any difference in behaviour on Linux and
Cygwin related to your testcase. I have no problems to trigger the
user_input_loop call on Linux and Cygwin. After I press ctrl-z, I don't
get into it on both systems. After unsuspending the process, I get into
user_input_loop on both systems again. Either your testcase is wrong,
or you should exactly specify what has to be typed to trigger the
problem. I tested this with Cygwin 1.5.24 and Linux 2.6.20.5, btw.
Hmmm, maybe I don't understand cygwin well enough. Does it require me to
have CYGWIN=tty to have this functionality work properly?
If I use the exact same test case I just sent in, and set CYGWIN=tty, I
still get different results than on linux, but it seems better. On
cygwin, select returns with value -1 and errno set to EINTR. On
linux, as I just posted, that doesn't seem to happen.
Should I assume that if cygwin users want to use cgdb that they must set
CYGWIN=tty, or is that a bad assumption to make?
Thanks,
Bob Rossi
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: SIGTSTP and select
On Fri, Apr 13, 2007 at 04:51:36PM +0200, Corinna Vinschen wrote:
On Apr 13 10:01, Bob Rossi wrote:
On Fri, Apr 13, 2007 at 03:25:01PM +0200, Corinna Vinschen wrote:
On Mon, Apr 02, 2007 at 08:07:23PM -0400, Bob Rossi wrote:
When ctrl-z is typed, CGDB receives a SIGTSTP on both linux and
cygwin.
When CGDB is at the select loop and this happens on linux select
returns
-1 and errno is set to EINTR. My code simple does a 'continue' when
this
happens and the select loop is reentered. All works well. On cygwin,
select does not return with -1. (I didn't check the return value but
I
can, I just compare to -1 in an if statement). In fact, select also
detects that input is ready on stdin. This causes CGDB to get to a
read
system call (which is non blocking) and the read system call fails
with
errno set to EAGAIN. This causes CGDB to exit.
[...]
I'm a bit puzzled. I don't see any difference in behaviour on Linux and
Cygwin related to your testcase. I have no problems to trigger the
user_input_loop call on Linux and Cygwin. After I press ctrl-z, I don't
get into it on both systems. After unsuspending the process, I get into
user_input_loop on both systems again. Either your testcase is wrong,
or you should exactly specify what has to be typed to trigger the
problem. I tested this with Cygwin 1.5.24 and Linux 2.6.20.5, btw.
Hi Corinna,
Thanks for testing this! I definately do not get the same results as
you. On ubuntu linux,
$ uname -a
Linux black 2.6.17-11-386 #2 Thu Feb 1 19:50:13 UTC 2007 i686
GNU/Linux
I'm running cygwin version 1.5.24 and have attached cygcheck.out.
I've modified the main program slightly to better show the problem.
On both platforms I do,
gcc -g main.c -o main
On cygwin when I type './main' and then I type 'ctrl-z', I see this,
$ ./main.exe
Select return value:1
In user_input_loop
On linux when I type './main' and then I type 'ctrl-z', I see this,
$ ./main
[1]+ Stopped ./main
$ fg
./main
In fact, I never see the user_input_loop on linux.
What's interesting and annoying is that when I tested this last time on
linux, I was sure that after the SIGTSTP was sent, the select loop
returned. The value of val was -1 and errno was EINTR and I did a
continue to the loop again. However, with the example I just posted, it
appears that linux never breaks free of the select loop. I am still
seeing a difference between linux and cygwin as shown above.
I'm curious to know if this is a programming error on my part or if it
is a bug in the select call on cygwin.
Ok, there's a difference between tty and notty mode here. I can
reproduce this with notty, while I get a -1/EINTR with CYGWIN=tty.
This is a bit unfortunate difference which is probably a result of
different handling of console handles (notty) vs. pipe handles (tty).
I'm not sure how to fix that. Signals and select are rather Chris'
contruction lot.
OK, good that we see this now. Chris, what do you recommend? Is this
something that would be fixed in select?
While that's not a nice solution in the long run, it might be better
to ask the use to run cgdb with CYGWIN=tty for now (which is default
in remote sessions, that's why I couldn't reproduce anything first).
You could for instance add a cgdb wrapper script which always adds tty
to $CYGWIN and starts the cgdb binary.
I have a nasty change I could make to cgdb to make it work when notty is
set. I could change this,
if (FD_ISSET (STDIN_FILENO, rset)) {
if (user_input_loop () == -1)
return -1;
return 0;
}
to this,
if (FD_ISSET (STDIN_FILENO, rset)) {
int val = user_input_loop ();
if (val == -1) {
if (errno == EAGAIN)
continue;
else
return -1;
}
return 0;
}
That's because i get down to the user_input_loop, and then go do some
stuff, and then do a non blocking read call. It returns -1 and sets
errno to EAGAIN. However, this is a less than ideal hack.
When you observed -1/EINTR on Linux, did you install a SIGTSTP signal
handle, maybe?
That's possible. I don't currently install a handler for that with cgdb,
so, it's not really a big deal.
Thanks for your help,
Bob Rossi
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: SIGTSTP and select
On Fri, Apr 13, 2007 at 11:03:56AM -0400, Christopher Faylor wrote: Ok, there's a difference between tty and notty mode here. I can reproduce this with notty, while I get a -1/EINTR with CYGWIN=tty. This is a bit unfortunate difference which is probably a result of different handling of console handles (notty) vs. pipe handles (tty). I'm not sure how to fix that. Signals and select are rather Chris' contruction lot. I'm not in a position to test this right now but, if cygwin is in blocking mode, i.e., select is in an infinite wait, it should be possible to use CTRL-Z to suspend it. I will look into this once I have my computers put back together. OK, thank you. The test case easily reproduces this behavior. What I'm really wondering is if I should hold up a release of cgdb over this. I could do one of several things - wait to do a release until select is changed - tell the user to use CYGWIN=tty if they want to do ctrl-z - add my hack to fix this problem with the way things are The restart behaviour as you observed on Linux is not implemented for select in Cygwin so far. Only a few system calls actually implement this right now. You should always handle EINTR yourself, as your loop already does. While that's not a nice solution in the long run, it might be better to ask the use to run cgdb with CYGWIN=tty for now (which is default in remote sessions, that's why I couldn't reproduce anything first). You could for instance add a cgdb wrapper script which always adds tty to $CYGWIN and starts the cgdb binary. Or start gdb in a pty. Sorry, I'm not sure what you mean. If you are talking about the way cgdb starts gdb, yes, it uses a pty. However, the test case reproduces all of this without gdb being involved at all. Thanks again, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SIGTSTP and select
On Fri, Apr 13, 2007 at 04:51:36PM +0200, Corinna Vinschen wrote: On Apr 13 10:01, Bob Rossi wrote: On Fri, Apr 13, 2007 at 03:25:01PM +0200, Corinna Vinschen wrote: On Mon, Apr 02, 2007 at 08:07:23PM -0400, Bob Rossi wrote: When you observed -1/EINTR on Linux, did you install a SIGTSTP signal handle, maybe? Hi Corinna, Do you think that if I capture the SIGTSTP signal, I could avoid all of this? That is, I would somehow avoid the situation where select has to deal with being in the blocking state while cgdb recieves the signal? I'm not even sure if a process could put itself in the process after catching that signal, but if it could, ... Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SIGTSTP and select
On Thu, Apr 05, 2007 at 07:31:39PM -0400, Bob Rossi wrote: On Tue, Apr 03, 2007 at 10:42:39AM -0400, Bob Rossi wrote: On Tue, Apr 03, 2007 at 10:13:20AM -0400, Bob Rossi wrote: On Mon, Apr 02, 2007 at 08:37:53PM -0400, Christopher Faylor wrote: On Mon, Apr 02, 2007 at 08:07:23PM -0400, Bob Rossi wrote: So, my question is, is there a bug with select on cygwin? Is select working properly and I should handle the read call differently? Why does it act differently than linux? You say that something changed between different releases but you don't mention what those releases are. Is this releases of Cygwin? If so, what releases? If this is as easy to demonstrate as you say, then a simple test case is definitely called for. Hi Christopher, Attached is the test case. If I run it under linux, and then type ctrl-z, I never get into the user_input_loop call. If I run it in cygwin, I do. Hopefully I'm doing something wrong here. Please advise! Ouch. Attached. Any idea if this is a bug in cygwin? I'm considering if I should rework my code to handle this case... Ping. Just wondering what actions I should take. I would very much like to get a release of cgdb out this week. Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SIGTSTP and select
On Tue, Apr 03, 2007 at 10:42:39AM -0400, Bob Rossi wrote:
On Tue, Apr 03, 2007 at 10:13:20AM -0400, Bob Rossi wrote:
On Mon, Apr 02, 2007 at 08:37:53PM -0400, Christopher Faylor wrote:
On Mon, Apr 02, 2007 at 08:07:23PM -0400, Bob Rossi wrote:
I'm not exactly sure what has changed since the last release to cause
this issue. However, here it is.
When ctrl-z is typed, CGDB receives a SIGTSTP on both linux and cygwin.
When CGDB is at the select loop and this happens on linux select returns
-1 and errno is set to EINTR. My code simple does a 'continue' when this
happens and the select loop is reentered. All works well. On cygwin,
select does not return with -1. (I didn't check the return value but I
can, I just compare to -1 in an if statement). In fact, select also
detects that input is ready on stdin. This causes CGDB to get to a read
system call (which is non blocking) and the read system call fails with
errno set to EAGAIN. This causes CGDB to exit.
The main loop looks something like this,
if (select (max + 1, rset, NULL, NULL, NULL) == -1)
{
if (errno == EINTR)
continue;
..
}
if (FD_ISSET (STDIN_FILENO, rset)) {
handle_stdin
}
So, my question is, is there a bug with select on cygwin? Is select
working properly and I should handle the read call differently? Why does
it act differently than linux?
You say that something changed between different releases but you don't
mention what those releases are. Is this releases of Cygwin? If so,
what releases?
If this is as easy to demonstrate as you say, then a simple test case
is definitely called for.
Hi Christopher,
Attached is the test case. If I run it under linux, and then type ctrl-z, I
never get into the user_input_loop call. If I run it in cygwin, I do.
Hopefully I'm doing something wrong here. Please advise!
Ouch. Attached.
Any idea if this is a bug in cygwin?
I'm considering if I should rework my code to handle this case...
Thanks,
Bob Rossi
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: SIGTSTP and select
On Mon, Apr 02, 2007 at 08:37:53PM -0400, Christopher Faylor wrote:
On Mon, Apr 02, 2007 at 08:07:23PM -0400, Bob Rossi wrote:
I'm not exactly sure what has changed since the last release to cause
this issue. However, here it is.
When ctrl-z is typed, CGDB receives a SIGTSTP on both linux and cygwin.
When CGDB is at the select loop and this happens on linux select returns
-1 and errno is set to EINTR. My code simple does a 'continue' when this
happens and the select loop is reentered. All works well. On cygwin,
select does not return with -1. (I didn't check the return value but I
can, I just compare to -1 in an if statement). In fact, select also
detects that input is ready on stdin. This causes CGDB to get to a read
system call (which is non blocking) and the read system call fails with
errno set to EAGAIN. This causes CGDB to exit.
The main loop looks something like this,
if (select (max + 1, rset, NULL, NULL, NULL) == -1)
{
if (errno == EINTR)
continue;
..
}
if (FD_ISSET (STDIN_FILENO, rset)) {
handle_stdin
}
So, my question is, is there a bug with select on cygwin? Is select
working properly and I should handle the read call differently? Why does
it act differently than linux?
You say that something changed between different releases but you don't
mention what those releases are. Is this releases of Cygwin? If so,
what releases?
If this is as easy to demonstrate as you say, then a simple test case
is definitely called for.
Hi Christopher,
Attached is the test case. If I run it under linux, and then type ctrl-z, I
never get into the user_input_loop call. If I run it in cygwin, I do.
Hopefully I'm doing something wrong here. Please advise!
Thanks,
Bob Rossi
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: SIGTSTP and select
On Tue, Apr 03, 2007 at 10:13:20AM -0400, Bob Rossi wrote:
On Mon, Apr 02, 2007 at 08:37:53PM -0400, Christopher Faylor wrote:
On Mon, Apr 02, 2007 at 08:07:23PM -0400, Bob Rossi wrote:
I'm not exactly sure what has changed since the last release to cause
this issue. However, here it is.
When ctrl-z is typed, CGDB receives a SIGTSTP on both linux and cygwin.
When CGDB is at the select loop and this happens on linux select returns
-1 and errno is set to EINTR. My code simple does a 'continue' when this
happens and the select loop is reentered. All works well. On cygwin,
select does not return with -1. (I didn't check the return value but I
can, I just compare to -1 in an if statement). In fact, select also
detects that input is ready on stdin. This causes CGDB to get to a read
system call (which is non blocking) and the read system call fails with
errno set to EAGAIN. This causes CGDB to exit.
The main loop looks something like this,
if (select (max + 1, rset, NULL, NULL, NULL) == -1)
{
if (errno == EINTR)
continue;
..
}
if (FD_ISSET (STDIN_FILENO, rset)) {
handle_stdin
}
So, my question is, is there a bug with select on cygwin? Is select
working properly and I should handle the read call differently? Why does
it act differently than linux?
You say that something changed between different releases but you don't
mention what those releases are. Is this releases of Cygwin? If so,
what releases?
If this is as easy to demonstrate as you say, then a simple test case
is definitely called for.
Hi Christopher,
Attached is the test case. If I run it under linux, and then type ctrl-z, I
never get into the user_input_loop call. If I run it in cygwin, I do.
Hopefully I'm doing something wrong here. Please advise!
Ouch. Attached.
Bob Rossi
#include unistd.h
#include stdlib.h
#include stdio.h
#include sys/select.h
#include sys/ioctl.h
#include errno.h
#include termios.h
static struct termios term_attributes;
int
tty_cbreak (int fd, struct termios *orig)
{
struct termios buf;
if (tcgetattr (fd, buf) 0)
return -1;
/* Save the original state, for resetting later */
*orig = buf;
buf.c_lflag = ~(ECHO | ICANON);
buf.c_iflag = ~(ICRNL | INLCR);
buf.c_cc[VMIN] = 1;
buf.c_cc[VTIME] = 0;
#if defined (VLNEXT) defined (_POSIX_VDISABLE)
buf.c_cc[VLNEXT] = _POSIX_VDISABLE;
#endif
#if defined (VDSUSP) defined (_POSIX_VDISABLE)
buf.c_cc[VDSUSP] = _POSIX_VDISABLE;
#endif
if (tcsetattr (fd, TCSAFLUSH, buf) 0)
return -1;
return 0;
}
int
tty_set_attributes (int fd, struct termios *buf)
{
if (tcsetattr (fd, TCSAFLUSH, buf) 0)
return -1;
return 0;
}
int
user_input_loop ()
{
fprintf (stderr, HERE\r\n);
return 0;
}
static int
main_loop (void)
{
fd_set rset;
int max = STDIN_FILENO;
for (;;)
{
/* Reset the fd_set, and watch for input from GDB or stdin */
FD_ZERO (rset);
FD_SET (STDIN_FILENO, rset);
/* Wait for input */
if (select (max + 1, rset, NULL, NULL, NULL) == -1)
{
if (errno == EINTR)
continue;
else
{
fprintf (stderr, __FILE__, __LINE__,
select failed: %s, strerror (errno));
return -1;
}
}
/* Input received: Handle it */
if (FD_ISSET (STDIN_FILENO, rset)) {
if (user_input_loop () == -1)
return -1;
}
}
return 0;
}
int
main (int argc, char *argv[])
{
if (tty_cbreak (STDIN_FILENO, term_attributes) == -1)
{
fprintf (stderr, __FILE__, __LINE__, tty_cbreak error);
exit (-1);
}
/* Enter main loop */
main_loop ();
if (tty_set_attributes (STDIN_FILENO, term_attributes) == -1)
fprintf (stderr, __FILE__, __LINE__, tty_reset error);
return 0;
}
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
cygwin or gdb question
Hi, I have one more cgdb issue that seems to be cygwin related. However, it could be a gdb issue. I'm not sure. In verison cgdb-0.6.3 I start GDB up on a pipe and communicate with it over the pipe. This works fine, except that GDB behaves slightly differently when it is invoked on a pipe rather than a pty. That is, GDB provides interactive questions to the user when it's on a pty and not when it's on a pipe. In svn trunk for CGDB I began starting GDB on a pty and communicating with it that way. This fixed a bug for a user on max os X and provided the user with a GDB that acted more like it was on an actual terminal. This seems to work fine on linux, however I noticed a difference on Cygwin. I compile a large GUI application and debug it. I set no breakpoints and type 'r', do some stuff and the GUI and then stop. The debugger is hanging, waiting for something interesting to happen. If I type ctrl-c on linux, it interupts the debugger so that I can set a breakpoint or do something else interesting. If I do this on cygwin, it doesn't interupt the program. In fact, this isn't just a problem with CGDB, the exact same results happen with gdb. So, is it a cygwin or gdb issue that it appears that you can interupt the inferior when gdb is on a pipe, but not when it's on a terminal. Is there an easy way for me to test starting gdb on a pipe outside of CGDB? I would like to reproduce that gdb does interupt the inferior when ctrl-c is typed and GDB is started on a pipe. Thanks again, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin or gdb question
On Tue, Apr 03, 2007 at 12:54:57PM -0400, Igor Peshansky wrote: On Tue, 3 Apr 2007, Bob Rossi wrote: I have one more cgdb issue that seems to be cygwin related. However, it could be a gdb issue. I'm not sure. In verison cgdb-0.6.3 I start GDB up on a pipe and communicate with it over the pipe. This works fine, except that GDB behaves slightly differently when it is invoked on a pipe rather than a pty. That is, GDB provides interactive questions to the user when it's on a pty and not when it's on a pipe. In svn trunk for CGDB I began starting GDB on a pty and communicating with it that way. This fixed a bug for a user on max os X and provided the user with a GDB that acted more like it was on an actual terminal. This seems to work fine on linux, however I noticed a difference on Cygwin. I compile a large GUI application and debug it. I set no breakpoints and type 'r', do some stuff and the GUI and then stop. The debugger is hanging, waiting for something interesting to happen. If I type ctrl-c on linux, it interupts the debugger so that I can set a breakpoint or do something else interesting. If I do this on cygwin, it doesn't interupt the program. In fact, this isn't just a problem with CGDB, the exact same results happen with gdb. So, is it a cygwin or gdb issue that it appears that you can interupt the inferior when gdb is on a pipe, but not when it's on a terminal. Is there an easy way for me to test starting gdb on a pipe outside of CGDB? I would like to reproduce that gdb does interupt the inferior when ctrl-c is typed and GDB is started on a pipe. Yes. Use CYGWIN=tty or rxvt. Thanks, neither of these showed me the results that I used to get with cgdb-0.6.3. I've actually decided that I like cgdb working exactly the same way gdb does. So not being able to interupt the program with ctrl-c is fine. Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
SIGTSTP and select
Hi,
I'm preparing a new release of CGDB and I'm testing it out on several
platforms. I noticed a bug and tracked it down to SIGTSTP and select.
I'm not exactly sure what has changed since the last release to cause
this issue. However, here it is.
CGDB has a select loop that it uses as it's main loop. Since CGDB is a
ncurses application, the user can type ctrl-z and it is put into the
background. Then if the user types 'fg' it should resume like normal.
When ctrl-z is typed, CGDB receives a SIGTSTP on both linux and cygwin.
When CGDB is at the select loop and this happens on linux select returns
-1 and errno is set to EINTR. My code simple does a 'continue' when this
happens and the select loop is reentered. All works well. On cygwin,
select does not return with -1. (I didn't check the return value but I
can, I just compare to -1 in an if statement). In fact, select also
detects that input is ready on stdin. This causes CGDB to get to a read
system call (which is non blocking) and the read system call fails with
errno set to EAGAIN. This causes CGDB to exit.
The main loop looks something like this,
if (select (max + 1, rset, NULL, NULL, NULL) == -1)
{
if (errno == EINTR)
continue;
..
}
if (FD_ISSET (STDIN_FILENO, rset)) {
handle_stdin
}
So, my question is, is there a bug with select on cygwin? Is select
working properly and I should handle the read call differently? Why does
it act differently than linux?
Sorry if this question is obvious to everyone else, it isn't to me.
Thanks,
Bob Rossi
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: SIGTSTP and select
On Mon, Apr 02, 2007 at 08:37:53PM -0400, Christopher Faylor wrote:
On Mon, Apr 02, 2007 at 08:07:23PM -0400, Bob Rossi wrote:
I'm not exactly sure what has changed since the last release to cause
this issue. However, here it is.
When ctrl-z is typed, CGDB receives a SIGTSTP on both linux and cygwin.
When CGDB is at the select loop and this happens on linux select returns
-1 and errno is set to EINTR. My code simple does a 'continue' when this
happens and the select loop is reentered. All works well. On cygwin,
select does not return with -1. (I didn't check the return value but I
can, I just compare to -1 in an if statement). In fact, select also
detects that input is ready on stdin. This causes CGDB to get to a read
system call (which is non blocking) and the read system call fails with
errno set to EAGAIN. This causes CGDB to exit.
The main loop looks something like this,
if (select (max + 1, rset, NULL, NULL, NULL) == -1)
{
if (errno == EINTR)
continue;
..
}
if (FD_ISSET (STDIN_FILENO, rset)) {
handle_stdin
}
So, my question is, is there a bug with select on cygwin? Is select
working properly and I should handle the read call differently? Why does
it act differently than linux?
You say that something changed between different releases but you don't
mention what those releases are. Is this releases of Cygwin? If so,
what releases?
I'm sorry, it's late for me, and my sentence was very poorly phrased.
cgdb-0.6.3 seems to not have this problem. svn trunk, which is going
to become cgdb-0.6.4, does have this problem.
If this is as easy to demonstrate as you say, then a simple test case
is definitely called for.
OK, I will try.
I could also try doing a binary search between cgdb-0.6.3 and svn trunk.
I guess I was wondering if this was known issue.
I will let you know what my results are.
Bob Rossi
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
sh problems
Hi, I think that I have narrowed this down enough to say that this is a cygwin issue. Hopefully, I can get some advice on this list. If I run these commands in a dos window that I started nativly on the machine, C:\Documents and Settings\kelliset PATH=C:\windows\system32;C:\windows;C:\msys\1.0\bin C:\Documents and Settings\kellish --login -i [EMAIL PROTECTED] $ ls bin rcs tmp vigilant [EMAIL PROTECTED] $ Then everything works fine. Including vim. However, if I login via ssh and run this command, $ TERM=vt100 HOME=C:/msys/1.0/home/kelli +PATH=/cygdrive/c/windows/system32:/cygdrive/c/windows:/cygdrive/c/msys/1.0/bin +/cygdrive/c/windows/system32/cmd /c sh --login -i [EMAIL PROTECTED] ~ $ ls ls bin rcs tmp vigilant The sh doesn't properly. echo is turned on, tab completion doesn't work, the arrows literally move you around the terminal... Also, ls doesn't know how to display the files properly. If I start vim I get $ vim vim Vim: Warning: Output is not to a terminal Vim: Warning: Input is not from a terminal Does anyone know why this would be? I've talked extensivly with the mingw-users list, and they aren't sure why. They recommended asking here if cygwin does something odd in the background. Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http
Re: sh problems
On Mon, Dec 11, 2006 at 11:50:01AM -0800, Brian Dessent wrote: Bob Rossi wrote: I think that I have narrowed this down enough to say that this is a cygwin issue. Hopefully, I can get some advice on this list. If I run these commands in a dos window that I started nativly on the machine, So, essentially, this boils down to I'm running a non-Cygwin app connected to a Cygwin tty and it's behaving strangely. Well, duh. Non-cygwin apps attached to ttys do that, because non-Cygwin apps don't know what a tty is, they see it as a pipe and get confused. I don't understand how you'd expect this to work, unless you thought for some reason that the fact that you're using MSYS's sh would somehow make it work because MSYS is an ancient fork of Cygwin. But it's been all patched to hell so as to specifically not appear as a Cygwin app, so it's no different than any other non-Cygwin binary in that regard. If you want MSYS's sh to think you're connected to a terminal you'll need to port openssh to use MSYS and not Cygwin's runtime, so that sh is connected to a MSYS tty (if MSYS even retained the pty emulation code at all, I have no idea.) Remember the key point here, that ttys don't exist on windows and so they have to be emulated, and this emulation only works if all the programs involved are in on the prank. Thanks, that is very helpful. Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: msys
On Thu, Dec 07, 2006 at 09:19:04AM -0500, Buchbinder, Barry (NIH/NIAID) [E] wrote: Bob Rossi wrote on Thursday, December 07, 2006 9:10 AM: I'd like to know if anyone knows if it is possible to start the msys environment from a cygwin shell? I'm ssh'ing into a windows machine, which gives me a cygwin shell. I've tried a lot of things, and can't get an msys environment. Even if I remove every environment variable except for PS1, and then run 'cmd' and then cd to C:\msys\1.0 and the run .\msys.bat, I end up back in cygwin somehow. Any suggestions? No idea, but this might help: http://www.mingw.org/mingwfaq.shtml#faq-usingwithcygwin Thanks, but that's not what I'm looking for. I've already showed that I can cross compile from cygwin to mingw. However, I would also like to build nativly for mingw. I can do this if I'm sitting at my computer, cuase the msys environment is easy to get. However, when I'm remote, there is no way I can see to get into an msys environment. The mingw-users list suggested that I get another version of sshd that's not related to cygwin. However, i like cygwin's sshd server. Any ideas? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin -mno-cygwin AC_CHECK_SIZEOF
On Thu, Nov 30, 2006 at 11:57:41PM -0500, Igor Peshansky wrote: On Thu, 30 Nov 2006, Eric Blake wrote: According to Bob Rossi on 11/30/2006 7:32 PM: AC_CHECK_SIZEOF does these two things on cygwin with autoconf 2.60. fprintf(f, %d\n, sizeof($1)); which prints 4\r\n if the size is 4 and then AC_CV_NAME=`cat conftestval`, ... now cygwin's cat doesn't understand \r\n, so Or experiment with the recent add-on to cygwin's bash, where exporting SHELLOPTS with the cygwin-specific shell option igncr set will tell subsequent /bin/sh invocations to strip \r from command substitution. Although this might work. This is interesting. bash --version GNU bash, version 3.2.5(7)-release (i686-pc-cygwin) $ export SHELLOPTS=$SHELLOPTS:igncr -bash: SHELLOPTS: readonly variable Is there anything special I need to do here? I'll google some more ... And the fact that you are now telling configure the truth that you are cross-compiling, even though the cross binaries are executable, may be enough for autoconf to try harder for discovering how AC_CHECK_SIZEOF should behave without tripping up on line endings (and if that is not the case, maybe we should consider patching autoconf to make it happen that way). Or have autoconf use some other tool that does not do binary processing (e.g., awk or tr) instead of cat, which would enable the text mount solution. I really think this is the current best solution, that is, to modify autoconf to not use cat. Either that, or simply don't put the \n in the AC_CHECK_SIZEOF macro. I'm not sure why that is done in the first place. If fprintf(f, %d\n, sizeof($1)); was changed to fprintf(f, %d, sizeof($1)); I think it would fix the problem. Well, I downloaded the autoconf sources, but couldn't find the AC_CHECK_SIZEOF code. I did find it in /usr/share/autoconf, but when I modify it, the system autoconf behavior doesn't change. Any ideas? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin -mno-cygwin AC_CHECK_SIZEOF
On Thu, Nov 30, 2006 at 11:57:41PM -0500, Igor Peshansky wrote: On Thu, 30 Nov 2006, Eric Blake wrote: Or experiment with the recent add-on to cygwin's bash, where exporting SHELLOPTS with the cygwin-specific shell option igncr set will tell subsequent /bin/sh invocations to strip \r from command substitution. Although this might work. OK, this worked. Or at least seemed to work. Here is what I did bash -o igncr CPPFLAGS=-mno-cygwin CFLAGS=-mno-cygwin -O0 ./configure --build=mingw32 --enable-experimental-libtool Now, should I use this as a temporary solution, and fix autoconf? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin -mno-cygwin AC_CHECK_SIZEOF
Well, I downloaded the autoconf sources, but couldn't find the AC_CHECK_SIZEOF code. I did find it in /usr/share/autoconf, but when I modify it, the system autoconf behavior doesn't change. Any ideas? Patch below. Keep replies on the autoconf-patches list. OK, this patch works perfectly. Think this will go upstream? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin -mno-cygwin AC_CHECK_SIZEOF
On Fri, Dec 01, 2006 at 07:06:06AM -0700, Eric Blake wrote: According to Bob Rossi on 12/1/2006 6:57 AM: CPPFLAGS=-mno-cygwin CFLAGS=-mno-cygwin -O0 ./configure --build=mingw32 --enable-experimental-libtool EVIL. --build is for the platform you are BUILDING on (ie. cygwin), NOT the platform you are compiling for (ie. using -mno-cygwin says you are cross-compiling for mingw). By lying to configure, you are asking for problems. *Don't do that.* Also, setting environment variables prior to ./configure is deprecated, because rerunning ./config.status won't remember that you set those variables. And since -mno-cygwin is changing from a regular to a cross-compiler, you really should be setting it in CC rather than CFLAGS, so that the change happens everywhere. So, if you INSIST on using the cygwin environment to cross-compile mingw binaries, you should use: ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 \ CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' Well, if I do that, I get this: checking for MAP_ANON in sys/mman.h... no checking for /dev/zero... configure: error: cannot check for file existence when cross compiling This comes from the AC_CHECK_FILE(/dev/zero) call in configure.in. I think this might be an apr m4 macro problem. That's why I was lying to configure. Is there standard conventions for getting around this problem? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin -mno-cygwin AC_CHECK_SIZEOF
On Fri, Dec 01, 2006 at 11:22:19AM -0800, Paul Eggert wrote: Eric Blake [EMAIL PROTECTED] writes: Patch below. Keep replies on the autoconf-patches list. Thanks. In retrospect it was a mistake to append the trailing newline, I guess. I installed the following: it differs from your patch only in adding more commentary. Thanks to everyone involved. I was able to cross compile apr from cygwin to mingw, although I had to make a few small patches to apr. I wouldn't have been able to do it without the knowledge this group possesses. Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
autoconf
Hi, I'm using autoconf. I notice when I use things like AC_CHECK_SIZEOF (int) that the ac_cv_sizeof_int has the value of 4\r. There is an extra carriage return in there. I start my configure script with ./configure --build=mingw32 could that be the problem? Is there any solution to having these macro's work correctly on cygwin? or did I break it by using the --build option? BTW, I can't test it without the --build option because the configure script doesn't even get that far otherwise, since this is a mingw package (sort of). Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: autoconf
On Thu, Nov 30, 2006 at 05:04:08PM -0500, Bob Rossi wrote: Hi, I'm using autoconf. I notice when I use things like AC_CHECK_SIZEOF (int) that the ac_cv_sizeof_int has the value of 4\r. I narrowed it down further. It's AC_CHECKS_SIZEOF that does acgeneral.m4: fprintf(f, %d\n, sizeof($1)); which because I'm passing -mno-cygwin, get's a 4\r\n in a file. (if the size is 4) Then it does AC_CV_NAME=`cat conftestval`, ... That cat is the cygwin cat, so it puts out 4\r, which is incorrect. Do I have to get a cat that's been built with mingw? When I try to modify /usr/local/share/autoconf/acgeneral.m4 to do AC_CV_NAME=`dos2unix conftestval; cat conftestval`, ... and then run autoconf, autoconf doesn't pick up the changes. Is this possible to make autoconf do? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: autoconf
On Thu, Nov 30, 2006 at 06:45:10PM -0500, Larry Hall (Cygwin) wrote: Bob Rossi wrote: Hi, I'm using autoconf. I notice when I use things like AC_CHECK_SIZEOF (int) that the ac_cv_sizeof_int has the value of 4\r. There is an extra carriage return in there. I start my configure script with ./configure --build=mingw32 could that be the problem? Is there any solution to having these macro's work correctly on cygwin? or did I break it by using the --build option? BTW, I can't test it without the --build option because the configure script doesn't even get that far otherwise, since this is a mingw package (sort of). Sounds to me like the file you're feeding to autoconf has DOS line endings in it. Yes, this is correct. The AC_CHECK_SIZEOF macro does not work with -mno-cygwin unless there is a cygwin version of 'cat' on the path. Is there a standard way to resolve this problem? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: autoconf
On Thu, Nov 30, 2006 at 09:45:21PM -0500, Larry Hall (Cygwin) wrote: Bob Rossi wrote: On Thu, Nov 30, 2006 at 06:45:10PM -0500, Larry Hall (Cygwin) wrote: Bob Rossi wrote: Hi, I'm using autoconf. I notice when I use things like AC_CHECK_SIZEOF (int) that the ac_cv_sizeof_int has the value of 4\r. There is an extra carriage return in there. I start my configure script with ./configure --build=mingw32 could that be the problem? Is there any solution to having these macro's work correctly on cygwin? or did I break it by using the --build option? BTW, I can't test it without the --build option because the configure script doesn't even get that far otherwise, since this is a mingw package (sort of). Sounds to me like the file you're feeding to autoconf has DOS line endings in it. Yes, this is correct. The AC_CHECK_SIZEOF macro does not work with -mno-cygwin unless there is a cygwin version of 'cat' on the path. Is there a standard way to resolve this problem? I'm not sure. I'm assuming not using '-mno-cygwin' is not an option? Here's the full story. I'm trying to build apr. It needs to be built with mingw in order to have thread support. It specifically disables thread support with cygwin. So, instead of getting the mingw environment, I'd like to use the cygwin environment cause I my build system builds many other packages. I can't figure out how to get past this problem. Any help at all would be greatly appreciated. I even tried putting ~/bin/cat in my path, where cat does dos2unix and then calls /usr/bin/cat, but that didn't work either. I'm not sure why. I was sort of looking for a solution that was clean. Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: autoconf
On Thu, Nov 30, 2006 at 10:11:01PM -0500, Larry Hall (Cygwin) wrote: Bob Rossi wrote: On Thu, Nov 30, 2006 at 09:45:21PM -0500, Larry Hall (Cygwin) wrote: Bob Rossi wrote: On Thu, Nov 30, 2006 at 06:45:10PM -0500, Larry Hall (Cygwin) wrote: Bob Rossi wrote: Hi, I'm using autoconf. I notice when I use things like AC_CHECK_SIZEOF (int) that the ac_cv_sizeof_int has the value of 4\r. There is an extra carriage return in there. I start my configure script with ./configure --build=mingw32 could that be the problem? Is there any solution to having these macro's work correctly on cygwin? or did I break it by using the --build option? BTW, I can't test it without the --build option because the configure script doesn't even get that far otherwise, since this is a mingw package (sort of). Sounds to me like the file you're feeding to autoconf has DOS line endings in it. Yes, this is correct. The AC_CHECK_SIZEOF macro does not work with -mno-cygwin unless there is a cygwin version of 'cat' on the path. Is there a standard way to resolve this problem? I'm not sure. I'm assuming not using '-mno-cygwin' is not an option? Here's the full story. I'm trying to build apr. It needs to be built with mingw in order to have thread support. It specifically disables thread support with cygwin. So, instead of getting the mingw environment, I'd like to use the cygwin environment cause I my build system builds many other packages. I can't figure out how to get past this problem. Any help at all would be greatly appreciated. I even tried putting ~/bin/cat in my path, where cat does dos2unix and then calls /usr/bin/cat, but that didn't work either. I'm not sure why. I was sort of looking for a solution that was clean. Forgive me for being dense but why does the requirement to build apr with -mno-cygwin mean that you have to run configure with it? OK, it's not 'clean' but what else am I missing? Sorry, I'm very confused by your statement. I'm trying to configure/make/make install apr. I'm running configure to prepare to build. Am I missing something? Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mismatched dll
On Thu, Feb 02, 2006 at 09:32:27PM +, Eric Blake wrote: By moving the cygwin1.dll in the executable directory, things begin to work. However, I don't understand how it's assumed that the new cygwin1.dll acts the same as the one the executable was linked against. See what I mean? There's a difference here. Cygwin does not maintain binary compatibility of its use of its shared memory region between versions. But it DOES maintain binary compatibility of the API it exposes. Cygwin releases try very hard to guarantee that something compiled against an older cygwin1.dll will continue to run when a newer cygwin1.dll is put in its place. The underlying details may change (such as the shared memory region), but the API continues to work. And that is exactly what shared libraries were invented for. Hi Eric, Well, I just updated Cygwin, and now my nx client doesn't work anymore. If I rename the cygwin cygwin1.dll and have nx use the cygwin1.dll it comes with, it works. However, when I have nx use the cygwin1.dll that cygwin uses, it doesn't work. What should I do now? I could post the error messages I get here, if that's useful. Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Need Volunteers to test patch for gnu make
On Tue, Sep 05, 2006 at 03:36:02PM -0400, William A. Hoffman wrote: I have tested it and it works for me. William Sheehan has also tested it. Can a few more folks give the patch a try? Here is the link to the most recent patch: http://www.mail-archive.com/make-w32@gnu.org/msg01157.html Just get the source for make-3.81 and apply the above patch. You can get make from here: http://ftp.gnu.org/pub/gnu/make/ You will need to rerun autoconf/automake after the patch, as the patch does not include the configure script. Once you build it, run make check to verify that the build is working. Also, please try with any makefiles that you have and need to work with windows paths. This works for me. Thanks for the great work! Our system used to build with 3.80 from cygwin, it did not build with 3.81 from cygwin, and now works with native build of make with the patch above on cygwin. Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: change in behavior of make from 3.80 to 3.81
- have the patch made part of the upstream gnu make That's the best solution of all. The whole problem is that the current Cygwin make maintainer has no fun to work on this issue. Everybody else is free to put a bit of time and sweat into this and get this for free firther on. I'm still wondering why people don't go this way instead of discussing this problem, which is none, IMHO, to death. I agree with Corinna here, and others that have said it. There is a list of us that find this patch useful. We should determine what the effort would be to get this patch in the upstream source. Does anyone have time for this right now? Corinna, I can speak for myself, the reason this issue is discussed to death is because of the reaction from the Cygwin people. Free software users have an implicit association with friendly communication with the software developers. In this instance, the cygwin maintainers (or higher ups) are pretty much belittling there users and/or saying there is no problem. To many of us, there is a problem. I think your solution is well stated. Does anyone know who was maintaining the old patch to make, so that a discussion with that person could be made more substantial on a technical level? Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: change in behavior of make from 3.80 to 3.81
I think your solution is well stated. Does anyone know who was maintaining the old patch to make, so that a discussion with that person could be made more substantial on a technical level? And ^^^this^^^ is a perfect example of why this discussion is so frustrating. Does someone *really* have to tell you who was maintaining the old patch? If you really need to be told this then you really don't have the right to an opinion on this subject at all since you clearly haven't been paying any attention. I think you are all to knowledgable about cygwin and should step back and think about people that use Cygwin as a black box and understand absolutly nothing about it or it's development process. The frustration you are expressing is understandable to me. However, with a little managerial effort on your part, you could use your knowledge (if you so choose) to help the rest of us organize a productive way to develop a patch to the upstream make. I thought Corinna spoke very well on this matter, and is why I even bothered responding to this list. Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: change in behavior of make from 3.80 to 3.81
On Wed, Aug 16, 2006 at 01:52:23PM -0400, William A. Hoffman wrote: At 11:49 AM 8/16/2006, Christopher Faylor wrote: How do you know it is a small patch? Have you actually looked at the code? I find that unlikely. I had not looked at the source, but figured it most likely was not that big a change. I now have looked at the sources, and minus the makefile changes, the diff between the upstream 3.80 and 3.81 is about 450 lines of diff. Although if you removed the command.com changes, and only used sh to launch stuff, the changes would be much smaller than that. I can see why it would not be accepted upstream as is: ChangeLog.RedHat: * vpath.c: use cygwin32_win32_to_posix_path_list() in ChangeLog.RedHat: cygwin.dll library to accept both posix and win32 paths It makes a call to cygwin.dll. So, I suppose a new patch would be needed up stream that did not have the command.com stuff ( I don't think it is being missed). The new patch would only put in support for drive letters to work, and I would think that it would be much smaller. Hi Bill, Do you plan on creating a patch to make that would provide the 3.80 functionality? Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: change in behavior of make from 3.80 to 3.81
On Mon, Aug 14, 2006 at 02:28:56PM -0400, Bill Hoffman wrote: 3.80 does this: make -f test.make make: *** No rule to make target `C:/foo', needed by `foo'. Stop. 3.81 does this: make -f test.make test.make:1: *** target pattern contains no `%'. Stop. test.make contains: foo: C:/foo So, in 3.80 windows style driver letter : path worked with make. In 3.81, it no longer does. Is this expected, can the old way be brought back? Yes, unfortunatly it no longer works in 3.81. However, I think it's good we all let the Cygwin guys know that this patch actually was useful. Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 3.81 and windows paths
Well, the whole point of cygwin is to give a POSIX-compatible environment in win32. So it's aiming to be like linux, not windows. This means that if something like a makefile parses fine in linux, but not in cygwin (barring linker stuff), something is wrong. Yeah, what's wrong is that cl doesn't accept posix paths. For some reason, they were added, we all got addicted to it, and now it's being ripped out from underneath us. It's not a very friendly thing to do. Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 3.81 and windows paths
On Fri, Jul 28, 2006 at 11:28:42AM -0400, Igor Peshansky wrote: On Fri, 28 Jul 2006, Christopher Faylor wrote: On Fri, Jul 28, 2006 at 10:43:30AM -0400, Bob Rossi wrote: Well, the whole point of cygwin is to give a POSIX-compatible environment in win32. So it's aiming to be like linux, not windows. This means that if something like a makefile parses fine in linux, but not in cygwin (barring linker stuff), something is wrong. Yeah, what's wrong is that cl doesn't accept posix paths. For some reason, they were added, we all got addicted to it, and now it's being ripped out from underneath us. It's not a very friendly thing to do. If you are invoking cl in your Makefiles, they are no longer POSIX or Linux Makefiles, and you might as well run your paths through cygpath before sending them to cl. Yes, this is the solution I came up with, but it's not an easy task. It's also slightly ugly, since we compile with g++/gcc on other systems. profanity deleted Hmm, I thought we didn't have an automatic censorship filter on this list. I guess you just have to be *really* annoyed to trip it. OTOH, a simple here we expletive go again would probably have sufficed... At least I understand this. Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 3.81 and windows paths
I can imagine that the immediate response to this complaint will be fix your Makefiles to work with Cygwin if it's such an important component. As others have mentioned, this is no simple task in very large Makefile systems that support a wide variety of compilation toolchains. Cygwin make has supported Win32 paths for a long time, so much that I would say that people have come to rely on it. I am not saying that the changes are impossible; just that it is a larger inconvenience than some may realize. I second this thought. I'm stuck on 3.80 until I have the time to figure out how to port to 3.81. I may simply wait for 3.82 and hope the feature removed comes back. Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: window resizing not updating COLUMNS and LINES
On Wed, May 31, 2006 at 05:19:15PM -0500, mwoehlke wrote: Kenneth Nellis wrote: mwoehlke wrote: Kenneth Nellis wrote: I'm not seeing the LINES and COLUMNS environment variables getting updated correctly after resizing my terminal window. This occurs whether I'm using rxvt or xterm. Furthermore, echo $COLUMNS and printenv COLUMNS don't agree. (I didn't see relevant articles in the archives.) This occurs regardless of how shopt -s checkwinsize is set. FWIW, on *my* Cygwin, LINES and COLUMNS aren't even set... go figure. :-) Same here...I do my own export to get things started. --Ken Wait, wait, step back... this in itself sounds like a problem. Can anyone on the list verify that Cygwin's bash is setting these *at all*? (Of course, Ken's OP seems to imply he has it at least half working, but something smells fishy here...) Bash is *supposed* to set these behind-the-scenes without your doing anything. This seems to be how it works on Linux... readline set's these variables in shell.c:sh_set_lines_and_columns. This gets called from terminal.c:_rl_get_screen_size which get's called from terminal.c:rl_resize_terminal. It also get's called from terminal.c:_rl_init_terminal_io. The best way to resolve this problem is to get a version of bash compiled with debug and set breakpoints at the places I've mentioned.. Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: multiple commands on a single line seem to run in the background automatically
On Sun, May 28, 2006 at 02:19:02PM +0100, Valster Nico-anv009 wrote: I'm working on a bash script to automate the build process. The script calls, depending on the parameters the Microsoft VC6 compiler and/or the GreenHills compiler and/or the Cygwin GCC for one or more project/makefiles. If I invoke the script like: c:/bat/sbuild .. things work pretty well. However if I invoke it as cd /cygdrive/d/CCase/anv009_SPRINT_8/SPRINT_VOB/SPRINT;c:/bat/sbuild . Is it possible you forgot to add the new line escape characther? Try: cd /cygdrive/d/CCase/anv009_SPRINT_8/SPRINT_VOB/SPRINT;c:/bat/sbuild \ . Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] New Package: cygport-0.1.93-1
On Fri, May 19, 2006 at 05:26:14PM -0500, Yaakov S (Cygwin Ports) wrote:
Bob Rossi wrote:
I created a setup.hint for the first time. I don't have a README, is
this required?
Yes, see:
http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/packaging/templates/generic-readme?content-type=text/plaincvsroot=cygwin-apps
Keep in mind that the Build instructions section needs to be changed
for a cygport-based source package.
OK, do you have an example from one that you've done that you can post
here?
What's the command to 'rerun the pkg phase?
cygport ./cgdb-0.6.2-1.cygport install pkg
This installs the README in ${D}/usr/share/doc/Cygwin, and creates
binary and source packages. You will also find cgdb-0.6.2-1/dist/cgdb/,
which is a release-ready package directory, and can be copied as is to
your web space for testing and upload.
OK, this works great so far. Forgive my ignorance, but what's the best
and easiest way I can test installing this new package before bothering
the cygwin-apps mailing list?
Thanks,
Bob Rossi
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] New Package: cygport-0.1.93-1
However, you do understand correctly. I'm attaching the .cygport and source patch that I've used to build cgdb for Cygwin Ports. Just put these files together in a directory, cd there, then: cygport ./cgdb-0.6.2-1.cygport download almostall OK, this worked great. To retrieve the sources and build them. Then just add your README and setup.hint to cgdb-0.6.2-1/CYGWIN-PATCHES, rerun the pkg phase, and you're set to go. I created a setup.hint for the first time. I don't have a README, is this required? What's the command to 'rerun the pkg phase? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] New Package: cygport-0.1.93-1
On Thu, May 18, 2006 at 08:13:50PM -0500, Yaakov S (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bob Rossi wrote: I have a package called CGDB. Do I understand you correctly by thinking that cygport would help me easily be able to create a cygwin package? In the future, please respect the following: http://cygwin.com/acronyms/#PPIOSPE However, you do understand correctly. I'm attaching the .cygport and source patch that I've used to build cgdb for Cygwin Ports. Just put these files together in a directory, cd there, then: cygport ./cgdb-0.6.2-1.cygport download almostall To retrieve the sources and build them. Then just add your README and setup.hint to cgdb-0.6.2-1/CYGWIN-PATCHES, rerun the pkg phase, and you're set to go. Wow! This package is incredible. Thanks. This will certainly encourage people like me (that have NO time), to submit packages to Cygwin. Thanks! Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
package maintenance
I would like to start to package CGDB for Cygwin. Has anyone written any scripts that would help automate bundling packages for cygwin from a source repo? That way, I could automate building the packages when I do a release of CGDB. Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Why only 1 cygwin1.dll?
Sorry for my late response. I've been busy. What's wrong with third parties simply installing any cygwin1.dll that they want to distribute (subject to the GPL of course) in a setup-compatible location and way? Then the only question is whether to install over any existing DLL or not. That's the same old issue that all installers have with any shared DLL. Using the accepted practice of replacing any existing old DLL with a newer one (by comparing version) should work fine. OK, I see your point here, but it only works when you have every 3rd party following the same rules. Does this seem possible to you? It doesn't to me. Removal of shared DLLs across apps is a common problem for any Windows app too. I don't believe the Cygwin distribution and any 3rd party distributor throws a new wrinkle into this. I've seen many an uninstaller ask me if I want to delete XXX.dll that could still be needed by other apps. Same rules apply. The worst case is that one cygwin1.dll gets left on a user's system after all apps using it have been uninstalled. That's par for the course with Windows. And at least if the DLL is always in the setup- compatible location, it would be easily found and used/overwritten by any subsequent installation, 3rd party or otherwise. OK, you are correct here, however, I plan on doing something a little different. I'm assuming many people on this list have much more knowledge than I do about these subjects, but I'll attempt anyways. I would like to package an executable and put the DLL in the same directory as the executable. That way, I don't really care if there is a different version on the system, my program will always use my version. Also, when I uninstall the application, I simply remove the executable and all the DLL's. By packaging this way, I sidestep replacing DLL's and uninstalling issues. Now, as far as a tool to help users install Cygwin. I don't think this is a possible task, and I will explain why. Two different cygwin1.dll's can not be used at the same time by two process's. Therefor, each time an application starts (including Cygwin?) it must check to see if a cygwin1.dll is already loaded by the kernel. If it is loaded, then mv the distributed cygwin1.dll out of the way so that the executable being started uses the already loaded cygwin1.dll. If it is not loaded, mv the distributed cygwin1.dll so that the started executable will use the distributed cygwin1.dll. Each 3rd party application needs to honor this, and that includes cygwin itself. Does this seem possible to you? Also, this yields the chicken or the egg problem, which would force 3rd party applications to have the program the user starts be a bash script, which handles all the dirty work until it is safe to start cygwin (or use dlopen on cygwin?). Next, putting cygwin1.dll in a common place could prove to be very problematic. If it is not in the directory where the program is executed, then it needs to be on your path. So, if there is a common spot in C:\cygwin\special_dir, then the PATH would need to be edited by 3rd party applications to make sure the dll could be found. Also, by using a common cygwin1.dll, installing software could change the DLL another vendor was tied to (patched cygwin) and break a previous installation. Finally, there is already a lot of applications that ship with cygwin1.dll in ther bin/ directory, and will probably continue to do so. Again, my intentions here are not to bash cygwin. Eric Blake was kind enough to describe to me why cygwin acts the way it does, and from my understanding it makes perfect sense. However, I don't think as a Cygwin supporter that it should follow that it is possible to nicely distribute Cygwin in a 3rd party application when in reality it is not. Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Why only 1 cygwin1.dll?
On Sat, Mar 25, 2006 at 12:38:53PM -0500, Lev Bishop wrote: FAQ candidate? Either of Eric's explanations seem spot on, to me. And this question does come up fairly regularly. In the FAQ, I think it would be a good idea to mention that this limitation makes it impossible (outside of setup.exe) to package an application based on Cygwin and guarantee that it runs on the host machine. That is, it's impossible to determine if the cygwin1.dll is already on the machine. Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Why only 1 cygwin1.dll?
On Sat, Mar 25, 2006 at 12:56:56PM -0500, Christopher Faylor wrote: On Sat, Mar 25, 2006 at 12:40:51PM -0500, Bob Rossi wrote: On Sat, Mar 25, 2006 at 12:38:53PM -0500, Lev Bishop wrote: FAQ candidate? Either of Eric's explanations seem spot on, to me. And this question does come up fairly regularly. In the FAQ, I think it would be a good idea to mention that this limitation makes it impossible (outside of setup.exe) to package an application based on Cygwin and guarantee that it runs on the host machine. That is, it's impossible to determine if the cygwin1.dll is already on the machine. It is certainly not impossible. We support the cygwin release here. That does not preclude (except for lack of interest apparently) someone providing providing a nifty tool for determining if/when to install a 3PP cygwin DLL but we all know that anyone who wants that automatically is only able to complain about the lack of such a tool. It's been a given for years in this mailing list and I doubt that it will change anytime soon. The best that people seem to be able to do is complain about how much they want to do this here and predict the death of cygwin if something isn't changed to accommodate their desires. Hi Christopher, I certainly didn't mean to complain. I really love Cygwin and wouldn't ever predict it's death. I can't work without it on windows. However, I still think that it's not possible, without a horrid solution. The problem with the third party tool is that it would need to be run every time before the third party application is run. If the user installed Cygwin, remove the local cygwin1.dll. If the user removed Cygwin, replace the removed cygwin1.dll. Very odd. Does this sound like a reasonable solution to you (although I'll admit it's possible)? Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GDB Interrupts on Cygwin
On Fri, Mar 17, 2006 at 03:55:08AM -0500, Doug Bohl wrote: When running a Windows application from GDB, GDB gives control to the application at a certain point. It would be nice to, at an arbitrary time, suspend the application and give control back to GDB. I know that I can set breakpoints, but sometimes I don't know exactly when I want to break until after I'm running the application. Ctrl-C supposedly sends the SIGINT signal to GDB, breaking the running application and restoring control to GDB. However, this does not appear to work, at least not on Cygwin. Even though this may seem strange, try this. Before starting GDB, type 'tty' at the console. Then, after you start GDB, run the command 'tty outputofttycommandfromconsole'. I think this will enable the ^c. It's a bug in GDB that hopefully I'll get to look at one day. Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GDB Interrupts on Cygwin
On Fri, Mar 17, 2006 at 10:15:13AM -0500, Christopher Faylor wrote: On Fri, Mar 17, 2006 at 06:56:55AM -0500, Bob Rossi wrote: On Fri, Mar 17, 2006 at 03:55:08AM -0500, Doug Bohl wrote: When running a Windows application from GDB, GDB gives control to the application at a certain point. It would be nice to, at an arbitrary time, suspend the application and give control back to GDB. I know that I can set breakpoints, but sometimes I don't know exactly when I want to break until after I'm running the application. Ctrl-C supposedly sends the SIGINT signal to GDB, breaking the running application and restoring control to GDB. However, this does not appear to work, at least not on Cygwin. Even though this may seem strange, try this. Before starting GDB, type 'tty' at the console. Then, after you start GDB, run the command 'tty outputofttycommandfromconsole'. I think this will enable the ^c. This is a no-voodoo zone. CTRL-C works fine in gdb. I use it ALL of the time. Maybe the OP has CYGWIN=tty set or is trying to run from rxvt. If so, don't do that. Run gdb from a windows console and it should work fine. O, right. Sorry. The bug I was talking about only appears when you fork/exec GDB from within a program. Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: curses.h location in cygwin install?
On Fri, Mar 10, 2006 at 08:38:57AM -0800, Robin Lin wrote: Hi everyone, I'm trying to use the curses library, and I can't seem to locate where the curses.h file is. I've tried to reinstall the curses packages several times, and I still can't locate the file. It's just not where everyone says it should be (\usr\include\ncurses). I don't even see an ncurses folder, yet I can run the ncurses tests/demos just fine, so it must be somewhere... Hi Robin, I would think this might be of some help to you. http://www.cygwin.com/ml/cygwin/2006-01/msg00996.html Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
mismatched dll
Hi, I've been plagued with this error message before: [EMAIL PROTECTED] /cygdrive/c/Program Files/NX Client for Windows/bin] $ ./nxssh.exe c:\Program Files\NX Client for Windows\bin\nxssh.exe (1292): *** proc magic mismatch detected - 0xC87757A7/0xD94C588A. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. Last time I had this problem, I actually had to modify the executable I was running to fix it, by pointing to the correct dll. http://sourceware.org/ml/cygwin/2005-03/msg00700.html However, I think this is different. I've used nx from (http://nomachine.com/) for a while now. After I upgraded Cygwin recently to get readline-5.1, this program stopped working. The error is above. This is the bin directory where the nx program ran: [EMAIL PROTECTED] /cygdrive/c/Program Files/NX Client for Windows/bin] $ ls -al total 6060 drwx--+ 2 bar None 0 Feb 2 14:18 . drwx--+ 5 bar None 0 Feb 2 14:20 .. -rwx--+ 1 bar None 1723392 Dec 13 10:50 NXWin.exe -rwx--+ 1 bar None 1152000 Dec 13 10:50 cygXcomp.dll -rwx--+ 1 bar None 1067008 Dec 9 10:34 cygcrypto-0.9.8.dll -rwx--+ 1 bar None 134656 Dec 9 10:34 cygjpeg-62.dll -rwx--+ 1 bar None 20992 Dec 9 10:34 cygminires.dll -rwx--+ 1 bar None 235520 Dec 9 10:34 cygpng12.dll -rwx--+ 1 bar None 105472 Dec 13 10:50 cygserver.exe -rwx--+ 1 bar None 1295582 Dec 9 10:34 cygwin1.dll -rwx--+ 1 bar None 61440 Dec 9 10:34 cygz.dll -rwx--+ 1 bar None 26112 Dec 13 10:50 nxauth.exe -rwx--+ 1 bar None 50176 Dec 13 10:50 nxesd.exe -rwx--+ 1 bar None 27136 Dec 13 10:50 nxkill.exe -rwx--+ 1 bar None 28672 Sep 13 19:14 nxsetup.exe -rwx--+ 1 bar None 253952 Dec 13 10:50 nxssh.exe I would appreciate any help. Just for my information, isn't it OK to put the cygwin1.dll in the same directory as the program you are running? Is this the approved way of releasing cygwin with an application? Thanks, Bob Rossi Cygwin Configuration Diagnostics Current System Time: Thu Feb 02 14:29:46 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: c:\Lint C:\cygwin\home\bar\bin C:\cygwin\home\bar\bin\fun C:\cygwin\usr\packages\distcc-2.18.3\bin C:\cygwin\home\bar\bin C:\cygwin\home\Qt\tmake-1.4\bin C:\cygwin\home\Qt\qt-2.3.0\bin C:\cygwin\usr\X11R6\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin c:\Perl\bin c:\GNAT\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\InstallShield\InstallShield 5.5 Professional Edition\Program Output from C:\cygwin\bin\id.exe (nontsec) UID: 1003(bar) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1003(bar) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'bar' PWD = '/home/bar' HOME = '/home/bar' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\bar.BAR-NT' MANPATH = ':/usr/ssl/man:/usr/X11R6/man' APPDATA = 'C:\Documents and Settings\bar.BAR-NT\Application Data' GNATMAKE = 'gnatmake -j5' HOSTNAME = 'bar-nt' VS71COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\' VCAST_ASSERTIONS = 'true' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 2 Stepping 7, GenuineIntel' WINDIR = 'C:\WINDOWS' VCAST_VRESULT_SHOW_ERRORS = 'true' LATEST = '/home/LATEST' CVSROOT = ':pserver:[EMAIL PROTECTED]:/home/CVS/cvsroot' PUBLIC = '/home/PUBLIC' OLDPWD = '/cygdrive/c/Program Files/NX Client for Windows/bin' USERDOMAIN = 'BAR-NT' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users.WINDOWS' USERS = '/home/USERS' !:: = '::\' TEMP = '/cygdrive/c/DOCUME~1/BAR~1.BAR/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' LIB = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\' USERNAME = 'bar' PROCESSOR_LEVEL = '15' BASELINE = '/home/BASELINE' VCAST_SPLASH_TIMEOUT = '0' BUILD = '/home/BUILD' GHS_LMHOST = '@ultra' FP_NO_HOST_CHECK = 'NO' BASH_PROFILE_CONFIG_DIR = '/home/USERS/bar/cvs/bob/config/bash' SYSTEMDRIVE = 'C:' EDITOR = 'vim' BASH_PROFILE_NETWORK_NAME = 'vector' VECTORCAST_DIR = 'c:\vcast\baseline' USERPROFILE = 'C:\Documents and Settings\bar.BAR-NT' CLIENTNAME = 'Console' PS1 = '[EMAIL PROTECTED] \w] $ ' LOGONSERVER = '\\BAR-NT' LM_LICENSE_FILE = '[EMAIL PROTECTED]' PROCESSOR_ARCHITECTURE = 'x86' !C: = 'C:\cygwin\bin' SHLVL
Re: mismatched dll
On Thu, Feb 02, 2006 at 02:28:31PM -0600, Yaakov S (Cygwin Ports) wrote: Bob Rossi wrote: This is the bin directory where the nx program ran: [EMAIL PROTECTED] /cygdrive/c/Program Files/NX Client for Windows/bin] $ ls -al total 6060 drwx--+ 2 bar None 0 Feb 2 14:18 . drwx--+ 5 bar None 0 Feb 2 14:20 .. -rwx--+ 1 bar None 1723392 Dec 13 10:50 NXWin.exe -rwx--+ 1 bar None 1152000 Dec 13 10:50 cygXcomp.dll -rwx--+ 1 bar None 1067008 Dec 9 10:34 cygcrypto-0.9.8.dll -rwx--+ 1 bar None 134656 Dec 9 10:34 cygjpeg-62.dll -rwx--+ 1 bar None 20992 Dec 9 10:34 cygminires.dll -rwx--+ 1 bar None 235520 Dec 9 10:34 cygpng12.dll -rwx--+ 1 bar None 105472 Dec 13 10:50 cygserver.exe -rwx--+ 1 bar None 1295582 Dec 9 10:34 cygwin1.dll **^^^ -rwx--+ 1 bar None 61440 Dec 9 10:34 cygz.dll -rwx--+ 1 bar None 26112 Dec 13 10:50 nxauth.exe -rwx--+ 1 bar None 50176 Dec 13 10:50 nxesd.exe -rwx--+ 1 bar None 27136 Dec 13 10:50 nxkill.exe -rwx--+ 1 bar None 28672 Sep 13 19:14 nxsetup.exe -rwx--+ 1 bar None 253952 Dec 13 10:50 nxssh.exe I would appreciate any help. Just for my information, isn't it OK to put the cygwin1.dll in the same directory as the program you are running? No. There must be only ONE cygwin1.dll on your entire system. It should be in your cygwin /bin directory. Period. Wow, that seems very inflexible. Is this a design decision? Is this the approved way of releasing cygwin with an application? AFAIK there is no approved way of releasing cygwin together with *anything*, as it is bound to lead to such problems. Why would 1 cygwin.dll care about another on the system that has nothing to do with it? I have N different versions of our product installed on my windows machine, and each has a slightly diffferent vresion of qt.dll. This isn't a problem at all. What's limiting Cygwin? BTW, this worked before I upgraded cygwin. So it is at least possible if they are the same version? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mismatched dll
On Thu, Feb 02, 2006 at 08:42:34PM +, Eric Blake wrote: No. There must be only ONE cygwin1.dll on your entire system. It should be in your cygwin /bin directory. Period. Wow, that seems very inflexible. Is this a design decision? Yes. Cygwin DEPENDS on shared memory between processes, in order to emulate POSIX semantics. If you have two different .dlls trying to share the same memory, but with different ideas of what the semantics of that memory are, you invariably have problems. Cygwin prints out the error message you saw rather than trying to be backwards compatible to all earlier releases of the .dll in how this shared memory is used, because it is just easier that way. OK. I understand the concept of having each application share a single .dll, this is to save space. Unix does this with shared objects. However, here's what I don't understand. Please explain to me why my thinking is fault. A program called p_v1 depends on v1.dll. Another program called p_v2 depends on v2.dll. For every p_v1 or p_v2 you start, only a single version of the associated dll is opened. The reason this design is nice is because you can have multiple versions of the .dll installed, and they will be shared between executables nicely. On Cygwin, for some reason you assert this condition is not true. I believe that what you are asserting is based in fact, and would really like to understand why. BTW, this worked before I upgraded cygwin. So it is at least possible if they are the same version? Possible? Yes. Wise? No. You are tempting fate - almost as surely as you try this, you will forget to upgrade one of the two copies, and be right back at this issue. Hence the official stance of this list is to only ever have a SINGLE cygwin1.dll on your machine. By moving the cygwin1.dll in the executable directory, things begin to work. However, I don't understand how it's assumed that the new cygwin1.dll acts the same as the one the executable was linked against. See what I mean? Another reason I'm asking is, I was trying to think of how I could package CGDB for people. Thanks for the great help, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mismatched dll
On Thu, Feb 02, 2006 at 09:32:27PM +, Eric Blake wrote: OK. I understand the concept of having each application share a single .dll, this is to save space. Unix does this with shared objects. However, here's what I don't understand. Please explain to me why my thinking is fault. A program called p_v1 depends on v1.dll. Another program called p_v2 depends on v2.dll. For every p_v1 or p_v2 you start, only a single version of the associated dll is opened. The difference is not the .dll itself, but the shared memory region that cygwin uses. Every process linked against cygwin1.dll opens a shared memory region, known by a fixed name/location, so that information can be passed between cygwin processes via this shared memory area. And there are enough POSIX semantics that require sharing info between cygwin processes that it is QUITE difficult to try opening different shared memory regions when different .dlls are used. http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/src/winsup/cygwin/how-cygheap-works.txt?rev=1.5content-type=text/plaincvsroot=src http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/src/winsup/cygwin/how-cygtls-works.txt?rev=1.1content-type=text/plaincvsroot=src OK, I understand now, thank you. So, it would be possible to start another process, that has a well known protocol, that distributes the communication between dll's, instead of sharing the memory explicitly? I'm just curious, I know this isn't going to happen. By moving the cygwin1.dll in the executable directory, things begin to work. However, I don't understand how it's assumed that the new cygwin1.dll acts the same as the one the executable was linked against. See what I mean? There's a difference here. Cygwin does not maintain binary compatibility of its use of its shared memory region between versions. But it DOES maintain binary compatibility of the API it exposes. Cygwin releases try very hard to guarantee that something compiled against an older cygwin1.dll will continue to run when a newer cygwin1.dll is put in its place. The underlying details may change (such as the shared memory region), but the API continues to work. And that is exactly what shared libraries were invented for. Yeah, that's nice. However, what happens when this changes? Another reason I'm asking is, I was trying to think of how I could package CGDB for people. By far the easiest is to tell them to download cygwin themselves, then you don't have to worry about it. But yes, this is not very user-friendly. So you will have to come up with some scheme where if cygwin is already on the machine, you make sure it is new enough for your needs, and if it is not present, you make sure the user is informed that you are installing a cygwin1.dll and that if they ever want more cygwin features they should replace/delete the one you installed. Otherwise, you risk becoming the dreaded http://cygwin.com/acronyms/#3PP. Oh, and remember that cygwin1.dll is GPLd, so if you distribute the dll yourself, you must also distribute the source code for the version you are shipping, as well as make sure your own project is open source per the cygwin license. I love Cygwin, so the following is not an attack against it, just critism that one day could hopefully be resolved. The way Cygwin currently can be distributed (as described above) is not 'packager friendly'. If the user does happen to install your package (which has cygwin1.dll in it) and then they install cygwin, the currently installed package will no longer work. I don't see any way to prevent this from a packaging perspective. As far as the licensing, Yeah, that's not a problem in any way. Thanks for your help, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mismatched dll
On Thu, Feb 02, 2006 at 09:58:17PM +, Eric Blake wrote: OK, I understand now, thank you. So, it would be possible to start another process, that has a well known protocol, that distributes the communication between dll's, instead of sharing the memory explicitly? I'm just curious, I know this isn't going to happen. Yes its possible (pretty much anything in computer science is, if you are willing to write the code and wait long enough). The difference is that shared memory is SO much faster than a data-copying communication protocol that it isn't even funny. Have you ever run cygwin on a Win9x machine, where the entire shared region has to be copied into the correct location because Windows didn't provide a convenient way to lock addresses, vs. a WinNT machine, where the shared memory already lives in the correct location? The timing difference on every fork() or exec() is staggering, and can't be blamed on processor speed alone. And yet even cygwin on WinNT is slower than native Linux, because Windows doesn't provide the nice copy-on-write semantics of memory pages shared between processes on a fork(), at least not in a way easily used by cygwin. OK, now I understand. It's currently the only practical way to accomplish the task. Here's another question I have (sorry). Why wouldn't it be acceptable to have to (different version) cygwin1.dll's running on a single system? That is, 2 completely different Cygwin environments? So, all programs that link against the same cygwin1.dll are in one Cygwin environment. If there is another version of the cygwin1.dll, and programs link against it, they would be in another Cygwin environment, completely independent. You know, I'm sure this has been thought of before, but if it hasn't ... I love Cygwin, so the following is not an attack against it, just critism that one day could hopefully be resolved. The way Cygwin currently can be distributed (as described above) is not 'packager friendly'. If the user does happen to install your package (which has cygwin1.dll in it) and then they install cygwin, the currently installed package will no longer work. I don't see any way to prevent this from a packaging perspective. There's always another alternative - propose to maintain your package as part of the official cygwin distribution. Then you just point people to cygwin.com, and source code distribution becomes cygwin.com's problem instead of yours. OK, here I do have some evidence to support me when I say you are partially wrong. http://www.cygwin.com/ml/cygwin-apps/2003-08/msg00064.html So, that is not a good alternative. Anyways, it's running circles around the point. I want to allow users to run my program with out install Cygwin. In some situations, it's possible installing Cygwin wouldn't even be allowed, where as simply untaring a directory with an executable might be OK. I've already installed 2 programs that I know of that use Cygwin. GNAT and nx (nomachine.com). Both of these companies deliver the cygwn1.dll, which totally borks my environment because I have Cygwin installed. So I have the problem on both ends. I want to package my software to be allowed in Cygwin (without borking others), and I know longer want to be borked when I install other people's software that use Cygwin. BTW, Cygwin is amazing, thanks for _all_ the great work. Hope I don't come off ungrateful. I could literally quit programming if I had to work on windows with out it. :) Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mismatched dll
On Thu, Feb 02, 2006 at 08:38:42PM -0500, Christopher Faylor wrote: On Thu, Feb 02, 2006 at 08:37:12PM -0500, Bob Rossi wrote: On Thu, Feb 02, 2006 at 09:58:17PM +, Eric Blake wrote: There's always another alternative - propose to maintain your package as part of the official cygwin distribution. Then you just point people to cygwin.com, and source code distribution becomes cygwin.com's problem instead of yours. OK, here I do have some evidence to support me when I say you are partially wrong. http://www.cygwin.com/ml/cygwin-apps/2003-08/msg00064.html So, that is not a good alternative. I retract my veto. If this is submitted via normal channels, I will have no objections. Well, I suppose anything in computer science is [possible], if you are willing to write the code and wait long enough? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mismatched dll
On Thu, Feb 02, 2006 at 05:52:57PM -0800, Brian Dessent wrote: Bob Rossi wrote: Here's another question I have (sorry). Why wouldn't it be acceptable to have to (different version) cygwin1.dll's running on a single system? That is, 2 completely different Cygwin environments? So, all programs that link against the same cygwin1.dll are in one Cygwin environment. If there is another version of the cygwin1.dll, and programs link against it, they would be in another Cygwin environment, completely independent. It *is* possible to create two Cygwin DLLs that can co-exist. But to do so requires much more than just naming them differently. The source code must be modified to use a different filename/identifier for the shared memory region, as well as different registry keys for the mount table. The Cygwin testsuite does a limited version of this to allow running the just-built Cygwin DLL for the purposes of executing the tests, from within the developer's existing Cygwin environment. Nice, I was wondering how you could develop on Cygwin without this capability. That makes perfect sense. I'm just guessing, but it might be a good idea to make this hardcoded constants dynamic, so that any arbitrary number of cygwin1.dll's can coexist. So yes, it can be done. But it is a very bad idea to do so. If you made two DLLs that were isolated in this way they would be truly isolated -- you could not send signals from one to the other, they would not see each others processes in their PID tables, and so on. It would be the absolute worst way to have two sets of software interact. OK, we are looking at things from 2 different perspectives. I want to make it so that they can not interact at all. That would be my goal. I want to deliver a cygwin1.dll with a program, and ensure that it will never ever interact with the users cygwin1.dll. This is ESPECIALLY true when the code goes to great lengths to be backward compatible. The idea is that you can ALWAYS replace an existing cygwin1.dll with a newer one, without recompiling the old apps that were linked against the old version of the DLL. You of course can't go in the other direction (using an older DLL with newer .exes) but this backwards compatibility is in theory good all the way back to version 1.0.0 from circa 1998-ish. So there is no reason why you should ever need two Cygwin DLLs in the first place, because you can always replace an older one with a newer one. There is at least 1 single reason. There is no possible way for a developer to package a project and deliver it, and guarantee that it will work. Either the user has cygwin installed (possibly catchable). Or the user doesn't have Cygwin installed, installs your package, and then later installs Cygwin (your package just got borked). However, I see your point about backwards compatibity. That's wonderful. If you are writing an installer of a third party application the basic logic should thus be: Is a cygwin1.dll already on the system somewhere? Yes: Is it newer than mine? Yes: Install my .exe, but do not install my cygwin1.dll, use the existing one. No: Prompt user of the situation, and either bail or overwrite older DLL with newer DLL. No: Install my DLL. OK, see my comment above please. Also, what do I do about these jerks? that package cygwin1.dll in there projects even though I have Cygwin installed? Brian, thanks for the input, it's very valuable. All in all, I can live with your suggestions above, and will figure out a way to get done what I need done. I'm just trying to suggest that there is a good reason to possibly do the suggestion I have in the top paragraph. I think it would help the community a lot. People (not developers) downloading softare want to install an executable throng some kind of package installer, and then run an executable. They do not want to install Cygwin, and then start a terminal, and then start a program. This is all just my opinion. Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mismatched dll
So, I guess all I'm saying is it's a complicated issue and there is no 100% foolproof way to go if you want to be a provider of Cygwin-based software that is meant to interact with other Cygwin-based software -- other than perhaps introducing your software as an official package, or telling users to install Cygwin from the cygwin.com mirrors first and then integrating with that. But for some vendors that is too many steps and not turnkey enough. I think at the end of the day, user education as to the nature of the problem is really what is required. Hi Brian, This is very informative. I do have 1 point to make. Software get's better and is easier to use, when the user doesn't have to become to knowledgable about how to install or configure it. IMHO, Cygwin needs a better way to allow distributers to distribute software built on top of it. The windows world could see a lot more smooth open source deliveries if this was possible. Remember, it only takes 2 open source projects doing the correct thing to potentially not work in your scenario. Unless both store the cygwin1.dll in SYSTEM32, or some place where 1 can find the other, there's going to be problems. Right? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: readline-5.1 CGDB
On Mon, Jan 30, 2006 at 07:11:45AM -0700, Eric Blake wrote:
According to Bob Rossi on 1/28/2006 9:19 PM:
On Linux, something totally different happens. When I initialize
readline, it eventually calls tgetent, which happens to set LINES and
COLS to the correct size of the terminal. On cygwin this doesn't happen.
The call readline makes to tgetent leaves LINES and COLS alone. Then,
in Cygwin when I get to initscr, LINES and COLS is set to 25x80, unless
I set the LINES and COLUMNS environment variables before the call to
initscr.
http://www.die.net/doc/linux/man/man3/tgetent.3.html does not document
that tgetent() messes with the environment, but if that is the case, you
may be onto something. Perhaps it really is something cygwin1.dll needs
to patch to be more similar to linux.
I've finally produced a small test case like you asked me too. It did
take some time, but it should certainly help discover the problem. I've
attached the program.
Basically, you can run the program like './main' and that will have
readline operate on stdout, or you can run it like './main use_pty' and
that will have readline operate on a PTY that I have created. Besides
the code that opens the PTY, there is only the main function, and a
function that modifies the readline library.
If you run with the use_pty option, then ncurses thinks the terminal
size is 25x80 after the call to rl_reset_terminal. Here's the output:
[EMAIL PROTECTED] ~/cvs/cgdb/builddir/tmp] $ ./main.exe use_pty
before rline_initialize LINES=0 COLS=0
before rl_callback LINES=0 COLS=0
after rl_callback LINES=75 COLS=85
before rl_reset_terminal LINES=75 COLS=85
after rl_reset_terminal LINES=25 COLS=80
after rline_initialize LINES=25 COLS=80
before initscr LINES=25 COLS=80
after initscr LINES=25 COLS=80
However, if you run without that option, then ncurses thinks the terminal
size is the correct terminal size. Here's the output:
[EMAIL PROTECTED] ~/cvs/cgdb/builddir/tmp] $ ./main
before rline_initialize LINES=0 COLS=0
before rl_callback LINES=0 COLS=0
(tgdb) after rl_callback LINES=75 COLS=85
before rl_reset_terminal LINES=75 COLS=85
after rl_reset_terminal LINES=75 COLS=85
after rline_initialize LINES=75 COLS=85
before initscr LINES=75 COLS=85
after initscr LINES=75 COLS=85
I've tracked down the code in readline to the line that manipulates the
LINES/COLS curses variables when initialize readline with a PTY. (This
same code does not modify the LINES/COLS variable when readline is
initialized with stdout).
The code is in terminal.c:_rl_init_terminal_io line 420 for me. It looks
like
tgetent_ret = tgetent (term_buffer, term);
where term is the string dumb.
What I can't understand is, why would tgetent act differently when I
initialize readline with a created PTY, instead of stdout?
Thanks,
Bob Rossi
#include stdio.h
#include curses.h
#include readline/readline.h
#include termios.h
#include unistd.h
#include stdlib.h
/*
PTY CODE ***
/
#define SLAVE_SIZE 64
static size_t strlcpy_local(char *dst, const char *src, size_t size) {
const char *s = src;
char *d = dst;
size_t n = size;
if (n)
while (--n (*d++ = *s++)) {}
if (n == 0) {
if (size)
*d = '\0';
while (*s++) {}
}
return s - src - 1;
}
int pty_open(
int *masterfd,
int *slavefd,
char *slavename,
size_t slavenamesize,
const struct termios *slave_termios,
const struct winsize *slave_winsize)
{
char *name;
if (!masterfd || !slavefd || !slavename || slavenamesize 64)
return -1;
if ((*masterfd = open(/dev/ptmx, 2 | 0x8000)) == -1)
return -1;
if (grantpt(*masterfd) == -1)
{
close(*masterfd);
return -1;
}
if (unlockpt(*masterfd) == -1)
{
close(*masterfd);
return -1;
}
if (!(name = ptsname(*masterfd)))
{
close(*masterfd);
return -1;
}
if (strlcpy_local(slavename, name, slavenamesize) = slavenamesize)
{
close(*masterfd);
return -1;
}
if ((*slavefd = open(slavename, 2 | 0x8000)) == -1)
{
close(*masterfd);
return -1;
}
if (slave_termios tcsetattr(*slavefd, 2, slave_termios) == -1)
{
close(*masterfd);
close(*slavefd);
return -1;
}
if (slave_winsize ioctl(*slavefd, (('T' 8) | 2), slave_winsize) == -1)
{
close(*masterfd);
close(*slavefd);
return -1;
}
return 0;
}
struct pty_pair
{
int masterfd;
int slavefd;
char slavename[SLAVE_SIZE];
};
typedef struct pty_pair *pty_pair_ptr;
pty_pair_ptr pty_pair_create (void)
{
int val;
static char local_slavename[SLAVE_SIZE];
pty_pair_ptr ptr = (pty_pair_ptr)malloc (sizeof (struct pty_pair));
if (!ptr)
return NULL;
ptr
Re: readline-5.1 CGDB
On Mon, Jan 30, 2006 at 10:50:13AM -0500, Bob Rossi wrote: On Mon, Jan 30, 2006 at 07:11:45AM -0700, Eric Blake wrote: According to Bob Rossi on 1/28/2006 9:19 PM: On Linux, something totally different happens. When I initialize readline, it eventually calls tgetent, which happens to set LINES and COLS to the correct size of the terminal. On cygwin this doesn't happen. The call readline makes to tgetent leaves LINES and COLS alone. Then, in Cygwin when I get to initscr, LINES and COLS is set to 25x80, unless I set the LINES and COLUMNS environment variables before the call to initscr. http://www.die.net/doc/linux/man/man3/tgetent.3.html does not document that tgetent() messes with the environment, but if that is the case, you may be onto something. Perhaps it really is something cygwin1.dll needs to patch to be more similar to linux. I've finally produced a small test case like you asked me too. It did take some time, but it should certainly help discover the problem. I've attached the program. And at last I believe I found the problem, but only after compiling ncurses with debug. The function shell.c:sh_set_lines_and_columns in readline sets the LINES and COLUMNS environment variables. It get's it's data from the PTY you assign to rl_instream. The LINES and COLUMNS environment variables effect the way ncurses work. If they are set, ncurses assumes that the size of the terminal is LINESxCOLUMNS and sets the ncurses variables LINES and COLS appopriatly. So, when I give readline a PTY, if the size of the LINES and COLUMNS are different then that of stdout, then ncurses get's confused. Chet, do you consider this desired functionality? I don't think readline should modify the LINES and COLUMNS environment variables if the PTY it's using is not stdout. What do you think? Anyways, for know, I can probably try to make the PTY I give readline the same size as the stdout PTY. Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: readline-5.1 CGDB
On Fri, Jan 27, 2006 at 03:36:19PM -0700, Eric Blake wrote: According to Bob Rossi on 1/27/2006 3:08 PM: Hi, I finally managed to compile CGDB with readline-5.1 statically. I compiled against a version of readline that has multibyte turned on, and a version with it turned off. In both cases I have the same results. CGDB is displayed awkardly in the curses window. I have finally discovered that this appears to be a LINES/COLS bug. If I connect via putty into the windows machine, and set the putty window to be 25/80 LINES/COLUMNS, then all works. Otherwise, the terminal is the wrong size. Can you provide any more details? How about a simple, reproducible test case? Otherwise, you are pretty much debugging this on your own. I'll work on a simple test case. However, it may take a while. I've spent countless hours trying to determine what the problem could be. I know that if I set the LINES and COLUMNS environment variables, then the display works fine. If I don't set them, then the display must be 25x80 for CGDB to look correct. For some reason, after the call to initscr, the LINES and COLS is set to 25 and 80 respectivly. On Linux, something totally different happens. When I initialize readline, it eventually calls tgetent, which happens to set LINES and COLS to the correct size of the terminal. On cygwin this doesn't happen. The call readline makes to tgetent leaves LINES and COLS alone. Then, in Cygwin when I get to initscr, LINES and COLS is set to 25x80, unless I set the LINES and COLUMNS environment variables before the call to initscr. Finally, if I make a small program on Cygwin, and simply call initscr, it somehow get's the size of the terminal correct. I have no idea why CGDB is different. I have 2 choices at this point. Start debugging the ncurses library or simply keep making CGDB smaller and smaller until I track down the problem. I wonder which is best. Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
readline-5.1 CGDB
Hi, I finally managed to compile CGDB with readline-5.1 statically. I compiled against a version of readline that has multibyte turned on, and a version with it turned off. In both cases I have the same results. CGDB is displayed awkardly in the curses window. I have finally discovered that this appears to be a LINES/COLS bug. If I connect via putty into the windows machine, and set the putty window to be 25/80 LINES/COLUMNS, then all works. Otherwise, the terminal is the wrong size. I'm convinced the problem is the call into readline. Is it possible there were any changes to readline that would effect this? I'm sure other curses apps will notice this problem, so it would be nice to fix it before the next readline minor release. I'm still working on it ... Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: readline-5.1-1, libreadline6-5.1-1
On Thu, Jan 26, 2006 at 06:47:46AM -0700, Eric Blake wrote: According to Bob Rossi on 1/25/2006 4:21 PM: Is there any known bugs with readline-5.1 on Cygwin? I've tracked down my problem compiling and running CGDB to this package. No known cygwin-specific bugs, but definitely upstream bugs, or perhaps also bugs in the terminfo database. Read the last few day's worth of complaints about prompt display bugs caused by readline mishandling terminfo settings when compiled for multibyte support (and I'm still trying to put together a readline-5.1-2 release that at least works around this). OK, thanks for the info. In linux, everything works fine, although I know these problems could lie anywhere. CGDB uses the alternative callback mechanism of the readline library. I had several contributions to readline, which improved the readline library's alterntive callback mode. You are welcome to compile readline from source, with full debugging symbols, and help debug this issue. I must admit that although I maintain readline, I have not compiled anything but bash that uses it, and even then, I relied on out-of-the-box usage of readline. So I won't be much help in discovering where the alternative callback mechanism seems to go wrong for you. Yeah, CGDB may be the only packages that uses the alternative interface. Before 5.1 the interface did not work properly, and would cause hangs. OK, I did figure out how to compile readline-5.1, however, I couldn't figure out how to link against it. I was only able to link against the system installed readline. Any suggestions? Does the Cygwin distro patch readline-5.1? If so, where can I see these patches? Use setup.exe to download the source for any package included in the cygwin distribution; the source tarball includes my cygwin-specific patches (mainly a workaround to speed up completion on //, and an extra hook function required by the cygwin release of bash 3.0-9). Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: readline-5.1-1, libreadline6-5.1-1
A new release of readline and libreadline6, 5.1-1, is available for use, replacing 5.0-4. Is there any known bugs with readline-5.1 on Cygwin? I've tracked down my problem compiling and running CGDB to this package. In linux, everything works fine, although I know these problems could lie anywhere. CGDB uses the alternative callback mechanism of the readline library. I had several contributions to readline, which improved the readline library's alterntive callback mode. Does the Cygwin distro patch readline-5.1? If so, where can I see these patches? Basically, I think when I link to readline and call rl_callback_handler_install, it is modifing the terminal on stdout, even though I don't run readline on that terminal. I open a new terminal, and apply readline to that. Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: curses.h (Attn: bash and setup maintainers)
In any case, looks like all the postinstall scripts ran for you, so you should be good to go. Hi Igor, So do you think that I broke CGDB somehow? When I compile and run it on Cygwin, it's display in the terminal is not correct. However, if I run a pre-compiled older version, it's display is fine. I'm going to build an older version today, and see if it still works. Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: curses.h
On Sat, Jan 21, 2006 at 05:31:24PM -0500, Igor Peshansky wrote: On Sat, 21 Jan 2006, Bob Rossi wrote: On Sat, Jan 21, 2006 at 11:33:42AM -0700, Eric Blake wrote: According to Bob Rossi on 1/21/2006 8:15 AM: Yup, things are screwed up all right. Not Found: sh Use setup.exe to reinstall the bash package; I would also reinstall libncurses-devel in case its postinstall failed to run because of problems with sh. sh is essential for normal cygwin operation. I will do this on Monday. However, is there a way to tell cygwin to fix all packages? Just in case others are broken? Once you have /bin/sh, you can re-run all postinstall scripts (go to /etc/postinstall and run everything that ends in .sh.done). Well, all is going well. I reinstalled bash, and the ncurses-devel package, along with all of the ncurses packages. And finally /usr/include/curses.h is there, so CGDB goes through configure fine. I did try your suggestions about for I in *.sh.done; do ./$I; done, however, it was producing lot's of errors, so I stopped it. The problem is now, when I run CGDB, the terminal is being skewed. So the display is incorrect. However, if I run a preinstalled version, then it works just fine. So I know it's a problem with the one I'm building. Has anything recently changed with libncurses? or has anyone seen problems like this recently? Thanks, and sorry for all the trouble. Bob Rossi Cygwin Configuration Diagnostics Current System Time: Mon Jan 23 09:49:14 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: c:\Lint C:\cygwin\home\bar\bin C:\cygwin\home\bar\bin\fun C:\cygwin\usr\packages\distcc-2.18.3\bin C:\cygwin\home\bar\bin C:\cygwin\home\Qt\tmake-1.4\bin C:\cygwin\home\Qt\qt-2.3.0\bin C:\cygwin\usr\X11R6\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin c:\Perl\bin c:\GNAT\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\InstallShield\InstallShield 5.5 Professional Edition\Program Output from C:\cygwin\bin\id.exe (nontsec) UID: 1003(bar) GID: 513(None) 513(None) 544(Administrators) 545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1003(bar) GID: 513(None) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'bar' PWD = '/home/bar/cvs/cgdb/builddir' HOME = '/home/bar' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\bar.BAR-NT' MANPATH = ':/usr/ssl/man:/usr/X11R6/man' APPDATA = 'C:\Documents and Settings\bar.BAR-NT\Application Data' GNATMAKE = 'gnatmake -j5' HOSTNAME = 'bar-nt' VS71COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\' VCAST_ASSERTIONS = 'true' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 2 Stepping 7, GenuineIntel' WINDIR = 'C:\WINDOWS' VCAST_VRESULT_SHOW_ERRORS = 'true' LATEST = '/home/LATEST' CVSROOT = ':pserver:[EMAIL PROTECTED]:/home/CVS/cvsroot' PUBLIC = '/home/PUBLIC' OLDPWD = '/home/bar/cvs/cgdb' USERDOMAIN = 'BAR-NT' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users.WINDOWS' USERS = '/home/USERS' !:: = '::\' TEMP = '/cygdrive/c/DOCUME~1/BAR~1.BAR/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' LIB = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\' USERNAME = 'bar' PROCESSOR_LEVEL = '15' BASELINE = '/home/BASELINE' VCAST_SPLASH_TIMEOUT = '0' BUILD = '/home/BUILD' GHS_LMHOST = '@ultra' FP_NO_HOST_CHECK = 'NO' BASH_PROFILE_CONFIG_DIR = '/home/USERS/bar/cvs/bob/config/bash' SYSTEMDRIVE = 'C:' EDITOR = 'vim' BASH_PROFILE_NETWORK_NAME = 'vector' VECTORCAST_DIR = 'c:\vcast\baseline' USERPROFILE = 'C:\Documents and Settings\bar.BAR-NT' CLIENTNAME = 'Console' PS1 = '[EMAIL PROTECTED] \w] $ ' LOGONSERVER = '\\BAR-NT' LM_LICENSE_FILE = '[EMAIL PROTECTED]' PROCESSOR_ARCHITECTURE = 'x86' !C: = 'C:\cygwin\bin' SHLVL = '1' NOGUI = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'C:' SSHHACK = 'rossi' BASH_PROFILE_OS = 'CYGWIN_NT-5.1' PROMPT = '$P$G' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/cygdrive/c/DOCUME~1/BAR~1.BAR/LOCALS~1/Temp' SYSTEMROOT = 'C:\WINDOWS' FLEXLM = 'h:/flexLM' CVS_RSH = 'ssh' PROCESSOR_REVISION = '0207' PKG_CONFIG_PATH = '/usr/X11R6/lib/pkgconfig' PROGRAMFILES = 'C:\Program Files' DELIVER = '/home/DELIVER' NUMBER_OF_PROCESSORS = '1' INCLUDE = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include\' SESSIONNAME = 'Console' COMPUTERNAME = 'BAR-NT' VCAST_VRESULT_ATTACH_DB_CMD = 'xterm -geom 80x60 -e cgdb --pid=%p' _ = '/usr/bin/cygcheck' POSIXLY_CORRECT = '1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/tmp (default) = 'C:\Documents and Settings
Re: curses.h
On Mon, Jan 23, 2006 at 11:06:09AM -0500, Igor Peshansky wrote: On Mon, 23 Jan 2006, Bob Rossi wrote: On Sat, Jan 21, 2006 at 05:31:24PM -0500, Igor Peshansky wrote: On Sat, 21 Jan 2006, Bob Rossi wrote: I will do this on Monday. However, is there a way to tell cygwin to fix all packages? Just in case others are broken? Once you have /bin/sh, you can re-run all postinstall scripts (go to /etc/postinstall and run everything that ends in .sh.done). [snip] I did try your suggestions about for I in *.sh.done; do ./$I; done, however, it was producing lot's of errors, so I stopped it. Heh? lot's of errors (sic) isn't particularly descriptive... What errors were you getting, exactly? Note that until you've run all postinstall scripts, your installation will not be in a consistent state. Hi Igor, Here's the command I ran, along with output. for I in *.sh.done; do ./$I; done ~/out.txt 21 Thanks, Bob Rossi ./00bash.sh.done: line 12: ./01bash.bat: No such file or directory cp: cannot stat `./01bash.bat.t': No such file or directory rm: cannot remove `./01bash.bat.t': No such file or directory dpsexec:Display PostScript command interface:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Tools:: dpsinfo:The Display PostScript extension:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Information:: fc-list:List available FreeType fonts:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Information:: glxinfo:GLX information:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Information:: showrgb:List rgb database:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Information:: xdpyinfo:Display information:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Information:: xfontsel:Pick a font:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Tools:: xfsinfo:The font server:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Information:: xlsatoms:List available atoms:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Information:: xlsclients:List all connected clients:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Information:: xlsfonts:List all available fonts:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Information:: xprop:Display the propertis of a window:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Information:: xtrapinfo:The TRAP extension:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Information:: xwd:Dump X11 window image to file:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Tools:: xwininfo:A single window:/cygdrive/c/Documents and Settings/All Users.WINDOWS/Start Menu/Programs/Cygwin-X/Information:: ./XFree86-bin-icons.sh.done: line 8: /usr/X11R6/bin/XFree86-bin-icons.sh: No such file or directory /etc/bash.bashrc is already in existance, not overwriting. /etc/DIR_COLORS is already in existance, not overwriting. /etc/profile is already in existance, not overwriting. /etc/skel/.bashrc is already in existance, not overwriting. /etc/skel/.bash_profile is already in existance, not overwriting. /etc/skel/.inputrc is already in existance, not overwriting. install-info: No such file or directory for bzip2.info install-info: No such file or directory for cvs.info install-info: No such file or directory for cvsclient.info *** Unpacking /etc/postinstall/gcc-mingw-core-3.4.4-20050522-1.tgz. Please wait. *** *** Unpacking /etc/postinstall/gcc-mingw-g++-3.4.4-20050522-1.tgz. Please wait. *** install-info: No such file or directory for gdbm.info /usr/share/misc/man.conf is already in existance, not overwriting. install-info: No such file or directory for history.info install-info: No such file or directory for readline.info install-info: No such file or directory for rluserman.info updating /usr/X11R6/lib/X11/fonts/100dpi updating /usr/X11R6/lib/X11/fonts/75dpi updating /usr/X11R6/lib/X11/fonts/misc /usr/X11R6/lib/X11/fonts/CID is not a directory. skipping /usr/X11R6/lib/X11/fonts/TTF is up-todate. skipping /usr/X11R6/lib/X11/fonts/Type1 is up-todate. skipping /usr/X11R6/lib/X11/fonts/cyrillic is not a directory. skipping /usr/X11R6/lib/X11/fonts/local is not a directory. skipping /usr/X11R6/lib/X11/fonts/100dpi is up-todate. skipping /usr/X11R6/lib/X11/fonts/75dpi is up-todate. skipping /usr/X11R6/lib/X11/fonts/misc is up-todate. skipping /usr/X11R6/lib/X11/fonts/CID is not a directory. skipping /usr/X11R6/lib/X11/fonts/TTF is up-todate. skipping /usr/X11R6/lib/X11/fonts/Type1 is up-todate. skipping /usr/X11R6/lib/X11/fonts/cyrillic is not a directory. skipping /usr/X11R6/lib/X11/fonts/local
Re: curses.h
On Sat, Jan 21, 2006 at 08:01:36AM -0700, Eric Blake wrote: According to Bob Rossi on 1/21/2006 7:29 AM: I can admit that I changed the version of automake that I was using, however I don't think that has much to do with looking for the files. Here the related config.log. Has anything changed with Cygwin that would cause this? Let's look at this a little closer: configure:6066: checking curses.h presence configure:6076: gcc -E conftest.c conftest.c:49:20: curses.h: No such file or directory configure:6082: $? = 1 Somehow, you've messed up your compilation environment. You need to figure out why the compiler can't find headers. Something to try would be taking the failed program (the next few lines in config.log), making a file with just those contents, and running the same gcc command line that configure tried, with -v added to see if gcc tells you more about the failure (such as which directories it searched). Also, you may want to repost your cygcheck output, with your current setup (the last one you posted, at http://cygwin.com/ml/cygwin/2006-01/msg00986.html, claimed that sh was not found, which hopefully has changed or you wouldn't have been able to run configure), to see if anyone spots a glaring problem in your setup. Yup, things are screwed up all right. [EMAIL PROTECTED] ~/cvs/cgdb/builddir/tmp] $ which gcc /usr/bin/gcc [EMAIL PROTECTED] ~/cvs/cgdb/builddir/tmp] $ gcc --version gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED] ~/cvs/cgdb/builddir/tmp] $ cat foo.c #include curses.h [EMAIL PROTECTED] ~/cvs/cgdb/builddir/tmp] $ gcc -c foo.c foo.c:1:20: curses.h: No such file or directory Is this expected behavior? I'm assuming you think I've broken something on my end. If so, sorry. Another change I've made since this worked last was that I updated my Cygwin install. Probably hadn't done that in a year or so before. Geez, now that I'm writing this, I remember that when it was updating, there were errors at the end, like rm ... failed. But I thought that might have been OK. Great, this could be bad news. Sorry for not stating this in the first place, I didn't remember. BTW, Thanks for the great work distributing readline! My application depends on the library being around. Thanks, Bob Rossi Cygwin Configuration Diagnostics Current System Time: Sat Jan 21 10:08:00 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: c:\Lint C:\cygwin\home\bar\bin C:\cygwin\home\bar\bin\fun C:\cygwin\usr\packages\distcc-2.18.3\bin C:\cygwin\home\bar\bin C:\cygwin\home\Qt\tmake-1.4\bin C:\cygwin\home\Qt\qt-2.3.0\bin C:\cygwin\usr\X11R6\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin c:\Perl\bin c:\GNAT\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\InstallShield\InstallShield 5.5 Professional Edition\Program C:\cygwin\bin Output from C:\cygwin\bin\id.exe (nontsec) UID: 1003(bar) GID: 513(None) 513(None) 544(Administrators) 545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1003(bar) GID: 513(None) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'bar' PWD = '/home/bar/cvs/cgdb/builddir/tmp' CYGWIN = 'ntsec' HOME = '/home/bar' MAKE_MODE = 'unix' HOMEPATH = '\cygwin\home\bar' MANPATH = ':/usr/ssl/man:/usr/X11R6/man' GNATMAKE = 'gnatmake -j5' HOSTNAME = 'bar-nt' VCAST_ASSERTIONS = 'true' TERM = 'cygwin' SHELL = '/bin/bash' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 2 Stepping 7, GenuineIntel' WINDIR = 'C:\WINDOWS' SSH_CLIENT = '208.229.91.27 47126 22' VCAST_VRESULT_SHOW_ERRORS = 'true' LATEST = '/home/LATEST' CVSROOT = ':pserver:[EMAIL PROTECTED]:/home/CVS/cvsroot' PUBLIC = '/home/PUBLIC' OLDPWD = '/home/bar/cvs/cgdb/builddir' USERDOMAIN = 'BAR-NT' SSH_TTY = '/dev/tty2' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users.WINDOWS' USERS = '/home/USERS' TEMP = '/cygdrive/c/WINDOWS/TEMP' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'bar' PROCESSOR_LEVEL = '15' BASELINE = '/home/BASELINE' MAIL = '/var/spool/mail/bar' VCAST_SPLASH_TIMEOUT = '0' BUILD = '/home/BUILD' BASH_PROFILE_CONFIG_DIR = '/home/USERS/bar/cvs/bob/config/bash' SYSTEMDRIVE = 'C:' EDITOR = 'vim' BASH_PROFILE_NETWORK_NAME = 'vector' USERPROFILE = 'C:\Documents and Settings\bar.BAR-NT' TZ = 'EST5EST4,M4.1.0/2,M10.5.0/2' PS1 = '[EMAIL PROTECTED] \w] $ ' LOGONSERVER = '\\BAR-NT' LM_LICENSE_FILE = '[EMAIL PROTECTED]' PROCESSOR_ARCHITECTURE = 'x86' SHLVL = '1' NOGUI = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'C:' SSHHACK = 'rossi
Re: curses.h
On Sat, Jan 21, 2006 at 11:33:42AM -0700, Eric Blake wrote: According to Bob Rossi on 1/21/2006 8:15 AM: Yup, things are screwed up all right. Not Found: sh Use setup.exe to reinstall the bash package; I would also reinstall libncurses-devel in case its postinstall failed to run because of problems with sh. sh is essential for normal cygwin operation. I will do this on Monday. However, is there a way to tell cygwin to fix all packages? Just in case others are broken? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
readline 5.1 question
Hi all,
My application recently started depending on readline 5.1. In Cygwin, I
installed in setup.exe
All-Devel-readline, and I have version 5.1-1 as the current.
However, if I compile and run this program,
#include stdio.h
#include readline/readline.h
main()
{
printf(%s\n, rl_library_version ? rl_library_version : 0.0);
exit(0);
}
With this compile line,
gcc -g rl.c -o rl -lreadline
I get this output,
5.0
I think this is a bug, but maybe I've misconfigured, any suggestions?
Thanks,
Bob Rossi
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: readline 5.1 question
On Fri, Jan 20, 2006 at 03:48:01PM +, Eric Blake wrote: Hi all, My application recently started depending on readline 5.1. In Cygwin, I installed in setup.exe All-Devel-readline, and I have version 5.1-1 as the current. Did you also pick up libreadline6-5.1-1? readline-5.1-1 only contains the headers and static link library, but using plain -lreadline without also using -static picks up the dynamic link library. The .dll is purposefully shipped in a different package, since the .dll is required by base packages, but the headers and static libraries are only needed in a development environment. I don't know of a way to make setup.exe force dependencies across experimental versions (ie. if you select just readline-5.1-1, it would be nice if cygwin.exe could then automatically also select libreadline6-5.1-1). Thanks for the prompt reply. Yes, I think I did install that. It's very odd to me that there is libreadline-6-5.1-1, since there is no readline version 6. Are you suggesting the cygwin package manager has no way of dealing with multiple version of a library? By the way, following the directions here, by attaching the output of cygcheck -svr, would have made it more obvious to me if you are experiencing the version mismatch that I think you are: Problem reports: http://cygwin.com/problems.html Sorry, attached is the output. Thanks, Bob Rossi Cygwin Configuration Diagnostics Current System Time: Fri Jan 20 11:07:11 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: c:\Lint C:\cygwin\home\bar\bin C:\cygwin\home\bar\bin\fun C:\cygwin\usr\packages\distcc-2.18.3\bin C:\cygwin\home\bar\bin C:\cygwin\home\Qt\tmake-1.4\bin C:\cygwin\home\Qt\qt-2.3.0\bin C:\cygwin\usr\X11R6\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin c:\Perl\bin c:\GNAT\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\InstallShield\InstallShield 5.5 Professional Edition\Program Output from C:\cygwin\bin\id.exe (nontsec) UID: 1003(bar) GID: 513(None) 513(None) 544(Administrators) 545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1003(bar) GID: 513(None) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'bar' PWD = '/home/bar/cvs/cgdb/tmp' HOME = '/home/bar' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\bar.BAR-NT' MANPATH = ':/usr/ssl/man:/usr/X11R6/man' APPDATA = 'C:\Documents and Settings\bar.BAR-NT\Application Data' GNATMAKE = 'gnatmake -j5' HOSTNAME = 'bar-nt' VS71COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\' VCAST_ASSERTIONS = 'true' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 2 Stepping 7, GenuineIntel' WINDIR = 'C:\WINDOWS' VCAST_VRESULT_SHOW_ERRORS = 'true' LATEST = '/home/LATEST' CVSROOT = ':pserver:[EMAIL PROTECTED]:/home/CVS/cvsroot' PUBLIC = '/home/PUBLIC' OLDPWD = '/home/bar/cvs/cgdb' USERDOMAIN = 'BAR-NT' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users.WINDOWS' USERS = '/home/USERS' !:: = '::\' TEMP = '/cygdrive/c/DOCUME~1/BAR~1.BAR/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' LIB = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\' USERNAME = 'bar' PROCESSOR_LEVEL = '15' BASELINE = '/home/BASELINE' VCAST_SPLASH_TIMEOUT = '0' BUILD = '/home/BUILD' GHS_LMHOST = '@ultra' FP_NO_HOST_CHECK = 'NO' BASH_PROFILE_CONFIG_DIR = '/home/USERS/bar/cvs/bob/config/bash' SYSTEMDRIVE = 'C:' EDITOR = 'vim' BASH_PROFILE_NETWORK_NAME = 'vector' VECTORCAST_DIR = 'c:\vcast\baseline' USERPROFILE = 'C:\Documents and Settings\bar.BAR-NT' CLIENTNAME = 'Console' PS1 = '[EMAIL PROTECTED] \w] $ ' LOGONSERVER = '\\BAR-NT' LM_LICENSE_FILE = '[EMAIL PROTECTED]' PROCESSOR_ARCHITECTURE = 'x86' !C: = 'C:\cygwin\bin' SHLVL = '1' NOGUI = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'C:' SSHHACK = 'rossi' BASH_PROFILE_OS = 'CYGWIN_NT-5.1' PROMPT = '$P$G' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/cygdrive/c/DOCUME~1/BAR~1.BAR/LOCALS~1/Temp' SYSTEMROOT = 'C:\WINDOWS' FLEXLM = 'h:/flexLM' CVS_RSH = 'ssh' PROCESSOR_REVISION = '0207' PKG_CONFIG_PATH = '/usr/X11R6/lib/pkgconfig' PROGRAMFILES = 'C:\Program Files' DELIVER = '/home/DELIVER' NUMBER_OF_PROCESSORS = '1' INCLUDE = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include\' SESSIONNAME = 'Console' COMPUTERNAME = 'BAR-NT' VCAST_VRESULT_ATTACH_DB_CMD = 'xterm -geom 80x60 -e cgdb --pid=%p' _ = '/usr/bin/cygcheck' POSIXLY_CORRECT = '1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/tmp (default) = 'C:\Documents and Settings\bar.BAR-NT\.nx/temp
Re: readline 5.1 question
On Fri, Jan 20, 2006 at 11:09:18AM -0500, Bob Rossi wrote: On Fri, Jan 20, 2006 at 03:48:01PM +, Eric Blake wrote: Hi all, My application recently started depending on readline 5.1. In Cygwin, I installed in setup.exe All-Devel-readline, and I have version 5.1-1 as the current. Did you also pick up libreadline6-5.1-1? readline-5.1-1 only contains the headers and static link library, but using plain -lreadline without also using -static picks up the dynamic link library. The .dll is purposefully shipped in a different package, since the .dll is required by base packages, but the headers and static libraries are only needed in a development environment. I don't know of a way to make setup.exe force dependencies across experimental versions (ie. if you select just readline-5.1-1, it would be nice if cygwin.exe could then automatically also select libreadline6-5.1-1). Thanks for the prompt reply. Yes, I think I did install that. It's very odd to me that there is libreadline-6-5.1-1, since there is no readline version 6. Are you suggesting the cygwin package manager has no way of dealing with multiple version of a library? By the way, following the directions here, by attaching the output of cygcheck -svr, would have made it more obvious to me if you are experiencing the version mismatch that I think you are: Problem reports: http://cygwin.com/problems.html Sorry, attached is the output. OK, actually, I pulled a major NO NO. Sorry. After I read your comments I installed the package. Then I did the cygcheck command. So, things are working fine now, with your help. Thanks very much. Is there any reason this important library isn't installed by default? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
curses.h
Hi all, This is yet another problem that I am having, that did not used to exist. My configure script checks for curses.h and ncurses.h, since I depend on curses to compile CGDB. This used to be detected, but no longer does. checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking curses.h usability... no checking curses.h presence... no checking for curses.h... no Actually, I just added the ncurses check, cause I thought it might be there. Any suggestions? Has something changed with this? Thanks, Bob Rossi Cygwin Configuration Diagnostics Current System Time: Fri Jan 20 12:25:10 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: c:\Lint C:\cygwin\home\bar\bin C:\cygwin\home\bar\bin\fun C:\cygwin\usr\packages\distcc-2.18.3\bin C:\cygwin\home\bar\bin C:\cygwin\home\Qt\tmake-1.4\bin C:\cygwin\home\Qt\qt-2.3.0\bin C:\cygwin\usr\X11R6\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin c:\Perl\bin c:\GNAT\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\InstallShield\InstallShield 5.5 Professional Edition\Program Output from C:\cygwin\bin\id.exe (nontsec) UID: 1003(bar) GID: 513(None) 513(None) 544(Administrators) 545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1003(bar) GID: 513(None) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'bar' PWD = '/home/bar/cvs/cgdb/builddir' HOME = '/home/bar' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\bar.BAR-NT' MANPATH = ':/usr/ssl/man:/usr/X11R6/man' APPDATA = 'C:\Documents and Settings\bar.BAR-NT\Application Data' GNATMAKE = 'gnatmake -j5' HOSTNAME = 'bar-nt' VS71COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\' VCAST_ASSERTIONS = 'true' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 2 Stepping 7, GenuineIntel' WINDIR = 'C:\WINDOWS' VCAST_VRESULT_SHOW_ERRORS = 'true' LATEST = '/home/LATEST' CVSROOT = ':pserver:[EMAIL PROTECTED]:/home/CVS/cvsroot' PUBLIC = '/home/PUBLIC' OLDPWD = '/home/bar/cvs/cgdb' USERDOMAIN = 'BAR-NT' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users.WINDOWS' USERS = '/home/USERS' !:: = '::\' TEMP = '/cygdrive/c/DOCUME~1/BAR~1.BAR/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' LIB = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\' USERNAME = 'bar' PROCESSOR_LEVEL = '15' BASELINE = '/home/BASELINE' VCAST_SPLASH_TIMEOUT = '0' BUILD = '/home/BUILD' GHS_LMHOST = '@ultra' FP_NO_HOST_CHECK = 'NO' BASH_PROFILE_CONFIG_DIR = '/home/USERS/bar/cvs/bob/config/bash' SYSTEMDRIVE = 'C:' EDITOR = 'vim' BASH_PROFILE_NETWORK_NAME = 'vector' VECTORCAST_DIR = 'c:\vcast\baseline' USERPROFILE = 'C:\Documents and Settings\bar.BAR-NT' CLIENTNAME = 'Console' PS1 = '[EMAIL PROTECTED] \w] $ ' LOGONSERVER = '\\BAR-NT' LM_LICENSE_FILE = '[EMAIL PROTECTED]' PROCESSOR_ARCHITECTURE = 'x86' !C: = 'C:\cygwin\bin' SHLVL = '1' NOGUI = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'C:' SSHHACK = 'rossi' BASH_PROFILE_OS = 'CYGWIN_NT-5.1' PROMPT = '$P$G' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/cygdrive/c/DOCUME~1/BAR~1.BAR/LOCALS~1/Temp' SYSTEMROOT = 'C:\WINDOWS' FLEXLM = 'h:/flexLM' CVS_RSH = 'ssh' PROCESSOR_REVISION = '0207' PKG_CONFIG_PATH = '/usr/X11R6/lib/pkgconfig' PROGRAMFILES = 'C:\Program Files' DELIVER = '/home/DELIVER' NUMBER_OF_PROCESSORS = '1' INCLUDE = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include\' SESSIONNAME = 'Console' COMPUTERNAME = 'BAR-NT' VCAST_VRESULT_ATTACH_DB_CMD = 'xterm -geom 80x60 -e cgdb --pid=%p' _ = '/usr/bin/cygcheck' POSIXLY_CORRECT = '1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/tmp (default) = 'C:\Documents and Settings\bar.BAR-NT\.nx/temp/' HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00 (default) = '\\.\tape1:' unix = '/dev/st1' fbinary = 0x fsilent = 0x0001 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01 (default) = '\\.\tape0:' unix = '/dev/st0' fbinary = 0x fsilent = 0x0001 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02 (default) = '\\.\b:' unix = '/dev/fd1' fbinary = 0x fsilent = 0x0001 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\03
dll version mismatch
Hi, I looked around and couldn't find this info anywhere, sorry in advance if it's a simple question. I am using GNAT GDB on windows. Apparently it was built with cygwin. [EMAIL PROTECTED] /cygdrive/c/GNAT] $ cygcheck 'C:\GNAT\bin\gdb.exe' C:/GNAT/bin/gdb.exe C:/GNAT/bin\cyggnat.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\USER32.dll C:\WINDOWS\system32\GDI32.dll cyggnat.dll must be there cygwin1.dll linked in and renamed. If I run the program in dos, it works fine, C:\C:\GNAT\bin\gdb.exe GNU gdb 5.0.gnat.3.15p Copyright 2000 Free Software Foundation, Inc. Ada Core Technologies version of GDB for GNAT Professional GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. See your support agreement for details of warranty and support. If you do not have a current support agreement, then there is absolutely no warranty for this version of GDB. Type show warranty for details. This GDB was configured as i686-pc-cygwin. (gdb) If I run it in cygwin I get, [EMAIL PROTECTED] ~] $ /cygdrive/c/GNAT/bin/gdb.exe c:\GNAT\bin\gdb.exe: *** proc version mismatch detected - 0x5751/0x8B3C. You have multiple copies of cygwin1.dll on your system. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. [EMAIL PROTECTED] ~] $ Does anyone know how I can run this program without problems on cygwin? Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
