Compile errors with Murk++

Hi guys, I'm (obviously) new here, as I'm just embarking on the mud coding journey...

First of all, although the internet is probably no place for patriotism, I'd just like to say it's awesome to see an Aussie site with such intelligence ;) I'm currently stuck in Afghanistan, and must be a little homesick, hence the comment.

I'm trying to find a good codebase to play with that's written in C++ as I'm very keen to learn good OOP techniques. I downloaded three codebases, namely Murk++, DawnOfTime, and Scratch, and so far have been unable to compile any of them :P

I'm running Ubuntu 8.10 64bit on my lappy and am receiving the following error when trying to compile Murk++

gcc -O2 -pipe -g -o sqlite3/sqlite3.exe sqlite3/shell.o sqlite3/libsqlite3.a
sqlite3/libsqlite3.a(loadext.o): In function `sqlite3AutoLoadExtensions':
loadext.c:(.text+0x4f): undefined reference to `sqlite3WinEnterMutex'
loadext.c:(.text+0x67): undefined reference to `sqlite3WinLeaveMutex'
loadext.c:(.text+0x91): undefined reference to `sqlite3WinLeaveMutex'
sqlite3/libsqlite3.a(loadext.o): In function `sqlite3_reset_auto_extension':
loadext.c:(.text+0xe5): undefined reference to `sqlite3WinEnterMutex'
sqlite3/libsqlite3.a(loadext.o): In function `sqlite3_auto_extension':
loadext.c:(.text+0x125): undefined reference to `sqlite3WinEnterMutex'
loadext.c:(.text+0x163): undefined reference to `sqlite3WinLeaveMutex'
loadext.c:(.text+0x1b2): undefined reference to `sqlite3WinLeaveMutex'
sqlite3/libsqlite3.a(loadext.o): In function `sqlite3CloseExtensions':
loadext.c:(.text+0x1f9): undefined reference to `sqlite3WinDlclose'
sqlite3/libsqlite3.a(loadext.o): In function `sqlite3_load_extension':
loadext.c:(.text+0x2a8): undefined reference to `sqlite3WinDlopen'
sqlite3/libsqlite3.a(btree.o): In function `sqlite3BtreeOpen':
btree.c:(.text+0x81a0): undefined reference to `sqlite3WinFullPathname'
sqlite3/libsqlite3.a(pager.o): In function `sqlite3pager_opentemp':
pager.c:(.text+0x1217): undefined reference to `sqlite3UnixTempFileName'
pager.c:(.text+0x1227): undefined reference to `sqlite3UnixOpenExclusive'
sqlite3/libsqlite3.a(pager.o): In function `pager_unwritelock':
pager.c:(.text+0x1411): undefined reference to `sqlite3UnixDelete'
sqlite3/libsqlite3.a(pager.o): In function `pager_playback':
pager.c:(.text+0x1867): undefined reference to `sqlite3UnixFileExists'
pager.c:(.text+0x18aa): undefined reference to `sqlite3UnixOpenReadOnly'
pager.c:(.text+0x1944): undefined reference to `sqlite3UnixFileExists'
pager.c:(.text+0x1962): undefined reference to `sqlite3UnixOpenReadOnly'
pager.c:(.text+0x1b43): undefined reference to `sqlite3UnixDelete'
sqlite3/libsqlite3.a(pager.o): In function `pager_open_journal':
pager.c:(.text+0x20e3): undefined reference to `sqlite3UnixOpenExclusive'
pager.c:(.text+0x21e1): undefined reference to `sqlite3UnixDelete'
sqlite3/libsqlite3.a(pager.o): In function `sqlite3pager_open':
pager.c:(.text+0x27c7): undefined reference to `sqlite3UnixFullPathname'
pager.c:(.text+0x2a5c): undefined reference to `sqlite3UnixFullPathname'
pager.c:(.text+0x2a7d): undefined reference to `sqlite3UnixOpenReadWrite'
sqlite3/libsqlite3.a(pager.o): In function `sqlite3pager_get':
pager.c:(.text+0x31ab): undefined reference to `sqlite3UnixFileExists'
pager.c:(.text+0x32f1): undefined reference to `sqlite3UnixOpenReadOnly'
pager.c:(.text+0x3509): undefined reference to `sqlite3UnixDelete'
sqlite3/libsqlite3.a(pragma.o): In function `sqlite3Pragma':
pragma.c:(.text+0x669): undefined reference to `sqlite3_temp_directory'
pragma.c:(.text+0x67f): undefined reference to `sqlite3_temp_directory'
pragma.c:(.text+0x926): undefined reference to `sqlite3_temp_directory'
pragma.c:(.text+0x953): undefined reference to `sqlite3UnixIsDirWritable'
pragma.c:(.text+0x996): undefined reference to `sqlite3_temp_directory'
pragma.c:(.text+0x9c8): undefined reference to `sqlite3_temp_directory'
sqlite3/libsqlite3.a(random.o): In function `sqlite3Randomness':
random.c:(.text+0x27): undefined reference to `sqlite3UnixEnterMutex'
random.c:(.text+0xc7): undefined reference to `sqlite3UnixRandomSeed'
random.c:(.text+0x135): undefined reference to `sqlite3UnixLeaveMutex'
sqlite3/libsqlite3.a(vacuum.o): In function `sqlite3RunVacuum':
vacuum.c:(.text+0x144): undefined reference to `sqlite3UnixTempFileName'
vacuum.c:(.text+0x1a5): undefined reference to `sqlite3UnixDelete'
vacuum.c:(.text+0x1bf): undefined reference to `sqlite3UnixDelete'
sqlite3/libsqlite3.a(date.o): In function `localtimeOffset':
date.c:(.text+0x8d7): undefined reference to `sqlite3WinEnterMutex'
date.c:(.text+0x91c): undefined reference to `sqlite3WinLeaveMutex'
sqlite3/libsqlite3.a(date.o): In function `isDate':
date.c:(.text+0x11c9): undefined reference to `sqlite3WinCurrentTime'
collect2: ld returned 1 exit status
make: *** [sqlite3/sqlite3.exe] Error 1


