RE: The availability of socketbits.h?
Alex wrote: info gcc Move down the screen using the arrow key to the line * Invoking GCC:: and press return. The problem is: I can't find the line * Invoking GCC:: after moving the curson down the info gcc screen with the arrow key. :( Sorry for my newbieness. Move down the screen using the arrow key to the line * C Dialect Options:: and press return. Move down the screen with arrow key or Page Down and there it is. Typing h at any point gives you help, but that's very long winded. Typing ? shows key bindings in a split window. Finish with this window by typing ^X0 (control-X then a 0 (zero)). There's also an emacs mode. I don't know if there is a proper X interface of any kind. Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The availability of socketbits.h?
Xu Qiang wrote: Thanks for finding the info I need. But I really don't know how you find it. I have done info gcc, and pressed 's' button in my keyboard to search -std or -fstd, but got nothing. :( info gcc Move down the screen using the arrow key to the line * Invoking GCC:: and press return. Move down the screen using the arrow key to the line * C Dialect Options:: and press return. Move down the screen with arrow key or Page Down and there it is. Typing h at any point gives you help, but that's very long winded. Typing ? shows key bindings in a split window. Finish with this window by typing ^X0 (control-X then a 0 (zero)). There's also an emacs mode. I don't know if there is a proper X interface of any kind. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The availability of socketbits.h?
Xu Qiang wrote: Giorgos Keramidas wrote: The manpage of gcc is severely out of date. The GNU folks prefer Texinfo for their documentation since a long time ago. Just ignore the manpage of gcc(1). IMHO, it provides absolutely no useful information anymore :-( So, would you point me to the place of GCC usage of the option -std? Even google failed to find it. :( info gcc then down to invoking, command line and C dialect options. Whether it really is up-to-date and accurate, I cannot say. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Alex Zbyslaw wrote: Xu Qiang wrote: Giorgos Keramidas wrote: The manpage of gcc is severely out of date. The GNU folks prefer Texinfo for their documentation since a long time ago. Just ignore the manpage of gcc(1). IMHO, it provides absolutely no useful information anymore :-( So, would you point me to the place of GCC usage of the option -std? Even google failed to find it. :( info gcc then down to invoking, command line and C dialect options. Whether it really is up-to-date and accurate, I cannot say. --Alex Still didn't find it in info gcc, :( Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The availability of socketbits.h?
On 2005-05-19 13:13, Xu Qiang [EMAIL PROTECTED] wrote: Giorgos Keramidas wrote: The manpage of gcc is severely out of date. The GNU folks prefer Texinfo for their documentation since a long time ago. Just ignore the manpage of gcc(1). IMHO, it provides absolutely no useful information anymore :-( So, would you point me to the place of GCC usage of the option -std? Even google failed to find it. :( % info '(gcc)' Then hit 's' and search for '-std'. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Xu Qiang Sent: Tuesday, May 17, 2005 9:58 PM To: Dan Nelson; Xu Qiang Cc: Giorgos Keramidas; freebsd-questions@freebsd.org Subject: RE: The availability of socketbits.h? Dan Nelson wrote: The rest of the code in command.c makes use of the command_count value and assumes that all the array elements are fully populated. The qsort routime tried to compare a NULL comm_name value and seg faulted. His fix would have worked if the rest of the program used the same code loop as the one at command.c:1149, but it doesn't. Yeah, you hit the point again! Just found the variable noofcomms (= COUNTOF(command_list)) is used in the function qsort() - qsort((command_list),noofcomms,sizeof command_list[0],command_cmp); - No wonder trailing NULL element at the end of the array command_list[] is used in qsort(), and the segmentation fault. Since the number of actual non-NULL elements in the array is one less than the array's size, I changed the calculation of noofcomms as: - noofcomms = COUNTOF(command_list) - 1; - Now the program can work properly. :) The author may not have tested it on many systems, and since the source is so old (relatively speaking), standards have changed. It's no longer acceptable to provide your own prototypes for system functions, for example (which was the cause of your first few compile errors). I am very lucky to have you and Giorgos around to help me in compiling this software. Thank you two so much for your help and patience! with my best wishes, Xu Qiang Would you post a diff of the files you had to change to the list once you get it running? Thanks, Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Ted Mittelstaedt wrote: Would you post a diff of the files you had to change to the list once you get it running? If you follow this thread, it would be quite easy. Anyway, it is my pleasure to do a summary here. But I don't know how to put the diff result into a more readable format (like the old line is prefixed with a -, and the newline is prefixed with a +) than this: gso_dev_2# diff configure.org configure 5234,5235c5234,5235 GGO_SOME_WARNINGS='-Wall -W -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wp,-lang-c89' GGO_ALL_WARNINGS='-Wall -W -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wp,-lang-c89' --- GGO_SOME_WARNINGS='-Wall -W -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wp,-std=c89' GGO_ALL_WARNINGS='-Wall -W -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wp,-std=c89' It is quite unreadable. Actually, all I have done to this file is: sed -i -e s/-lang-c89/-std=c89/g configure If you can tell me how to do it in a -, + format, I will post a complete revision to the list. thanks, Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The availability of socketbits.h?
On 2005-05-18 11:27, Xu Qiang [EMAIL PROTECTED] wrote:
Dan Nelson wrote:
That for loop should really read:
for(i=0; icommand_count; i++) {
, since command_count should already be set to COUNTOF(command_list)
by a previous call to command_init().
Thank you, Dan. Your fix works!
Still, I wonder why the fix of Giorgos doesn't work, because it seems
quite right to me, too.
If you refer to the addition of a zero-filled entry at the end of the
array, it's not a fix. Just a description of what the buggy loop seems
to expect. The rest of the program works differently, so it definitely
won't work as a fix.
(Btw, I can't understand why this software has so many bugs to be
fixed before it can be compiled and run successfully. The developers
don't check their product before shipping out?
Obviously, no. They should be hit hard on the head with a copy of
Extreme Programming Explained :P
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The availability of socketbits.h?
On 2005-05-18 13:54, Xu Qiang [EMAIL PROTECTED] wrote: Ted Mittelstaedt wrote: Would you post a diff of the files you had to change to the list once you get it running? If you follow this thread, it would be quite easy. Anyway, it is my pleasure to do a summary here. But I don't know how to put the diff result into a more readable format (like the old line is prefixed with a -, and the newline is prefixed with a +) than this: That should be easy. You'll need two directory hierarchies: * One with the unchanged, vendor version of the code, i.e. an extracted copy of the tarballs you got from sourceforge. * One with the fixed version that builds and runs fine on your system. Assuming that you have the tarballs of mlrate-1.1.0 and nngs-1.1.14 that you got from sourceforge under /tmp/nngs/vendor/mlrate-1.1.0 and /tmp/nngs/vendor/nngs-1.1.14 respectively, you can copy these directories recursively to /tmp/nngs/local: # mkdir -p /tmp/nngs/local # cd /tmp/nngs/vendor # cp -Rp mlrate-1.10 nngs-1.1.14 /tmp/nngs/local Then you can make all the changes you need to /tmp/nngs/local and see all the changes of mlrate or nngs in one patchfile with: # cd /tmp/nngs # diff -ruN vendor/mlrate* local/mlrate* /tmp/nngs/mlrate.patch # less /tmp/nngs/mlrate.patch # cd /tmp/nngs # diff -ruN vendor/nngs* local/nngs* /tmp/nngs/nngs.patch # less /tmp/nngs/nngs.patch If you can tell me how to do it in a -, + format, I will post a complete revision to the list. See above :-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Giorgos Keramidas wrote: If you refer to the addition of a zero-filled entry at the end of the array, it's not a fix. Just a description of what the buggy loop seems to expect. The rest of the program works differently, so it definitely won't work as a fix. Even it is not a fix, your analysis helped me a lot in solving this problem. Thank you! Obviously, no. They should be hit hard on the head with a copy of Extreme Programming Explained :P Haha, good idea! Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Giorgos Keramidas wrote: That should be easy. You'll need two directory hierarchies: * One with the unchanged, vendor version of the code, i.e. an extracted copy of the tarballs you got from sourceforge. * One with the fixed version that builds and runs fine on your system. Assuming that you have the tarballs of mlrate-1.1.0 and nngs-1.1.14 that you got from sourceforge under /tmp/nngs/vendor/mlrate-1.1.0 and /tmp/nngs/vendor/nngs-1.1.14 respectively, you can copy these directories recursively to /tmp/nngs/local: # mkdir -p /tmp/nngs/local # cd /tmp/nngs/vendor # cp -Rp mlrate-1.10 nngs-1.1.14 /tmp/nngs/local Then you can make all the changes you need to /tmp/nngs/local and see all the changes of mlrate or nngs in one patchfile with: # cd /tmp/nngs # diff -ruN vendor/mlrate* local/mlrate* /tmp/nngs/mlrate.patch # less /tmp/nngs/mlrate.patch # cd /tmp/nngs # diff -ruN vendor/nngs* local/nngs* /tmp/nngs/nngs.patch # less /tmp/nngs/nngs.patch Thanks for the direction. I will try to do a summary of changes needed into a number of .patch files. Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Ted Mittelstaedt wrote: Would you post a diff of the files you had to change to the list once you get it running? With the help of Giorgos, I finally got all the diff into separate patch files. Explanatory notes: 1. I am using mlrate-1.1.0.tar.gz and nngs-1.1.14.tar.gz (coz it is more stable and reliable than 1.1.16 version), and only nngs-1.1.14.tar.gz need to be patched. 2. configure.patch must be applied in order to compile nngs src in FreeBSD 5.3 (for i386) with gcc 3.4.2; the patch is hinted by this bug reported in sourceforge: http://sourceforge.net/tracker/index.php?func=detailaid=1201565group_id=59572atid=491424 For your convenience, the gist is listed here: --- -lang-c89 deprecated quote from man gcc (3.3.5-20050130) Note: Previous versions of cpp accepted a -lang option which selected both the language and the standards conformance level. This option has been removed, because it conflicts with the -l option. just use -std=c89 (not sure but seem to works) --- P.S.: Although this can work, I can't find the option -std in man gcc, quite strange. Any hints? 3. Up to now, the compilation can be done successfully with GNU make, but if the following patch(es) is/are not applied, the compiled binary (nngssrv) will throw a run-time error and dump core. The patches are credited to Dan Nelson and Giorgos Keramidas. Either one set of the patches is enough to avoid the run-time error. Which one to choose is up to your own. i) The patch of Dan Nelson involves only one file - command.c, and the patch file is command.c.patch.DanNelson ii) The patch of Giorgos involves two files - command.c and command_list.h, the patch files are command.c.patch.GiorgosKeramidas and command_list.h.patch.GiorgosKeramidas If you meet any other problem in the process of setting up the server, pls let us know. P.S.: After using Giorgos' method to create the diff patches, I don't know how to apply the patches back to the original file(s). Can Giorgos help me once more? (Actually, I am quite a newbie in FreeBSD world.) 4. Final word: when configure nngs src, it is best to enable adminlevels options, it is done by: ./configure --prefix=your_install_dir --enable-adminlevels Hope this open-source software can be integrated into ports system of FreeBSD. Thank you, all. Regards, Xu Qiang command.c.patch.DanNelson Description: Binary data command.c.patch.GiorgosKeramidas Description: Binary data command_list.h.patch.GiorgosKeramidas Description: Binary data configure.patch Description: Binary data ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The availability of socketbits.h?
On 2005-05-18 18:31, Xu Qiang [EMAIL PROTECTED] wrote: Ted Mittelstaedt wrote: Would you post a diff of the files you had to change to the list once you get it running? With the help of Giorgos, I finally got all the diff into separate patch files. One patch file for the entire source tree of each package would be even better, but anyway... P.S.: Although this can work, I can't find the option -std in man gcc, quite strange. Any hints? The manpage of gcc is severely out of date. The GNU folks prefer Texinfo for their documentation since a long time ago. Just ignore the manpage of gcc(1). IMHO, it provides absolutely no useful information anymore :-( 3. Up to now, the compilation can be done successfully with GNU make, but if the following patch(es) is/are not applied, the compiled binary (nngssrv) will throw a run-time error and dump core. The patches are credited to Dan Nelson and Giorgos Keramidas. Either one set of the patches is enough to avoid the run-time error. Which one to choose is up to your own. My patch is incorrect. Use Dan's changes :-) P.S.: After using Giorgos' method to create the diff patches, I don't know how to apply the patches back to the original file(s). Can Giorgos help me once more? (Actually, I am quite a newbie in FreeBSD world.) Using patch(1). The diffs you have posted refer to a single file each. The correct method to use these diffs would be: 1. Extract the package tarballs, as downloaded from sourceforge. 2. Change into the directory that contains the file you'll patch (see the first lines of the patch for the filename). 3. Run patch(1) on the patchfile (the patchfile doesn't need to be in the current directory). An example could be: # cd /tmp/nngs/directory/of/file/ # patch -p0 /tmp/dan_nelson.diff Hope this open-source software can be integrated into ports system of FreeBSD. I honestly hope it is *NOT*. It's so awfully written, my eyes hurt *AND* it is unmaintained at SourceForge since late 2002. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Giorgos Keramidas wrote: One patch file for the entire source tree of each package would be even better, but anyway... Yes, but to this software, there are two kind of patches (of you, and Dan Nelson, respectively) that both works independently, so... :) The manpage of gcc is severely out of date. The GNU folks prefer Texinfo for their documentation since a long time ago. Just ignore the manpage of gcc(1). IMHO, it provides absolutely no useful information anymore :-( So, would you point me to the place of GCC usage of the option -std? Even google failed to find it. :( My patch is incorrect. Use Dan's changes :-) Dan's sure is correct. But your fix also works well, after I changed the command.c file. It would not work if we only patch the command_list.h hearder. An example could be: # cd /tmp/nngs/directory/of/file/ # patch -p0 /tmp/dan_nelson.diff Thanks for this detailed explanation and example, hoho, the example is better for such a lazy bone as I. :) A side note: After the server is running, I used Jago (http://www.rene-grothmann.de/jago/) as a client tool to connect to the server. The experiment shows that the server-client interaction works fine. Strongly recommend this go client software by Rene Grothmann, which is also an open-source software (But not GNU). Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Xu Qiang wrote: cc1: error: unrecognized command line option -lang-c89 gmake[2]: *** [command.o] Error 1 gmake[2]: Leaving directory `/usr/games/nngs_sourceforge/nngs-1.1.16/nrat' Just found out this: http://sourceforge.net/tracker/index.php?func=detailaid=1201565group_id=59572atid=491424: -lang-c89 deprecated quote from man gcc (3.3.5-20050130) Note: Previous versions of cpp accepted a -lang option which selected both the language and the standards conformance level. This option has been removed, because it conflicts with the -l option. just use -std=c89 (not sure but seem to works) Then I did the modification in the file ./configure, and it can go on. But another error appears: In file included from comproc.c:44: ../missing.h:30: error: conflicting types for 'ftruncate' /usr/include/stdio.h:367: error: previous declaration of 'ftruncate' was here ../missing.h:30: error: conflicting types for 'ftruncate' It is strange that while 1.1.16 version has this problem, 1.1.14 doesn't. Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The availability of socketbits.h?
In the last episode (May 17), Xu Qiang said: Great that another pal has compiled this stuff. :) No, I'm just a good troubleshooter :) In the last episode (May 17), Xu Qiang said: But another error appears: In file included from comproc.c:44: ../missing.h:30: error: conflicting types for 'ftruncate' /usr/include/stdio.h:367: error: previous declaration of 'ftruncate' was here ../missing.h:30: error: conflicting types for 'ftruncate' It is strange that while 1.1.16 version has this problem, 1.1.14 doesn't. It looks like missing.h was added in 1.1.15, but the author didn't run all the necessary autoconf commands afterwards. Try running autoheader253 (you will see that a HAVE_FTRUNCATE placeholder gets added to config.h.in), and rerun configure and make. It looks like there have been some autoconf changes make in CVS after 1.1.16 was released. You might want to check out the current source to see if some of these issues have been fixed already. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Dan Nelson wrote: It looks like missing.h was added in 1.1.15, but the author didn't run all the necessary autoconf commands afterwards. Try running autoheader253 (you will see that a HAVE_FTRUNCATE placeholder gets added to config.h.in), and rerun configure and make. It looks like there have been some autoconf changes make in CVS after 1.1.16 was released. You might want to check out the current source to see if some of these issues have been fixed already. Thanks for your suggestions. Yes, this error is overcome after running autoheader. But now another error of the same type appears: - mink.c:22: error: conflicting types for 'random' /usr/include/stdlib.h:200: error: previous declaration of 'random' was here mink.c:22: error: conflicting types for 'random' - This file is in nngs-1.1.16/src directory, and when I run autoheader in this directory: - autoheader: `configure.ac' or `configure.in' is required - What shall I do now? Thanks a lot, Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Xu Qiang wrote: Thanks for your suggestions. Yes, this error is overcome after running autoheader. But now another error of the same type appears: - mink.c:22: error: conflicting types for 'random' /usr/include/stdlib.h:200: error: previous declaration of 'random' was here mink.c:22: error: conflicting types for 'random' - This file is in nngs-1.1.16/src directory, and when I run autoheader in this directory: - autoheader: `configure.ac' or `configure.in' is required - Btw, I just found there is a line #undef HAVE_RANDOM in config.h.in, so is it due to the src file (mink.c) is not in the same directory as config.h.in? (It is one level below: config.h.in is in nngs-1.1.16, while mink.c is in nngs-1.1.16/src) Strange, Looking forward to your help, Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The availability of socketbits.h?
In the last episode (May 17), Xu Qiang said: Dan Nelson wrote: It looks like missing.h was added in 1.1.15, but the author didn't run all the necessary autoconf commands afterwards. Try running autoheader253 (you will see that a HAVE_FTRUNCATE placeholder gets added to config.h.in), and rerun configure and make. It looks like there have been some autoconf changes make in CVS after 1.1.16 was released. You might want to check out the current source to see if some of these issues have been fixed already. Thanks for your suggestions. Yes, this error is overcome after running autoheader. But now another error of the same type appears: - mink.c:22: error: conflicting types for 'random' /usr/include/stdlib.h:200: error: previous declaration of 'random' was here mink.c:22: error: conflicting types for 'random' - That's because after including the header that provides a declaration for random (stdlib.h), the author decided to include another of his own for some reason, but he used the wrong return type so gcc complained. Just remove like 22 of mink.c. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The availability of socketbits.h?
On 2005-05-17 15:59, Xu Qiang [EMAIL PROTECTED] wrote: Xu Qiang wrote: Thanks for your suggestions. Yes, this error is overcome after running autoheader. But now another error of the same type appears: - mink.c:22: error: conflicting types for 'random' /usr/include/stdlib.h:200: error: previous declaration of 'random' was here mink.c:22: error: conflicting types for 'random' - This file is in nngs-1.1.16/src directory, and when I run autoheader in this directory: - autoheader: `configure.ac' or `configure.in' is required - Btw, I just found there is a line #undef HAVE_RANDOM in config.h.in, so is it due to the src file (mink.c) is not in the same directory as config.h.in? (It is one level below: config.h.in is in nngs-1.1.16, while mink.c is in nngs-1.1.16/src) The autoheader/autoconf commands have to be run in the directory that contains configure.in or configure.ac (usually the top level directory of the entire distribution). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Dan Nelson wrote: That's because after including the header that provides a declaration for random (stdlib.h), the author decided to include another of his own for some reason, but he used the wrong return type so gcc complained. Just remove like 22 of mink.c. Thank you again. It can roll forward when the declaration of the random function function is removed. It seems 1.1.16 version is full of bugs, like stated above. The 1.1.14 version is much better in compiling. However, both versions give me an error when I run the compiled application after gmake, gmake install. I go to bin directory and type ./nngssrv, it told me: Bus error (core dumped) GDB trace is here: --- gso_dev_2# gdb nngssrv nngssrv.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. 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. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Core was generated by `nngssrv'. Program terminated with signal 10, Bus error. Reading symbols from /lib/libcrypt.so.2...done. Loaded symbols for /lib/libcrypt.so.2 Reading symbols from /lib/libm.so.3...done. Loaded symbols for /lib/libm.so.3 Reading symbols from /lib/libc.so.5...done. Loaded symbols for /lib/libc.so.5 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x2818bbc5 in __vfprintf () from /lib/libc.so.5 (gdb) bt #0 0x2818bbc5 in __vfprintf () from /lib/libc.so.5 #1 0x2818a513 in vfprintf () from /lib/libc.so.5 #2 0x28177352 in fprintf () from /lib/libc.so.5 #3 0x0805f98c in commands_init () at command.c:1149 #4 0x0805aeab in main (argc=1116382465, argv=0x807e702) at nngsmain.c:162 --- What is a Bus error? Any hints to overcome this last barrier? thanks a lot, Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The availability of socketbits.h?
On 2005-05-18 10:02, Xu Qiang [EMAIL PROTECTED] wrote:
Thank you again. It can roll forward when the declaration of the
random function function is removed. It seems 1.1.16 version is full
of bugs, like stated above. The 1.1.14 version is much better in
compiling.
However, both versions give me an error when I run the compiled
application after gmake, gmake install. I go to bin directory and type
./nngssrv, it told me: Bus error (core dumped)
GDB trace is here:
---
gso_dev_2# gdb nngssrv nngssrv.core
(gdb) bt
[...]
#0 0x2818bbc5 in __vfprintf () from /lib/libc.so.5
#1 0x2818a513 in vfprintf () from /lib/libc.so.5
#2 0x28177352 in fprintf () from /lib/libc.so.5
#3 0x0805f98c in commands_init () at command.c:1149
#4 0x0805aeab in main (argc=1116382465, argv=0x807e702) at nngsmain.c:162
---
What is a Bus error?
A bug in the program. The relevant code seems to be this part of
nngs-1.1.14/nrat/command.c:
1131 void commands_init()
1132 {
1133 FILE *fp, *afp;
1134 int i = 0;
1135
1136 fp = xyfopen(FILENAME_CMDS, w);
1137 if (!fp) {
1138 return;
1139 }
1140 afp = xyfopen(FILENAME_ACMDS, w);
1141 if (!afp) {
1142 fclose(fp);
1143 return;
1144 }
1145 for (i = 0; command_list[i].comm_name; i++) {
1146 if (command_list[i].adminLevel = ADMIN_ADMIN) {
1147 fprintf(afp, %s\n, command_list[i].comm_name);
1148 } else {
1149 fprintf(fp, %s\n, command_list[i].comm_name);
1150 }
1151 }
1152 fclose(fp);
1153 fclose(afp);
1154 }
If we put for a while the horrible style aside, the bug seems to be that
the for loop doesn't properly check the bounds of the command_list[]
array. This would probably be ok if the command_list array was declared
to have a trailing element set to an all zeroes value:
struct command_type command_list[] = {
{accept,n,com_accept, ADMIN_USER },
{actitle, dS, com_actitle,ADMIN_ADMIN },
{0, 0, 0, 0 },
};
but it's not (look in nngs-1.1.14/nrat/command_list.h):
/* NameOptions Functions Security */
struct command_type command_list[] = {
{accept,n,com_accept, ADMIN_USER },
{actitle, dS, com_actitle,ADMIN_ADMIN },
[...]
/* by Syncanph */
{shownote, , com_shownote, ADMIN_USER },
};
and this is *EXACTLY* where this particular bug lies.
Any hints to overcome this last barrier?
Yes. Don't run software that is full of bugs, unless you're keen on
fixing those bugs :-(
The nngs.sourceforge.net web page shows *no* release of nngs after 2002.
The history of that project shows that the ones developing it would
release very often; some times twice within the same week. The fact
that there has been absolutely no release for more than 3 years means
that nngs is, for all purposes, thoroughly dead.
- Giorgos
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The availability of socketbits.h?
In the last episode (May 18), Xu Qiang said:
Dan Nelson wrote:
That's because after including the header that provides a declaration
for random (stdlib.h), the author decided to include another of his
own for some reason, but he used the wrong return type so gcc
complained. Just remove like 22 of mink.c.
Thank you again. It can roll forward when the declaration of the random
function function is removed. It seems 1.1.16 version is full of bugs, like
stated above. The 1.1.14 version is much better in compiling.
However, both versions give me an error when I run the compiled application
after gmake, gmake install. I go to bin directory and type ./nngssrv, it
told me:
Bus error (core dumped)
GDB trace is here:
(gdb) bt
#0 0x2818bbc5 in __vfprintf () from /lib/libc.so.5
#1 0x2818a513 in vfprintf () from /lib/libc.so.5
#2 0x28177352 in fprintf () from /lib/libc.so.5
#3 0x0805f98c in commands_init () at command.c:1149
#4 0x0805aeab in main (argc=1116382465, argv=0x807e702) at nngsmain.c:162
---
What is a Bus error?
It's usually caused by an incorrect pointer, or a stack overflow, where
the program tries to read a memory address not available to it. In
fact, I can see the problem right away. command_list is a
statically-initilized array (defined at command_list.h:55). Note that
there is no special end-of-list value at the end of the array. The
loop at command.c:1149 loops until command_list[i].comm_name is NULL,
but since there's no explicit NULL entry at the end, the loop falls off
the end of the array, where it eventually hits an unmapped page of
memory and gets a bus error.
That for loop should really read:
for(i=0; icommand_count; i++) {
, since command_count should already be set to COUNTOF(command_list) by
a previous call to command_init().
--
Dan Nelson
[EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Giorgos Keramidas wrote:
A bug in the program. The relevant code seems to be this part of
nngs-1.1.14/nrat/command.c:
1131 void commands_init()
1132 {
1133 FILE *fp, *afp;
1134 int i = 0;
1135
1136 fp = xyfopen(FILENAME_CMDS, w);
1137 if (!fp) {
1138 return;
1139 }
1140 afp = xyfopen(FILENAME_ACMDS, w);
1141 if (!afp) {
1142 fclose(fp);
1143 return;
1144 }
1145 for (i = 0; command_list[i].comm_name; i++) {
1146 if (command_list[i].adminLevel = ADMIN_ADMIN) {
1147 fprintf(afp, %s\n, command_list[i].comm_name);
1148 } else {
1149 fprintf(fp, %s\n, command_list[i].comm_name);
1150 }
1151 }
1152 fclose(fp);
1153 fclose(afp);
1154 }
If we put for a while the horrible style aside, the bug seems to be
that the for loop doesn't properly check the bounds of the
command_list[] array. This would probably be ok if the command_list
array was declared to have a trailing element set to an all zeroes
value:
struct command_type command_list[] = {
{accept,n,com_accept, ADMIN_USER },
{actitle, dS, com_actitle,ADMIN_ADMIN },
{0, 0, 0, 0 },
};
but it's not (look in nngs-1.1.14/nrat/command_list.h):
/* NameOptions Functions Security */
struct command_type command_list[] = {
{accept,n,com_accept, ADMIN_USER },
{actitle, dS, com_actitle,ADMIN_ADMIN },
[...]
/* by Syncanph */
{shownote, , com_shownote, ADMIN_USER },
};
and this is *EXACTLY* where this particular bug lies.
Thank you, Giorgos. You hit the cause I didn't see.
But after compile, there is a new segmentation fault, here is the GDB trace:
gso_dev_2# gdb nngssrv nngssrv.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
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.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...
Core was generated by `nngssrv'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.2...done.
Loaded symbols for /lib/libcrypt.so.2
Reading symbols from /lib/libm.so.3...done.
Loaded symbols for /lib/libm.so.3
Reading symbols from /lib/libc.so.5...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x281803d2 in strcmp () from /lib/libc.so.5
(gdb) bt
#0 0x281803d2 in strcmp () from /lib/libc.so.5
#1 0x2817f125 in qsort () from /lib/libc.so.5
#2 0x0805d740 in command_init () at command.c:212
#3 0x0805ae95 in main (argc=1116386171, argv=0xbfbfe958) at nngsmain.c:158
It seems still related to the array of command_list.
Any further suggestions?
thanks,
Regards,
Xu Qiang
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Dan Nelson wrote:
It's usually caused by an incorrect pointer, or a stack overflow,
where the program tries to read a memory address not available to it.
In fact, I can see the problem right away. command_list is a
statically-initilized array (defined at command_list.h:55). Note that
there is no special end-of-list value at the end of the array. The
loop at command.c:1149 loops until command_list[i].comm_name is NULL,
but since there's no explicit NULL entry at the end, the loop falls
off the end of the array, where it eventually hits an unmapped page of
memory and gets a bus error.
That for loop should really read:
for(i=0; icommand_count; i++) {
, since command_count should already be set to COUNTOF(command_list)
by a previous call to command_init().
Thank you, Dan. Your fix works!
Still, I wonder why the fix of Giorgos doesn't work, because it seems quite
right to me, too.
(Btw, I can't understand why this software has so many bugs to be fixed before
it can be compiled and run successfully. The developers don't check their
product before shipping out? I have compiled and installed quite a number of
GNU softwares, never saw such a buggy one. Yet, I am a go game lover, and want
to set up a local NNGS server. And this is the only available open source go
server software in the world. Alas!)
Regards,
Xu Qiang
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The availability of socketbits.h?
In the last episode (May 18), Xu Qiang said:
Dan Nelson wrote:
That for loop should really read:
for(i=0; icommand_count; i++) {
, since command_count should already be set to
COUNTOF(command_list) by a previous call to command_init().
Thank you, Dan. Your fix works!
Still, I wonder why the fix of Giorgos doesn't work, because it seems
quite right to me, too.
The rest of the code in command.c makes use of the command_count value
and assumes that all the array elements are fully populated. The qsort
routime tried to compare a NULL comm_name value and seg faulted. His
fix would have worked if the rest of the program used the same code
loop as the one at command.c:1149, but it doesn't.
(Btw, I can't understand why this software has so many bugs to be
fixed before it can be compiled and run successfully. The developers
don't check their product before shipping out? I have compiled and
installed quite a number of GNU softwares, never saw such a buggy
one. Yet, I am a go game lover, and want to set up a local NNGS
server. And this is the only available open source go server software
in the world. Alas!)
The author may not have tested it on many systems, and since the source
is so old (relatively speaking), standards have changed. It's no
longer acceptable to provide your own prototypes for system functions,
for example (which was the cause of your first few compile errors).
--
Dan Nelson
[EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Dan Nelson wrote: The rest of the code in command.c makes use of the command_count value and assumes that all the array elements are fully populated. The qsort routime tried to compare a NULL comm_name value and seg faulted. His fix would have worked if the rest of the program used the same code loop as the one at command.c:1149, but it doesn't. Yeah, you hit the point again! Just found the variable noofcomms (= COUNTOF(command_list)) is used in the function qsort() - qsort((command_list),noofcomms,sizeof command_list[0],command_cmp); - No wonder trailing NULL element at the end of the array command_list[] is used in qsort(), and the segmentation fault. Since the number of actual non-NULL elements in the array is one less than the array's size, I changed the calculation of noofcomms as: - noofcomms = COUNTOF(command_list) - 1; - Now the program can work properly. :) The author may not have tested it on many systems, and since the source is so old (relatively speaking), standards have changed. It's no longer acceptable to provide your own prototypes for system functions, for example (which was the cause of your first few compile errors). I am very lucky to have you and Giorgos around to help me in compiling this software. Thank you two so much for your help and patience! with my best wishes, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The availability of socketbits.h?
In the last episode (May 17), Xu Qiang said: I am compiling NNGS (No Name Go Server) code in my FreeBSD 5.3 machine. Yet, I came across the following error: - gcc -traditional-cpp -Wall -DFREEBSD -c network.c network.c:23: socketbits.h: No such file or directory gmake: *** [network.o] Error 1 - I have searched for this file in my system, but can't find it. To have it present, which software must I install? That is a Linux internal header that programs should not be including directly. What version of nngs are you trying to compile? I downloaded nngs-1.1.16 from http://sourceforge.net/projects/nngs/ and line 23 of src/network.c is a blank line: 20 #ifdef HAVE_CONFIG_H 21 #include config.h 22 #endif 23 24 #include stdio.h 25 #include stdlib.h 26 #include assert.h -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Dan Nelson wrote: That is a Linux internal header that programs should not be including directly. What version of nngs are you trying to compile? I downloaded nngs-1.1.16 from http://sourceforge.net/projects/nngs/ and line 23 of src/network.c is a blank line: 20 #ifdef HAVE_CONFIG_H 21 #include config.h 22 #endif 23 24 #include stdio.h 25 #include stdlib.h 26 #include assert.h Great that another pal has compiled this stuff. :) Hmmm, I was compiling the original NNGS source code from http://nngs.cosmic.org/src/. Just found this new sourceforge page related to NNGS. Let me try this out. thank you and be prepared for my foolish questions, :P Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Dan Nelson wrote: That is a Linux internal header that programs should not be including directly. What version of nngs are you trying to compile? I downloaded nngs-1.1.16 from http://sourceforge.net/projects/nngs/ and line 23 of src/network.c is a blank line: 20 #ifdef HAVE_CONFIG_H 21 #include config.h 22 #endif 23 24 #include stdio.h 25 #include stdlib.h 26 #include assert.h By the way, is there a similar sourceforge page for mlrate? I understand that it is necesary for nngs to compile. Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: The availability of socketbits.h?
Dan Nelson wrote: That is a Linux internal header that programs should not be including directly. What version of nngs are you trying to compile? I downloaded nngs-1.1.16 from http://sourceforge.net/projects/nngs/ and line 23 of src/network.c is a blank line: 20 #ifdef HAVE_CONFIG_H 21 #include config.h 22 #endif 23 24 #include stdio.h 25 #include stdlib.h 26 #include assert.h I downloaded mlrate-1.1.0.tar.gz and nngs-1.1.16.tar.gz, and did as the following: 1 tar xvzf mlrate-1.1.0.tar.gz 2 cd mlrate-1.1.0 3 ./configure 4 gmake (Should I do gmake install thereafter?) 5 tar xvzf nngs-1.1.16.tar.gz 6 cd nngs-1.1.16 7 ln -s ../mlrate-1.1.0 mlrate (Why this step?) 8 gmake But I met an error: gso_dev_2# gmake gmake all-recursive gmake[1]: Entering directory `/usr/games/nngs_sourceforge/nngs-1.1.16' Making all in nrat gmake[2]: Entering directory `/usr/games/nngs_sourceforge/nngs-1.1.16/nrat' source='command.c' object='command.o' libtool=no \ depfile='.deps/command.Po' tmpdepfile='.deps/command.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I../mlrate/src-g -O2 -Wall -W -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wp,-lang-c89 -c `test -f 'command.c' || echo './'`command.c cc1: error: unrecognized command line option -lang-c89 gmake[2]: *** [command.o] Error 1 gmake[2]: Leaving directory `/usr/games/nngs_sourceforge/nngs-1.1.16/nrat' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/games/nngs_sourceforge/nngs-1.1.16' gmake: *** [all] Error 2 Any help? thanks, Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
