Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
Bug in get_exp_worth( )
Oct 10, 2017, 1:26 am
By GatewaySysop
Bug in do_drag( )
Oct 8, 2017, 12:40 am
By GatewaySysop
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Beastmaster 6D sound files
Author: Vladaar
Submitted by: Vladaar
Users Online
CommonCrawl, Yahoo!, Bing, DotBot

Members: 0
Guests: 21
Stats
Files
Topics
Posts
Members
Newest Member
476
3,704
19,231
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » AFKMud Support & Development » AFKMud 2.1 and g++ 4.3.2
Forum Rules | Mark all | Recent Posts

AFKMud 2.1 and g++ 4.3.2
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 Sep 18, 2008, 10:36 am
Go to the top of the page
Go to the bottom of the page

wowgonna
Fledgling
GroupMembers
Posts4
JoinedSep 18, 2008

I extracted stock afk 2.1, commented IMC = 1 in the makefile due to errors in imc.cpp and ran make, slew of errors.
AFKMud Compile Error

I'm sure that this is an easy fix, but I'm complete noob at c++. It appears as if my system doesn't have the c++ includes but I've check and they are there.

Any help would be appreciated.
       
Post is unread #2 Sep 18, 2008, 11:02 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Some of those are interesting -- it looks like declaring an object of name "map" makes it unhappy due to shadowing the STL map.

Errors like these:
act_comm.cpp:234: error: must #include <typeinfo> before using typeid

are easy to fix, just #include <typeinfo> somewhere, e.g. mud.h (if AFKMud has such a thing).

And this:
act_comm.cpp:1152: error: conversion to ‘short int’ from ‘int’ may alter its value

I'm surprised to see this as an error, even though I guess it should be. Anyhow, you need to either adjust the return types (more correct but harder solution), or introduce explicit casts (easier but perhaps dangerous solution).
       
Post is unread #3 Sep 18, 2008, 11:47 am   Last edited Sep 18, 2008, 11:53 am by wowgonna
Go to the top of the page
Go to the bottom of the page

wowgonna
Fledgling
GroupMembers
Posts4
JoinedSep 18, 2008

I needed typeinfo cstring and cstdlib all included but still had numerous errors with 4.3.2, installed g++ 4.2 and added -Wno-address to quiet errors such as:
db.cpp: In function ‘void append_file(char_data*, const std::string&, const char*, ...)’:
db.cpp:2363: warning: the address of ‘str’ will always evaluate as ‘true’
db.cpp: In function ‘void append_to_file(const std::string&, const char*, ...)’:
db.cpp:2394: warning: the address of ‘str’ will always evaluate as ‘true’

The allowed make to complete. I'm guessing a lot of work needs to be done to get it to compile in 4.3 w/o warnings/errors.
I telnet in and login as admin, as soon as I enter the world it segfaults, gdb producing:
Thu Sep 18, 2008 1:48:51 PM CDT :: Admin returns from beyond the void.
[New Thread 0x7fc1125436f0 (LWP 813)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fc1125436f0 (LWP 813)]
rankbuffer (ch=0x6d5942) at player.cpp:92
92 if( ch->pcdata->rank && ch->pcdata->rank[0] != '\0' )
(gdb) backtrace
#0 rankbuffer (ch=0x6d5942) at player.cpp:92
#1 0x0000000000669db9 in web_who () at web.cpp:287
#2 0x000000000057a159 in ev_webwho_refresh (data=0x6d5a92)
at event_handler.cpp:590
#3 0x0000000000579e26 in run_events (newtime=1221763731) at event.cpp:148
#4 0x0000000000545627 in game_loop () at comm.cpp:949
#5 0x0000000000545dea in main (argc=<value optimized out>,
argv=0x7fff1a56ba68) at comm.cpp:1337

       
Post is unread #4 Sep 18, 2008, 8:17 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Oh boy. Did GNU pull another one of these stupid ass "lets make some new errors" games again?

Also note to self: Fix those cockeyed international characters that keep showing up.
       
Post is unread #5 Sep 19, 2008, 8:49 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Samson said:

Also note to self: Fix those cockeyed international characters that keep showing up.


That one I can help with. If you're referring to the post above, that's because the person using gcc has their system locale set to something "funky". Where "funky" is anything that isn't just plain ASCII. Most of the modern linux distros tend to force people into UTF-8 or something similar, and gcc will use the locale setting to adjust how it reports errors (highlighting and such).

The easy fix is to put this in your .bashrc.

export LANG=C

"C" is the plain ASCII locale that doesn't allow any extended characters, like Latin-1 and friends. You lose the minimal foreign language support (N with the ~), but gain the clear concise UI we had before international committees decided we had to try to support every character set in every language on earth, at the same time.

Oh, and note that this isn't something you can fix on your end Samson. This is an interaction between the compiler, the shell (and terminal), and the settings on the system invoking the compiler. Unless you can get everyone to switch to the "C" locale, or somehow get the forum to filter those out perhaps.
       
Post is unread #6 Sep 19, 2008, 10:59 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Why is it so terrible to have the system use UTF-8? It makes a lot of things prettier even in plain ol' English. And I think what Samson meant is that he can fix things on the forum side by having it either convert to ASCII or filter the characters.

As for the compiler issue: well, it's just preventing people from doing things they really shouldn't be doing anyhow. Arguably, a conversion to short int from int is a worse sin than the constness. Warning about addresses evaluating to true is not new, but is also a good thing because it informs whoever wrote the code that they didn't understand what they were doing with pointers. But, well, we've talked about this issue ad nauseam already with the constness warnings.
       