Sorry for the lengthy post. As an addendum, would you guys recommend Murk++ as a good C++ codebase to sink my teeth into?

Thanks very much in advance for any help!

P.S. I've actually managed to get Dawn of Time to compile. I followed the instructions at:

http://forums.dawnoftime.org/viewtopic.php?t=2228

then recompiled. The first time it still threw deprecation errors, but upon just trying 'make' again, it seems to work. I now get the error:

Mud failed to complete the startup process
The startup process was terminated by do_read_classes()
With a message of: classes list not found
The last bug text in the log reads:
An error occured trying to open system/classes.txt for reading!

Once more, thanks again for any advice/help/suggestions.

Cheers guys.

Thanks for the comments. :)




Warnings. That's why it worked next time.



Somewhere in the notes that come with DoT it tells you that the first time you have to run it a special way to create files/directories. Something like:


./dawn --createdirs


Thanks for the reply Nick,

Yeah, let's just pretend I didn't post that second post :P I was in a hurry as internet time is limited over here, and I wanted to see if she'd compile before I left. Once I sat down and properly looked at what was going on, it was a simple process to get DoT going. Sorry to waste your time with that second question.

Are you able to provide me any help on the first though? Namely what's causing those sqlite errors in Murk++? And would you recommend it as a good stable example of a C++ codebase for beginners? I've also grabbed a copy of the Awakened Worlds codebase : http://www.awakenedworlds.net/
as it's a C++ conversion of circlemud, which I'm a bit more familiar with, but there's not much documentation for her.
Ultimately if you and Ksilyan would hurry up and release your Babble Mud, I'd use that ;)

Thanks for all the free snippets of code/quizes etc you throw on the site btw mate! They're all over my head, but I grab a copy and stare at them, hoping they'll imprint onto the brain :P

