Greetings,
I'm trying to get 0.13 to compile and it gets to here and hangs.
configure: WARNING: using single-threaded resolver with gethostbyaddr Consider obtaining ARES or a machine with a working gethostbyaddr_r. checking where to find pcap.h... /include checking for pcap_open_live in -lpcap... yes checking pcap.h usability... yes checking pcap.h presence... yes checking for pcap.h... yes checking for a curses library containing mvchgat... -lcurses checking how to compile a working program with POSIX threads...
Any ideas?
thanks,
Siri Dhyan Singh
On Fri, Aug 22, 2003 at 05:41:30PM -0700, Siri Dhyan Singh wrote:
Greetings,
I'm trying to get 0.13 to compile and it gets to here and hangs.
configure: WARNING: using single-threaded resolver with gethostbyaddr Consider obtaining ARES or a machine with a working gethostbyaddr_r. checking where to find pcap.h... /include checking for pcap_open_live in -lpcap... yes checking pcap.h usability... yes checking pcap.h presence... yes checking for pcap.h... yes checking for a curses library containing mvchgat... -lcurses checking how to compile a working program with POSIX threads...
Any ideas?
Yep. It's a brokenness in Mac OS's POSIX threads routines. I'll try to do a fix later.
Chris Lightfoot wrote:
On Fri, Aug 22, 2003 at 05:41:30PM -0700, Siri Dhyan Singh wrote:
Greetings,
I'm trying to get 0.13 to compile and it gets to here and hangs.
configure: WARNING: using single-threaded resolver with gethostbyaddr Consider obtaining ARES or a machine with a working gethostbyaddr_r. checking where to find pcap.h... /include checking for pcap_open_live in -lpcap... yes checking pcap.h usability... yes checking pcap.h presence... yes checking for pcap.h... yes checking for a curses library containing mvchgat... -lcurses checking how to compile a working program with POSIX threads...
Any ideas?
Yep. It's a brokenness in Mac OS's POSIX threads routines. I'll try to do a fix later.
Alright thanks!
I'm fairly lightweight when it comes to C/C++ but I do have a programming background so if there's anything I can do to help please let me know.
Kind Regards,
-Siri Dhyan
On Sat, Aug 23, 2003 at 10:06:23AM -0700, Siri Dhyan Singh wrote:
Chris Lightfoot wrote:
Yep. It's a brokenness in Mac OS's POSIX threads routines. I'll try to do a fix later.
(At this point I should say that I think the Mac OS behaviour is in fact standards-compliant, but unhelpful.)
Alright thanks!
I'm fairly lightweight when it comes to C/C++ but I do have a programming background so if there's anything I can do to help please let me know.
Have you tried the two patches I sent? iftop compiles fine on my Mac now but I suspect my version is a little out of sync with 0.13.
(Stop reading here if you don't want to know the gory details.)
The background to this problem: different systems need different combinations of compiler options to get working POSIX threads support. Linux and Solaris, in particular, are quite different, and IIRC the compiler options which work on Linux give programs which compile *but when run cannot start threads* on Solaris.
So config/pthread.c is a small test program which spawns a thread which then changes the value of a variable; the controlling thread then cancels the subthread and verifies that the variable's value has changed. This allows us to detect whether we have threads that work at all; the configure script can try compiling this program with various different options until it works.
Unfortunately, on Mac OS X, the program hung while trying to cancel (==kill) the subthread. This was because I had assumed -- incorrectly, it seems -- that the function yield(2) was a cancellation point. While it is (or appears to be) on Linux and Solaris, it isn't in Mac OS X. While this might seem surprising, it apparently conforms to the standard. Slightly more surprisingly, replacing yield() with sleep(1) also caused the thing to hang, which I believe is wrong, since http://www.opengroup.org/onlinepubs/7908799/xsh/threads.html lists sleep as a cancellation point.
The take home message? Threads: Just Say No.
Chris Lightfoot wrote:
On Sat, Aug 23, 2003 at 10:06:23AM -0700, Siri Dhyan Singh wrote:
Chris Lightfoot wrote:
Yep. It's a brokenness in Mac OS's POSIX threads routines. I'll try to do a fix later.
(At this point I should say that I think the Mac OS behaviour is in fact standards-compliant, but unhelpful.)
Alright thanks!
I'm fairly lightweight when it comes to C/C++ but I do have a programming background so if there's anything I can do to help please let me know.
Have you tried the two patches I sent? iftop compiles fine on my Mac now but I suspect my version is a little out of sync with 0.13.
I just applied the patches and it seems to be working fine. I supply a n interface of en0 as its OS X and I'm off and running.
(Stop reading here if you don't want to know the gory details.)
The background to this problem: different systems need different combinations of compiler options to get working POSIX threads support. Linux and Solaris, in particular, are quite different, and IIRC the compiler options which work on Linux give programs which compile *but when run cannot start threads* on Solaris.
ahh how nice and frustrating :-)
So config/pthread.c is a small test program which spawns a thread which then changes the value of a variable; the controlling thread then cancels the subthread and verifies that the variable's value has changed. This allows us to detect whether we have threads that work at all; the configure script can try compiling this program with various different options until it works.
Unfortunately, on Mac OS X, the program hung while trying to cancel (==kill) the subthread. This was because I had assumed -- incorrectly, it seems -- that the function yield(2) was a cancellation point. While it is (or appears to be) on Linux and Solaris, it isn't in Mac OS X. While this might seem surprising, it apparently conforms to the standard. Slightly more surprisingly, replacing yield() with sleep(1) also caused the thing to hang, which I believe is wrong, since http://www.opengroup.org/onlinepubs/7908799/xsh/threads.html lists sleep as a cancellation point.
The take home message? Threads: Just Say No.
many thanks
-Siri dhyan
Siri Dhyan Singh wrote:
Chris Lightfoot wrote:
On Sat, Aug 23, 2003 at 10:06:23AM -0700, Siri Dhyan Singh wrote:
Chris Lightfoot wrote:
Yep. It's a brokenness in Mac OS's POSIX threads routines. I'll try to do a fix later.
(At this point I should say that I think the Mac OS behaviour is in fact standards-compliant, but unhelpful.)
Alright thanks!
I'm fairly lightweight when it comes to C/C++ but I do have a programming background so if there's anything I can do to help please let me know.
Have you tried the two patches I sent? iftop compiles fine on my Mac now but I suspect my version is a little out of sync with 0.13.
I just applied the patches and it seems to be working fine. I supply a n interface of en0 as its OS X and I'm off and running.
A little more background here. Basically on OS X 10.2.6 (and other BSDs I suspect) I'm pulling up a couple of pseudo devices used for tunneling which are probably not appropriate as defaults for iftop. Here's a little patch. My first code contribution to an open source project - a historic moment ;-).
diff -u options.orig options.c --- options.orig Mon Aug 25 15:30:26 2003 +++ options.c Mon Aug 25 15:33:32 2003 @@ -40,6 +40,8 @@ static char *bad_interface_names[] = { "lo:", "lo", + "stf", //pseudo-device 6to4 tunnel interface + "gif", //psuedo-device generic tunnel interface "dummy", "vmnet", NULL /* last entry must be NULL */
Kind Regards,
Siri Dhyan
(Stop reading here if you don't want to know the gory details.)
The background to this problem: different systems need different combinations of compiler options to get working POSIX threads support. Linux and Solaris, in particular, are quite different, and IIRC the compiler options which work on Linux give programs which compile *but when run cannot start threads* on Solaris.
ahh how nice and frustrating :-)
So config/pthread.c is a small test program which spawns a thread which then changes the value of a variable; the controlling thread then cancels the subthread and verifies that the variable's value has changed. This allows us to detect whether we have threads that work at all; the configure script can try compiling this program with various different options until it works.
Unfortunately, on Mac OS X, the program hung while trying to cancel (==kill) the subthread. This was because I had assumed -- incorrectly, it seems -- that the function yield(2) was a cancellation point. While it is (or appears to be) on Linux and Solaris, it isn't in Mac OS X. While this might seem surprising, it apparently conforms to the standard. Slightly more surprisingly, replacing yield() with sleep(1) also caused the thing to hang, which I believe is wrong, since http://www.opengroup.org/onlinepubs/7908799/xsh/threads.html lists sleep as a cancellation point.
The take home message? Threads: Just Say No.
many thanks
-Siri dhyan
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
On Mon, Aug 25, 2003 at 03:50:50PM -0700, Siri Dhyan Singh wrote:
Siri Dhyan Singh wrote:
I just applied the patches and it seems to be working fine. I supply a n interface of en0 as its OS X and I'm off and running.
A little more background here. Basically on OS X 10.2.6 (and other BSDs I suspect) I'm pulling up a couple of pseudo devices used for tunneling which are probably not appropriate as defaults for iftop. Here's a little patch. My first code contribution to an open source project - a historic moment ;-).
diff -u options.orig options.c --- options.orig Mon Aug 25 15:30:26 2003 +++ options.c Mon Aug 25 15:33:32 2003 @@ -40,6 +40,8 @@ static char *bad_interface_names[] = { "lo:", "lo",
"stf", //pseudo-device 6to4 tunnel interface
[ Tiny suggestion: better to use /* ... */ comments in C programs, since // is not universally supported yet. ]
"gif", //psuedo-device generic tunnel interface "dummy", "vmnet", NULL /* last entry must be NULL */
Noted. Many thanks.
Chris Lightfoot wrote:
On Mon, Aug 25, 2003 at 03:50:50PM -0700, Siri Dhyan Singh wrote:
Siri Dhyan Singh wrote:
I just applied the patches and it seems to be working fine. I supply a n interface of en0 as its OS X and I'm off and running.
A little more background here. Basically on OS X 10.2.6 (and other BSDs I suspect) I'm pulling up a couple of pseudo devices used for tunneling which are probably not appropriate as defaults for iftop. Here's a little patch. My first code contribution to an open source project - a historic moment ;-).
diff -u options.orig options.c --- options.orig Mon Aug 25 15:30:26 2003 +++ options.c Mon Aug 25 15:33:32 2003 @@ -40,6 +40,8 @@ static char *bad_interface_names[] = { "lo:", "lo",
"stf", //pseudo-device 6to4 tunnel interface[ Tiny suggestion: better to use /* ... */ comments in C programs, since // is not universally supported yet. ]
And here I was wondering why you had used multiline comments for single lines having forgotten that tidbit about C. I'll keep that in mind going forward.
"gif", //psuedo-device generic tunnel interface "dummy", "vmnet", NULL /* last entry must be NULL */Noted. Many thanks.
On Fri, Aug 22, 2003 at 05:41:30PM -0700, Siri Dhyan Singh wrote:
Greetings,
I'm trying to get 0.13 to compile and it gets to here and hangs.
configure: WARNING: using single-threaded resolver with gethostbyaddr Consider obtaining ARES or a machine with a working gethostbyaddr_r. checking where to find pcap.h... /include checking for pcap_open_live in -lpcap... yes checking pcap.h usability... yes checking pcap.h presence... yes checking for pcap.h... yes checking for a curses library containing mvchgat... -lcurses checking how to compile a working program with POSIX threads...
Any ideas?
Please could you try applying the following patch and re-running configure?
diff -u -r1.1 pthread.c --- config/pthread.c 2002/11/04 12:27:35 1.1 +++ config/pthread.c 2003/08/23 18:29:11 @@ -24,7 +24,7 @@ pthread_cond_signal(&cond); pthread_mutex_unlock(&mtx); while (1) - pause(); + pthread_testcancel(); }
On Fri, Aug 22, 2003 at 05:41:30PM -0700, Siri Dhyan Singh wrote:
Greetings,
I'm trying to get 0.13 to compile and it gets to here and hangs.
configure: WARNING: using single-threaded resolver with gethostbyaddr Consider obtaining ARES or a machine with a working gethostbyaddr_r.
[ aside to Paul: Mac OS X, being BSD, has no thread-safe way to resolve names. There is no need to act surprised at this point. But maybe we should write a Netscape-style forking asynchronous resolver? ]
checking where to find pcap.h... /include checking for pcap_open_live in -lpcap... yes checking pcap.h usability... yes checking pcap.h presence... yes checking for pcap.h... yes checking for a curses library containing mvchgat... -lcurses checking how to compile a working program with POSIX threads...
Any ideas?
with the patch I just sent, and the following:
diff -u -r1.32 options.c --- options.c 2003/03/01 01:55:13 1.32 +++ options.c 2003/08/23 18:33:21 @@ -134,7 +134,7 @@ options.netfiltermask.s_addr = htonl(0xffffffffl); } else { - uint32_t mm = 0xffffffffl; + u_int32_t mm = 0xffffffffl; mm >>= n; options.netfiltermask.s_addr = htonl(~mm); }
iftop compiles and runs happily.
On Sat, Aug 23, 2003 at 07:36:44PM +0100, Chris Lightfoot wrote:
On Fri, Aug 22, 2003 at 05:41:30PM -0700, Siri Dhyan Singh wrote:
Greetings,
I'm trying to get 0.13 to compile and it gets to here and hangs.
configure: WARNING: using single-threaded resolver with gethostbyaddr Consider obtaining ARES or a machine with a working gethostbyaddr_r.
[ aside to Paul: Mac OS X, being BSD, has no thread-safe way to resolve names. There is no need to act surprised at this point. But maybe we should write a Netscape-style forking asynchronous resolver? ]
I assume you are speaking of a different type of asynchronous resolver to that found in Netscape 4.x which caused all windows to crash should one window fail to resolve a host name?
Paul
-
Chris Lightfoot -
Matthew M. Austin -
Paul Warren -
Siri Dhyan Singh