Post is unread #7 Sep 19, 2008, 11:01 am
Go to the top of the page
Go to the bottom of the page

wowgonna
Fledgling
GroupMembers
Posts4
JoinedSep 18, 2008

wowgonna said:


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fc1125436f0 (LWP 813)]
rankbuffer (ch=0x6d5942) at player.cpp:92
92 if( ch->pcdata->rank && ch->pcdata->rank[0] != '\0' )
(gdb) backtrace
#0 rankbuffer (ch=0x6d5942) at player.cpp:92
#1 0x0000000000669db9 in web_who () at web.cpp:287


Anyone have a clue as to why the above line is segfaulting? I'd really like to get this running.
       
Post is unread #8 Sep 19, 2008, 11:09 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Chances are that either ch or ch->pcdata is null. The real interesting question is why that would be, especially if you are using a completely stock base and haven't modified it at all.
       
Post is unread #9 Sep 19, 2008, 1:22 pm
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

ch->pcdata is going to be null if it was called from a web form. :P
       
Post is unread #10 Sep 19, 2008, 1:49 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Kind of funny that nobody ever found this bug before, no? I mean, I wouldn't expect a web who list to be a particularly obscure feature...
       
Post is unread #11 Sep 19, 2008, 2:38 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

That's sort of the reason development was halted. Lack of interest. Even obvious bugs like this that should have been caught aren't because there aren't enough eyes on the code and never really were. I was only able to find so many developing for a dead game :P
       
Post is unread #12 Sep 22, 2008, 9:14 am
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

Yeah I know what you mean. I made this same mistake when I coded new stuff into webwho, and I wouldn't have caught it if no one used webwho.

But people did, and boom... crash. :P
       
Post is unread #13 Oct 5, 2008, 3:25 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Ok. Took the plunge and updated the OS here. Which has gcc 4.3 now, so I'm seeing all the lovely new warnings and hard errors. I'll bring the codebase out of hiatus to fix these.

character.h: In member function 'void char_data::WAIT_STATE(int)':
character.h:461: error: conversion to 'short int' from 'int' may alter its value


This stems from the bugfix for the old UMAX macro in which the macro was redirected to a function. That function, along with UMIN and URANGE, became these:

int umin( int check, int ncheck )
{
   if( check < ncheck )
      return check;
   return ncheck;
}

int umax( int check, int ncheck )
{
   if( check > ncheck )
      return check;
   return ncheck;
}

int urange( int mincheck, int check, int maxcheck )
{
   if( check < mincheck )
      return mincheck;
   if( check > maxcheck )
      return maxcheck;
   return check;
}


What the compiler is now complaining about is that the "wait" value, which is usually ch->wait, is a short integer. That's being passed to the new umax() function which is taking normal integers as arguments. The function in character.h where the problem arise from is this:

   void WAIT_STATE( int npulse )
   {
      ( wait = UMAX( wait, ( is_immortal(  )? 0 : npulse ) ) );
   }


Where, again, "wait" is ch->wait. The simple solution is to change the definition of ch->wait to an int, but the long term solution is to fix the umin(), umax(), and urange() functions to accept multiple types. My preference would be for a template to handle this rather than making dozens of versions of these to account for all the different number types that exist. But I'm not sure how to do that.

character.h:608: error: declaration of 'short int char_data::map'
/usr/include/c++/4.3/bits/stl_map.h:92: error: changes meaning of 'map' from 'class std::map<int, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<int>, std::allocator<std::pair<const int, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >'


This one is easy. Find:
   short map;  /* Which map are they on? - Samson 8-3-99 */


Change to:
   short cmap;  /* Which map are they on? - Samson 8-3-99 */


The downside is this will create a zillion more compiler errors that will need to be fixed because ch->map will no longer exist. They'll just need to become ch->cmap etc. instead. Long tedious process, but apparently necessary now.

In file included from act_comm.cpp:30:
mud.h: In function 'char* bitset_string(std::bitset<_Nb>, const char**)':
mud.h:1375: error: there are no arguments to 'strlen' that depend on a template parameter, so a declaration of 'strlen' must be available
mud.h:1375: error: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)


Gah. This reeks of assholery on GNU's part. Solveable by adding
#include <cstring>
to the include list in mud.h, but damn them, this is going to bloat up the binary file :/

The rest of the stuff in that pastebin looks solveable in similar manners. Somewhere along the way one of the included heade files AFKMud calls up must have dropped the internal include for stdlib, which is going to make it necessary for me to do that explicitly now.
       
Post is unread #14 Oct 5, 2008, 5:03 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

conversion to 'short int' from 'int' may alter its value


Figured it out. Ditch the -Wconversion flag. That will silence literally thousands of uber-paranoid warnings that apparently were never being displayed before. I don't even know when this flag was added but it's getting removed now since all it's doing is generating worthless compiler spam and hiding the real errors that were apparently not errors in gcc 4.1 or 4.2 :rolleyes:
       
Post is unread #15 Oct 5, 2008, 11:50 pm
Go to the top of the page
Go to the bottom of the page

wowgonna
Fledgling
GroupMembers
Posts4
JoinedSep 18, 2008

Thanks for checking into it, I haven't developed for any mud in a long time and haven't played one for even longer still. I recently did, however, start playing Aardwolf, which I believe is AFKMud, very very nice. A real shame there arent more of them out there, the overworld is real nice. I read the thread about why people don't use afk, and #1 response was having to rip out overworld, I dont see why...
       
Pages:<< prev 1 next >>