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
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.
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
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 :-(
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
-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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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:
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
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
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
31 matches
Mail list logo