Cheers

Dunno about the sqlite3 stuff. Maybe sqlite is not installed? Old version? Looks like linker errors to me.

I haven't worked with Murk++, hard to comment on it.

The code base I usually recommend here is SmaugFUSS, which is the old Smaug codebase with lots of fixes, and is currently being maintained (unlike DoT).

However that is C, not C++.

I suppose it depends if your big focus is learning C++, or running a MUD, even if only for a handful of people. DoT was pretty cleanly written, last time I looked at it.

I think some of the other regular posters here use C++ codebases, maybe they can comment on which ones they recommend.

My goal is definitely to learn C++. I highly doubt any mud I end up coding will ever see the light of day. There are enough muds/mushes/moos out there with an already too thin playerbase for me to add to the mix.

Can I ask, what is your opinion of learning C prior to C++? I believe WhiteKnight said somewhere in these forums that he recommends that path (forgive me if I'm wrong on this WhiteKnight :)). Or is it better to learn good OOP-fu straight away?

Cheers

If you wanted to play with an existing codebase, like Smaug, then learning C would be fine. A lot of C translates into C++ (like control constructs such as for loops and so on).

However if you are starting, then I think I would go with C++.

You get a *huge* bonus with the STL - Standard Template Library. Don't underestimate what that can give you. See my posts here for some descriptions:

http://www.gammon.com.au/forum/?bbtopic_id=111

Basically STL (which requires C++) gives you things like:

• Much easier string management
  
• Containers like vectors, lists, queues, maps
  
• Iterators which let you work with containers

C++ objects have constructors and destructors. Constructors let you do useful things like initialize an object's values (for example, setting pointers to NULL). Destructors can be used to automatically free resources when an object goes out of scope, for example, freeing memory.

You also get inheritance, where you can have a base object, and then inherit its properties and add more. Just as an example, in a MUD you might have a generic object type (something the player carries) and then inherit that basic type to get a weapon, which has the basic attributes (eg. weight, cost) and adds more attributes (like how much damage it does).

C++ also lets you pass variables to function calls by "reference". I won't bore you with the details, but it is simpler than using pointers.

It's good to know, I'm on the right track then. I will stick to searching for a C++ codebase, I might just plow on with DoT. Murk++ seemed to be by far the most popular on the mudbytes code repository, and it was the most recent, hence why I chose it.

When I mentioned earlier your code chunks/quizzes etc that were over my head, one of them was your introduction to STL :P But I will continue to stare at her, and hopefully mitosis will take care of the rest.

Thanks again!

Personally I don't know Murk++ so I can't really comment on its appropriateness either way. Regarding C vs. C++ though, I don't think that you need to strictly learn C before C++. I think the important part is to take things slowly and not get too wrapped up in all the concepts that C++ throws at you, but there's no reason to force yourself to only use C when learning. As Nick has said, there are many very good reasons for using C++, not the least of which is sane string management (string management is probably the single largest source of errors for new programmers).

To be honest I actually don't know that many good C++ codebases out there. There are a few templates in various state of release (some written by Nick and yours truly) but most C++ codebases are relatively thin wrappers of C codebases and aren't what you might produce were you to start in C++ from scratch. The thing is that these days, if you were to write a whole codebase from scratch, you probably wouldn't be doing it exclusively in C/C++ anyhow, so it's rarer and rarer to see people working in just C++.

Thanks for the reply David,

I mentioned a few posts back that if you and Nick would kindly wrap up this whole Babble mud concept and release it, I'd be using that in a heartbeat (some people are just insensitive to the needs of others :P )

I understand a lot of people are looking at, and achieving writing codebases in scripting languages, Java etc, but for me, this is just a means to help me hack away at code while I read through C++ manuals etc.

As far as Dawn of Time goes, how much of that is C rewrapped as C++?

I'm actually trying to download the sourcecode for Ron Penton's book Mud Game Programming located at bettermud.cvs.sourceforge.net as I thought this might be perfect for me, but I'm having insane amounts of trouble getting cvs to work. I've tried different cvs commands and clients in both windows and linux, but I must be a cvs quamby :P

Does this look right:

cvs -d :pserver:anonymous@bettermud.cvs.sourceforge.net:/cvsroot/bettermud -r HEAD bettermud

Anyway thanks again for the reply, really appreciate all the help.

Cheers.

Try this:
cvs -d :pserver:anonymous@bettermud.cvs.sourceforge.net:/cvsroot/bettermud checkout BetterMUD


Well, we'll have to see on that one :-) For various reasons (most of them my fault -- life is ridiculously busy these days :-/) it hasn't been going as fast as I would like. Actually, interestingly enough I think, the main problem is one of game design, not really code. It's very difficult (basically impossible?) to write code without knowing what game you're writing it for... :-)

