If you go to the docs page of the website, the menu on the left breaks, because some of the links (like Downloads) are relative and assume one is in the top directory. -- -- Neil Stevens - neil@... 'A republic, if you can keep it.' -- Benjamin Franklin [Non-text portions of this message have been removed]
I have been trying to run tome 2.3.1 on a debian pure-amd64 system and had been running into problems that look to be the same as those reported at http://wiki.t-o-m-e.net/BugReport360 The symptoms are a spew of lua errors at various points (loading a save file for instance.) I managed to track down the problem to being caused by h-config.h not detecting that AMD64 is a 64 bit platform, as it was only checking for alpha. This results in various typedefs that are supposed to be 32 bits ending up as 64 bit values. The below patch against CVS h-config.h should fix this. It should also fix it for Intel's IA64 architecture, though I haven't tested that. Possibly the right thing might instead be to check for (sizeof(long) == 8) in order to cover any other future 64 bit platforms. I'm not sure if that has any portability implications though, so the below patch just adds in __x86_64__ to the known 64 bit platforms in the same way its done for alpha. Index: h-config.h =================================================================== RCS file: /var/cvs/tome/tome/src/h-config.h,v retrieving revision 1.7 diff -u -r1.7 h-config.h --- h-config.h 13 Apr 2005 17:40:03 -0000 1.7 +++ h-config.h 23 Jul 2005 19:59:49 -0000 <at> <at> -171,10 +171,11 <at> <at> /* * OPTION: Define "L64" if a "long" is 64-bits. See "h-types.h".(Continue reading)
On Saturday 23 July 2005 01:51 pm, Brian McErlean wrote: > Possibly the right thing might instead be to check for > (sizeof(long) == 8) in order to cover any other future 64 bit platforms. > I'm not sure if that has any portability implications though, so the > below patch just adds in __x86_64__ to the known 64 bit platforms in the > same way its done for alpha. Could you try the sizeof approach instead? I think that would be the far better approach, since the comment is probably accurate. thanks, -- -- Neil Stevens - neil@... 'A republic, if you can keep it.' -- Benjamin Franklin [Non-text portions of this message have been removed]
On Sun, 24 Jul 2005 08:26:46 -0700 Neil Stevens <neil@...> wrote: > On Saturday 23 July 2005 01:51 pm, Brian McErlean wrote: > > Possibly the right thing might instead be to check for > > (sizeof(long) == 8) in order to cover any other future 64 bit platforms. > > I'm not sure if that has any portability implications though, so the > > below patch just adds in __x86_64__ to the known 64 bit platforms in the > > same way its done for alpha. > > Could you try the sizeof approach instead? I think that would be the far > better approach, since the comment is probably accurate. I spoke too soon I think - you can't actually check for sizeof in the c preprocssor. One possibly better define to check for is listed in the gnu cpp info as: __LP64__, _LP64 These macros are defined, with value 1, if (and only if) the compilation is for a target where long int and pointer both use 64-bits and int uses 32-bit. However, these are listed in a section describing gcc extensions, so may not be available on all platforms. (Using either works here) Also, it looks like there are still some 64 bit-related problems even with the above change. eg. the skills ('G') page for a starting rohanknignt lists stealth as being 4294967288. I think this is just the display though - Stealth is still listed as "Bad" in the character listing ('C'), and after(Continue reading)
On Sunday 24 July 2005 09:39 am, Brian McErlean wrote:
> I spoke too soon I think - you can't actually check for sizeof in the c
> preprocssor.
Hmm. Well, since we already don't support cross-compiling (thanks to
tolua), we could write a little test program that the makefiles can use to
determine themselves whether to add the 64-bit define or not.
> Also, it looks like there are still some 64 bit-related problems even
> with the above change. eg. the skills ('G') page for a starting
> rohanknignt lists stealth as being 4294967288. I think this is just the
> display though - Stealth is still listed as "Bad" in the character
> listing ('C'), and after incrementing stealth till it is non-negative it
> is set to zero again. (I didn't see what could be causing this from a
> quick look, but I'll probably take another look later to see if I can
> find the cause.)
I'm sure you'll let us know whatever you find.
--
--
Neil Stevens - neil@...
'A republic, if you can keep it.' -- Benjamin Franklin
[Non-text portions of this message have been removed]
On Sun, 24 Jul 2005 09:59:14 -0700 Neil Stevens <neil@...> wrote: > On Sunday 24 July 2005 09:39 am, Brian McErlean wrote: > > Also, it looks like there are still some 64 bit-related problems even > > with the above change. eg. the skills ('G') page for a starting > > rohanknignt lists stealth as being 4294967288. I think this is just the > > display though - Stealth is still listed as "Bad" in the character > > listing ('C'), and after incrementing stealth till it is non-negative it > > is set to zero again. (I didn't see what could be causing this from a > > quick look, but I'll probably take another look later to see if I can > > find the cause.) > > I'm sure you'll let us know whatever you find. I've found what was causing this (should have read the gcc warnings which were flagging it) In print_skills in skills.c, the format code when printing skills specifies long width, but an int is passed: format("%02ld.%03ld [%01d.%03d]", s_info[i].value / SKILL_STEP, s_info[i].value % SKILL_STEP, s_info[i].mod / 1000, s_info[i].mod % 1000), Casting the parameters to long, or changing to a %d format specifier fixes this. eg. format("%02ld.%03ld [%01d.%03d]", (long) s_info[i].value / SKILL_STEP, (long) s_info[i].value % SKILL_STEP,(Continue reading)
On Sun, Jul 24, 2005 at 07:30:08PM +0100, Brian McErlean wrote:
>
> format("%02ld.%03ld [%01d.%03d]",
> s_info[i].value / SKILL_STEP, s_info[i].value % SKILL_STEP,
> s_info[i].mod / 1000, s_info[i].mod % 1000),
>
> Casting the parameters to long, or changing to a %d format specifier
> fixes this. eg.
>
> format("%02ld.%03ld [%01d.%03d]",
> (long) s_info[i].value / SKILL_STEP, (long) s_info[i].value % SKILL_STEP,
> s_info[i].mod / 1000, (long) s_info[i].mod % 1000),
Oy vey.
> Unfortunately, it
> looks like its a matter of ploughing through the warnings and replacing
> only for those cases.
> I could send you the compile log or take a stab at doing this, but
> I'm guessing its probably best to do it against the latest CVS,
> which I haven't got to compile.
If you get it working on AMD64, send us the diff, please. You seem to
be getting to the root of the problem already.
> (Can't find w_util.c, which I'm
> guessing is autogenerated. However, I'm not too familiar with the
> source or lua, so I'm not sure how to generate it.
> Are there docs / instructions for this anywhere?
(Continue reading)
On Sunday 24 July 2005 11:30 am, Brian McErlean wrote: > I've found what was causing this (should have read the gcc warnings > which were flagging it) ... > As a quick fix I tried just: > > sed -i -e 's/%ld/%d/g' -e 's/%lu/%u/g' *.c > > which fixes the problems, but raises more warnings as there are places > where %ld is legitimately being passed a long. Unfortunately, it > looks like its a matter of ploughing through the warnings and replacing > only for those cases. Do send us a patch with all those changes when you're done. > I could send you the compile log or take a stab at doing this, but > I'm guessing its probably best to do it against the latest CVS, > which I haven't got to compile. (Can't find w_util.c, which I'm > guessing is autogenerated. However, I'm not too familiar with the > source or lua, so I'm not sure how to generate it. > Are there docs / instructions for this anywhere? If there are issues in the w_ files, then making the fixes directly will NOT be enough to fix. w_*.c are being generated by tolua, so if tolua's generated code is wrong, tolua has to be fixed. -- -- Neil Stevens - neil@... 'A republic, if you can keep it.' -- Benjamin Franklin(Continue reading)
On Mon, 25 Jul 2005 06:53:27 -0700 Neil Stevens <neil@...> wrote: > Do send us a patch with all those changes when you're done. OK. I've attached a patch against tome2 CVS that should fix this. It now compiles without format warnings, and properly printed piety / stealth. (Also fixes a more serious case with sscanf that does cause corruption due to reading a long into an int buffer) [Non-text portions of this message have been removed]
> OK. I've attached a patch against tome2 CVS that should fix this.
Oops, that didn't seem to go through.
I've included the patch below:
Index: birth.c
===================================================================
RCS file: /var/cvs/tome/tome2/src/birth.c,v
retrieving revision 1.247
diff -u -r1.247 birth.c
--- birth.c 23 Sep 2004 17:38:05 -0000 1.247
+++ birth.c 25 Jul 2005 19:48:36 -0000
<at> <at> -2943,7 +2943,7 <at> <at>
birth_put_stats();
/* Dump round */
- put_str(format("%6ld", auto_round), 9, 73);
+ put_str(format("%6ld", (long) auto_round), 9, 73);
/* Make sure they see everything */
Term_fresh();
Index: bldg.c
===================================================================
RCS file: /var/cvs/tome/tome2/src/bldg.c,v
retrieving revision 1.72
diff -u -r1.72 bldg.c
--- bldg.c 8 Oct 2004 09:06:55 -0000 1.72
+++ bldg.c 25 Jul 2005 19:48:59 -0000
<at> <at> -441,7 +441,7 <at> <at>
(Continue reading)
RSS Feed3 | |
|---|---|
4 | |
16 | |
25 | |
27 | |
31 | |
31 | |
25 | |
14 | |
15 | |
24 | |
30 | |
28 | |
19 | |
24 | |
50 | |
30 | |
32 | |
35 | |
44 | |
39 | |
37 | |
24 | |
30 | |
28 | |
31 | |
33 | |
26 | |
26 | |
12 | |
9 | |
50 | |
51 | |
36 | |
63 | |
73 | |
71 | |
43 | |
47 | |
50 | |
60 | |
72 | |
80 | |
45 | |
13 | |
6 | |
4 | |
6 | |
19 | |
6 | |
18 | |
3 | |
4 | |
34 | |
14 | |
4 | |
12 | |
6 | |
5 | |
7 | |
5 | |
12 | |
29 | |
17 | |
10 | |
10 | |
6 | |
82 | |
35 | |
20 | |
7 | |
8 | |
1 | |
1 | |
1 | |
3 | |
23 | |
3 | |
4 | |
1 | |
38 | |
50 | |
94 | |
50 | |
17 | |
8 | |
6 | |
14 | |
35 | |
3 | |
5 | |
70 | |
10 | |
5 | |
5 | |
15 | |
15 | |
34 | |
9 |
