Compliation error Smaug 1.8a OpenSuse 10.2

Posted by Smee on Mon 23 Apr 2007 11:31 PM — 14 posts, 58,834 views.

Smee Mon 23 Apr 2007 11:31 PM #0

Hi,

Am trying to install smaug using gcc under OpenSuse 10.2 and get the following errors when attempting a make all


make smaug
make[1]: Entering directory `/home/smee/smaug1.8/src'
gcc -c  -O -g3 -Wall -Wuninitialized   -DREQUESTS -DSMAUG   -DREGEX -DUSE_IMC act_move.c
act_move.c:393:15: warning: trigraph ??> ignored, use -trigraphs to enable
act_move.c: In function 'generate_exit':
act_move.c:604: error: invalid lvalue in assignment
make[1]: *** [act_move.o] Error 1
make[1]: Leaving directory `/home/smee/smaug1.8/src'
make: *** [all] Error 2

Searched the forums and looks like it might be something to do with line 604 in act_move.c? Or am I just speculating?

Smee Mon 23 Apr 2007 11:40 PM #1

Actually fixed that part, I didn't look hard enough, answer is here:

http://www.gammon.com.au/forum/?id=7445

Got another error though, although it got quite a way through compilation


grub.c:27: warning: conflicting types for built-in function 'trunc'
grub.c: In function 'rgrub_help':
grub.c:538: error: missing terminating " character
grub.c:539: error: expected ')' before 'search'
grub.c:539: error: stray '\' in program
grub.c:539: error: stray '\' in program
grub.c:539: error: missing terminating " character
grub.c:543: error: missing terminating " character
grub.c:544: error: stray '\' in program
grub.c:544: error: stray '\' in program
grub.c:544: error: missing terminating " character
grub.c:548: error: too few arguments to function 'send_to_char'
grub.c:548: error: expected ';' before '}' token
make[1]: *** [grub.o] Error 1
make[1]: Leaving directory `/home/smee/smaug1.8/src'
make: *** [all] Error 2

Not sure on this one at all

David Haley USA Tue 24 Apr 2007 12:00 AM #2

You'd need to show us the line with the error for us to be able to help.

Also, what is Smaug 1.8a? I've never heard of it and a (very) quick google search is not helpful.

Smee Tue 24 Apr 2007 12:08 AM #3

Thanks, Smaug 1.8a I got from here:

http://ftpgame.org/cgi-bin/directory?/pub/mud/diku/merc/smaug
Which was a link from smaug.org

I had smaug a while ago, version 1.4a so assumed this was the latest version.

N

David Haley USA Tue 24 Apr 2007 12:12 AM #4

Oh, wow... that file is dated today. Nifty. I'll have to check that out when I get some time.

Kind of a shame that their code doesn't compile out of the box, though. :-) What was the line with the error?

Conner USA Tue 24 Apr 2007 12:17 AM #5

Yeah, according to the Smaug Mailing List:

-------- Original Message --------
Subject: [SMAUG] Smaug v1.8
Date: Tue, 24 Apr 2007 07:41:49 +0900
From: Edmond <edmond@realms.game.org>
To: smaug@realms.game.org

For the first time since 1998, we have posted a newer version of
SMAUG for public consumption to the FTP site.

SMAUG v1.8 is public use portions of the code as it existed on Realms
of Despair on August 17th, 2002. This is the date that Realms
implemented v2.0 of SMAUG.

SMAUG v1.8 does not come with a complete record of changes, as there
are simply too many changes to be made and it was a segment of the
code source being constructed parallel to v2.0 without any revision
control while we were simultaneously implementing updates/changes to
implement for the v2.0 update.

This version of code has been implemented and stable on our mortal
build port for just over a year. Crash errors have only occurred
when attempting to bring files back from v2.0 to 1.8 due to missing
flags/bvs, etc...

I also specify that there are still things we have left out of the
v1.8 release to the public that are Realms of Despair
specific. Certain methods of tracking cheats, items, objects, and
hacking specific fixes were omitted as they have been in all prior releases.

Finally, the online help files also remain rather inept, as
always. One would be well advised to run a "diff" between the new
code and 1.4a code to see what changes are available and how they
function in code speak. I've been attempting to get this release out
for over a year but do not have the coder resource time to
create/compare/compile all of the help files or adjust the help files
out from the existing 2.1 code on Realms main port.

Apologies in advance for the inadequacies. Looking forward to
responses from the public at large.

If there is a snippet of code or bug fix that has been integrated
into v1.8 (Blodkai and I did quite a bit of this) that wasn't
credited to you properly and you can confirm that it was yours,
please let us know right away so we can properly credit you here and
in the distributed source.

Edmond

Smee Tue 24 Apr 2007 12:18 AM #6

When you said you hadn't hear of it I thought the file might be a bit dodgy, didn't know if they were still working on it.

Line 27 onwards


{
   if ( strlen(s) > len )
      s[len] = '\0';
}

Line 538 onwards


void rgrub_help (CHAR_DATA *ch)
{
send_to_char( "Syntax:\n\r", ch);
send_to_char( "rgrub <type> n lo hi -  type search.\n\r"
   "   list room vnums between lo and hi that match n on <type> of
search.\n\r", ch );
send_to_char( "   e.g. rgrub st 6 901 969 - list all rooms in Olympus\n\r"
   "      that are sectortype 6.\n\r", ch );
send_to_char( "   e.g. rgrub st 2 - list all rooms sectortype 2.\n\r", ch );
send_to_char( "   e.g. rgrub f nomob 901 969 - list all rooms in
Olympus\n\r"
   "      that are flagged nomon.\n\r", ch );
send_to_char( "   e.g. rgrub f nomob - list all rooms flagged nomob.\n\r",
ch );
}

void do_rgrub (CHAR_DATA *ch, char *argument)
{
/* modified by Edmond to support room flag searches 000820 */

#define RGRUB_MAX_SIZE 5000
ROOM_INDEX_DATA *pRoom;
int x, lo, hi, hit_cou, cou, vnum[RGRUB_MAX_SIZE];

extern    ROOM_INDEX_DATA *room_index_hash[MAX_KEY_HASH];
char arg1[MAX_STRING_LENGTH];
char arg2[MAX_STRING_LENGTH];
char arg3[MAX_STRING_LENGTH];
char arg4[MAX_STRING_LENGTH];

David Haley USA Tue 24 Apr 2007 12:44 AM #7

The strings shouldn't break in the middle of the line like that; is that what it looks like in your source, or is that an artifact of pasting to the forum?

It's ok for several strings to appear in a row, e.g.

"abc" "def"
"ghi"

it should not be:

"abc" "de
f" "ghi"

Smee Tue 24 Apr 2007 12:59 AM #8

Thats how they showed in text editor (vi)

Fixed though and got next error <sigh!>


variables.c:285: error: invalid lvalue in assignment
variables.c: In function ‘fread_variable’:
variables.c:631: error: invalid lvalue in assignment
variables.c:653: error: invalid lvalue in assignment
make[1]: *** [variables.o] Error 1

variables.c line 283 onwards


    else
    {
        vd = make_variable(vtINT, vnum, arg2);
        (int)vd->data = atoi(argument);
    }

line 631 onwards


            (int)pvd->data = fread_number(fp);
                        fMatch = TRUE;
                    }
                    break;
                }
                break;

line 653 onwards


                       (char *)pvd->data = fread_string_nohash(fp);
                        fMatch = TRUE;
                    }
                    break;
                }
                break;

Getting there! Thanks for prompt responses.

David Haley USA Tue 24 Apr 2007 02:19 AM #9

This is just completely weird style; I don't know why the SMAUG authors insist on casting their lvalues, it's just not right and it's unclear what it's supposed to mean in the first place. Anyhow.

What you want to do is move the cast from the left side to the right side, and adjust it so that it's casting to whatever type vd->data is. I imagine it is a void*, so you probably want to cast to void*.
(I wonder if that code is 64-bit system safe...)

Zeno USA Tue 24 Apr 2007 02:19 AM #10

You can search for that error too, I think it was solved here.
http://www.gammon.com.au/forum/bbshowpost.php?id=7122

Smee Tue 24 Apr 2007 11:34 PM #11

Sorry I am not a C++ programmer, I do BBC BASIC, HTML and amd not too bad at PHP so do not understand what you mean.

Also, the link provided does not seem relative to the problem I am currently experiencing.

I am willing to be corrected, just confused at the moment, that is all.

David Haley USA Wed 25 Apr 2007 12:40 AM #12

Without having tested it, you want to make:

(int) vd->data = foo;

be

vd->data = (void*) foo;

it's quite possible that won't work, though, and again I have not tested this.

Samson USA Sun 17 Jun 2007 05:29 PM #13

(int)vd->data = foo;

had to become:

vd->data = (void*)(long)foo;

for it to compile properly on my 64 bit systems.

Results in ugliness like this:

vd->data = (void*)((long)atoi(argument));

which I'm sure is probably not the best way to do it but I wanted it to compile first and worry about ugliness later.

If the smaugdevs used more strict compiling flags we wouldn't have to deal with this to begin with :P