Oh yeah, I'd forgotten I wrote a MUD server in C++ <grin>.

Forum post:

http://www.gammon.com.au/forum/bbshowpost.php?id=4496

Download:

http://www.gammon.com.au/files/muds/tinymudserver_v2_3.tgz


It is pretty basic, but if you are starting off with C++ and MUD servers, this might be a good place to see the fundamentals.



As usual, I agree with David. ;)

Apart from doing something trivial, for fun, I would be putting a lot of work into design before I lifted hand to keyboard. Indeed, questions like "should I use C++?", whilst important, should be done after questions like "will I have instanced dungeons?" or "will I have ranged weapons?".

It is questions like those that will influence fundamental design concepts, and thus, the code that is written to meet those criteria.

I am leaning towards SQLite now, as a platform for storing MUD data. For one thing, you could have a very large MUD, but not have to load it all into memory on startup, as a lot of MUDs do. For another, you could change things on the fly, writing new room descriptions to the database, for example, while the MUD is live.

For the main engine I would use C++ (if I used a high level language at all). I experimented with doing an entire MUD in Lua, but I think that might have some possible problems.

For a script engine I would use Lua - that is fast and easy to integrate. Scripts could be used for things like mob AI handling.

Then you have the potential question: "do I want a custom client?". That one is sloshing around in my brain these days, and one day fairly soon I will be hopefully writing a lengthy post about that.

Thanks very much guys!

I'm pretty solid with background concept, as I'm basing it on a series of books well loved by yours truly, so I already have most of the ideas I want to see implemented in the mud worked out. (Although I'm sure once I actually get developing, that will change repeatedly and rapidly). There's also a pen and paper RPG for the series, from which I can steal ideas like the fight system, if I decide not to create it all myself.

As previously mentioned this mud will never see the light of the internet, it's just something to do to while away dead hours sitting in my bunk.

Thanks for the help with CVS David, I'll try that when I knock off work... This site is one of the few sites actually not yet blocked by the proxy server, yay! :)

The custom client (a la bat mud... which I never got into as it seemed a little too commercial to me) is a very cool idea Nick, I look forward to reading that post.

As an aside, do you guys actually still play muds? I know you are the head coder on a mud David, but do you still play? Or is the coding itself the game?

Cheers!

edit: Thanks very much for the link to your Tiny Mud Server Nick. I think that might be what I go with, as I can learn the functionality of the code and build upon it with a good understanding of what happens where, as opposed to trawling through hundreds of lines of code to understand relationships between bits of data.
Thanks again!

At work so must be brief, but to this:


No, I don't play MUDs anymore. Darkstone is mostly in maintenance mode with respect to coding; I prefer to focus major efforts on other projects (like the eternally pending BabbleMUD :P).


The more I write large systems in Lua, the more I think it's really not that great of an idea. Having to implement your own object orientation framework is nice if you need the flexibility, but annoying if you just want to get on with things. Having to write your own standard library (collection classes, common algorithms, etc.) gets old.

Lua is superb, excellent, outstanding, and many more great things when it comes to writing an add-on/plugin/scripting framework, but I'm not sure how appropriate it is for writing an entire, large application in.