18 Sep, 2010, Flonne Ninetails wrote in the 1st comment:
Votes: 0
GodWars Codebases give me this:

comm.c:57:48: error: execinfo.h: No such file or directory
make: *** [o/comm.o] Error 1

How can I fix this?

I used the Full Install of CygWin.
18 Sep, 2010, Tyche wrote in the 2nd comment:
Votes: 0
The header defines backtrace functions for use with glibc It's not supported on non-glibc systems MacOS X 10.3, FreeBSD 6.0, NetBSD 3.0, OpenBSD 3.8, AIX 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 10, Cygwin, mingw, Interix 3.5, BeOS and HaikuOS. The backtrace() functions are used for debugging and I'd just comment out the functionality for Cygwin.
18 Sep, 2010, Flonne Ninetails wrote in the 3rd comment:
Votes: 0
I now have another error. Hand tight I'll post it…
18 Sep, 2010, Flonne Ninetails wrote in the 4th comment:
Votes: 0
/home/Dash/cotn25/src/comm.c:1253: undefined reference to `_gethostbyaddr_r'
collect2: ld returned 1 exit status
make: *** [dystopia] Error 1
18 Sep, 2010, Tyche wrote in the 5th comment:
Votes: 0
Yeah gethostbyaddr_r isn't supported yet across all platforms.
Somewhere in comm.c do something like the following… (this is a patch to Dystopia BTW. I have no idea what cotn25 looks like)

pthread_mutex_t lockhost = PTHREAD_MUTEX_INITIALIZER;

void lookup_address(DUMMY_ARG *darg)
{
struct hostent *from = 0;
struct hostent ent;
char buf[16384]; // enough ??
int err;

thread_count++;

#ifdef __CYGWIN__
pthread_mutex_lock(lockhost);
from = gethostbyaddr(darg->buf, sizeof(darg->buf), AF_INET );
#else
gethostbyaddr_r( darg->buf, sizeof(darg->buf), AF_INET, &ent, buf, 16384, &from, &err);
#endif

if (from && from->h_name)
{
free_string(darg->d->host);
darg->d->host = str_dup(from->h_name);
}
#ifdef __CYGWIN__
pthread_mutex_unlock(lockhost);
#endif

/*
* Brilliant system there Mr. Jobo
*/
darg->d->lookup_status++;

free_string(darg->buf);
darg->status = 0;

thread_count–;

pthread_exit(0);
}


You might have to add the library pthread to your Makefile if it doesn't have it already.
18 Sep, 2010, Flonne Ninetails wrote in the 6th comment:
Votes: 0
COTN is based on Dystopia. I'll try that.
18 Sep, 2010, Flonne Ninetails wrote in the 7th comment:
Votes: 0
Now it crashes with a segmentation fault when a player tries to connect. o.O;
18 Sep, 2010, Tyche wrote in the 8th comment:
Votes: 0
Flonne Ninetails said:
Now it crashes with a segmentation fault when a player tries to connect. o.O;


Try using gdb to debug it. Some tips for running gdb with muds follow:
http://www.iguanadons.net/Using-GDB-to-D...
http://sourcery.dyndns.org/wiki.cgi?Segm...
http://mushclient.com/gdb
18 Sep, 2010, Flonne Ninetails wrote in the 9th comment:
Votes: 0
Quote
Exception: STATUS_ACCESS_VIOLATION at eip=6110D758
eax=03B46420 ebx=00000000 ecx=00000000 edx=00000000 esi=03B46420 edi=03B46420
ebp=03B4639C esp=03B46390 program=C:\cygwin\home\Dash\cotn25\area\dystopia.exe, pid 6040, thread unknown (0x1080)
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
03B4639C 6110D758 (03B46420, 00000000, 03B463BC, 03B4CE64)
03B463BC 6110D59C (03B463E8, 00000000, 00000039, 00000000)
03B483EC 00506313 (10450E6C, 10450E6C, 00000000, 00000000)
03B4855C 00472794 (0000000B, 00000000, 00000000, 00000000)
03B4864C 610290F9 (000001A4, 0000EA60, 000000A4, 03B48740)
03B4875C 610C60ED (00000014, 03B48824, 0000001C, 00000000)
03B4884C 610288D9 (03B48938, 03B4FF70, 03B48954, 03B4890C)
03B48870 77425F79 (03B48938, 03B4FF70, 03B48954, 03B4890C)
03B48920 77425F4B (00B48938, 03B48954, 03B48938, 03B48954)
03B48D18 77425DD7 (00000014, 00000000, 00000000, 00000000)
03B4CD58 610C01A5 (11A6BBB8, 00000000, 00000000, 00000000)
03B4CD98 610E38C5 (10461078, 03B4CDD4, 610E3810, 10461078)
End of stack trace


That is what it comes up with.
18 Sep, 2010, Tyche wrote in the 10th comment:
Votes: 0
That's a stackdump trace. It's for use with command line debugging tools like addr2line.
I'd recommend you use gdb.

If you want gdb compatible core dumps to be produced for all cygwin processes rather than stackdumps, add the following to your cygwin.bat file
set CYGWIN=error_start:dumper

If you want gdb to automatically attach itself to any abending cygwin process add the following instead.
set CYGWIN=error_start:gdb
19 Sep, 2010, Flonne Ninetails wrote in the 11th comment:
Votes: 0
With the latter, it starts, but then doesn't let me do anything.
19 Sep, 2010, Flonne Ninetails wrote in the 12th comment:
Votes: 0
Here's all that shows in the GDB…

Quote
Dash@Dash-PC ~/cotn25/area
$ gdb -c dystopia.exe.core
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
[New process 1]
[New process 0]
[New process 0]
[New process 0]
#0 0x77425e74 in ?? ()
(gdb) quit
19 Sep, 2010, Tyche wrote in the 13th comment:
Votes: 0
Flonne Ninetails said:
With the latter, it starts, but then doesn't let me do anything.


?

Flonne Ninetails said:
Here's all that shows in the GDB…
$ gdb -c dystopia.exe.core


Did you compile with the debugging information "gcc -g"?

If so…
Perhaps symbol tables aren't loading. Try this:

$ gdb dystopia.exe -c dystopia.exe.core
19 Sep, 2010, Flonne Ninetails wrote in the 14th comment:
Votes: 0
Here's what it says.

Quote
#0 0x77425e74 in ntdll!LdrAccessResource ()
from C:\Windows\system32\ntdll.dll
19 Sep, 2010, Tyche wrote in the 15th comment:
Votes: 0
Your missing the stacktrace. Try running gdb interactively on the running mud like in the Nick Gammon article I referenced earlier.
0.0/15