TinTin++ Mud Client The TinTin++ message board

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
TinTin++ Mud Client

Build Tintin without pThread?

 
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> General Discussion
View previous topic :: View next topic  
Author Message
Picklesworth



Joined: 09 Apr 2007
Posts: 4

PostPosted: Mon Apr 09, 2007 6:53 pm    Post subject: Build Tintin without pThread? Reply with quote

First off, hi and thanks for a really nice, text-based MUD client that is clearly built with portability in mind. It's hard to find well supported text-based programs written in C these days!
My only problem with this program is that its name sent me on a wild tangent of rereading Tintin books when I should have been working :P

Okay, so I am trying to build Tintin++ for DSLinux.

Luckily, Tintin has a really good configure script (far better than TinyFugue's mean, cross-compiler-hating thing). Tintin's config script is working fine with the cross-compiling environment.
All the libraries are detected except one: libpthread. I don't think this is Tintin's fault; the library is disabled in DSLinux by default and nobody seems to have had success with it so far. Its nonexistence seems to be a problem with the DSLinux toolchain not liking it. (Note: We have pthread.h, but not libpthread).
Anyway, the config script doesn't terminate or anything, it keeps going and tells me I can run make... seems almost as though pthread is unnecessary.
However, once it gets to linking I quickly get an error from chat.c about an undefined reference to pthread_create. Evidently, the missing (unworking?) library is breaking this.

I don't think I can fix pthread because I know little about cross-compiling, uClinux or toolchains (or Linux at all, really)... so I have one choice: Getting Tintin to cooperate.
Is it entirely necessary to use pthread in Tintin, or can it operate in some way without it?
Any help to achieve a pthread-less Tintin, or any loud exclamations of "you idiot, don't waste your time on that!" would be greatly appreciated :)


Edit:
! A quick search for files containing the string "pthread" seems to say that the only source file with pthread mentioned is chat.c, and that file only uses it in the single function chat_call. Perhaps chances are a bit better than I think?
Assuming that chat.c is for the Chat feature, I'm assuming it is not integral (it isn't integral, right?), so can I turn that feature off?
Hehe, nice code by the way. I don't know why people dislike C; I think it's awesome. Everything seems to be neater and tidier in it!
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Tue Apr 10, 2007 4:06 am    Post subject: Reply with quote

Hiyas,

I fiddled with the configuration stuff and with a little luck things should work now after you reconfigure. The updated sourcecode is at: http://tintin.sf.net/download/tintin-beta.tar.gz

If that doesn't do the trick edit config.h and find:

#define HAVE_LIBPTHREAD 1

#define HAVE_PTHREAD_H 1

and set both to 0.
Back to top
View user's profile Send private message Send e-mail
Picklesworth



Joined: 09 Apr 2007
Posts: 4

PostPosted: Tue Apr 10, 2007 9:00 pm    Post subject: Reply with quote

Yay! Thanks, Scandum.

I just earlier managed to pull out mention of pThread from chat.c manually, but this is much tidier!
The build I managed to pop together did run, start and do everything except for create a session (and I didn't dare try the chat option). Some kind of memory management problem with calloc returning NULL a lot of of the time made it crash in create_session. Hopefully it will work better with this one; the last one was pretty shakey anyway thanks to my pitiful method of 'just making it compile'.

For now it's moved on to a brand new linking problem with rpl_realloc and uClibc (the config script thinks my libc sucks because malloc(0) returns NULL instead of something else), but it seems well documented and not really anyone's fault. Looks like it's fixable, too.

So thank you for your help, that seems to have done the trick. I'll let you know how it goes.

By the way, I am quite grateful to have bumped into these little kinks. I'm still learning this whole cross-compiling with ginormous source codes and Make thing, so something like this gives me a lot of hands-on learning. May be useful some day Smile

Edit:
Okay, I just had to change "#define realloc rpl_realloc" to "/* #undef realloc /*" in config.h and it compiled again. Still crashes when I create a new session, though... Ah well, it's looking happier.

Edit 2:
Interesting...
This is weird!
Okay, firstly here is my awesome ultra verbose (output for every line) debugging of session.c's new_session function:
Code:
newsession                = calloc(1, sizeof(struct session));
   
   if (newsession == NULL)
   {
      tintin_puts(ses, "#Newsession object creation failed!"); //Outputting this one at the moment :(
   }else{
      tintin_puts(ses, "#Created newsession object! Or so we think...");
   }
   //newsession is not being created; calloc outputs NULL.
   
   /*
   Note:
   "Name" variable is fine. Strdup is not the problem. The
   below can be rearranged and will still fail on the first line.
   The problem is probably the newsession object...
   */

   tintin_puts(ses, "#pre newsession->name = strdup(name);");
   newsession->name          = strdup(name);
   tintin_puts(ses, "#post newsession->name = strdup(name);");
   
   tintin_puts(ses, "#pre newsession->class = strdup(gts->class);");
   newsession->class         = strdup(gts->class);
   tintin_puts(ses, "#post newsession->class = strdup(gts->class);");
   
   tintin_puts(ses, "#pre newsession->flags = gts->flags;");
   newsession->flags         = gts->flags;
   tintin_puts(ses, "#post newsession->flags = gts->flags;");
   
   tintin_puts(ses, "#pre newsession->telopts = gts->telopts;");
   newsession->telopts       = gts->telopts;
   tintin_puts(ses, "#post newsession->telopts = gts->telopts;");
   
   tintin_puts(ses, "#pre newsession->host = strdup(host);");
   newsession->host          = strdup(host);
   tintin_puts(ses, "#post newsession->host = strdup(host);");
   
   tintin_puts(ses, "#pre newsession->port = strdup(port);");
   newsession->port          = strdup(port);
   tintin_puts(ses, "#post newsession->port = strdup(port);");
   
   /*
   Nope, it gets worse. The program gets through that entire set
   of commands (newsession object is created) down to here,
   then crashes, if the session is   created without first checking
   and finding no sessions. (Hitting Enter when program starts).
   
   Important question: What the heck is gtd? I bet it's NULL.
   --gtd is an instance of tintin_data struct.
   --It is created when the program starts, near top of main in main.c
   --No problems appear then, and it is given many values
   --No, it is not NULL.
   */
   
   if (gtd == NULL)
   {
      tintin_puts(ses, "#gtd object is NULL!");
   }else{
      tintin_puts(ses, "#gtd object exists! Or so we think...");
   }

   gtd->ses  = newsession;


Okay, so if I am at the title screen, then I hit enter so it tells me to create a new session, newsession is not allocated by calloc (returns NULL) and so the program crashes when it tries to write to that NULL pointer.

However (and this is where it gets weird), if I do not hit Enter and instead just go straight ahead to punching in #session blah blah blah, the newsession object is created.

It also works fine if I enter another command at the start (like #help), before starting a session, or even if I type #session notEnoughArguments. There seems to be a specific connection to the "No Session Active" message, or something connected to it.

With the version I was using before, that moment of happiness did not last long and it crashed on I believe gtd->ses = newsession;.
With this new version, that does not seem to happen; it creates the session, connects, shows the login screen (drum roll!!!) and crashes Sad
It crashes right where it should start asking for input, curiously enough...

Correction:
That crash which occured when I had to input my username and password: It looks pretty random, actually. I just logged in and executed a look command (lots of output. This is Achaea; they're very talkative), then it crashed again. I don't think it's output hurting it, as I crashed it again by typing the look command and it crashed as soon as I hit enter to send it.
Probably DSLinux's fault, come to think of it. Time to decifer stack traces! Yay!

An error message is displayed, consistently, every time the login screen for the MUD comes up: "#Failed to initialize MCCP2."

By the way, something weird that isn't to do with crashes: If I start Tintin while not connected to the network, it seems to permanently assume that I am not connected. If I go over to another terminal and connect, attempts to start a session still fail with an immediate claim that it cannot connect. Is this an expected behaviour? (Does it check if the network is up when it initiates and then remember that?)

Err, sorry, I'm in a very verbose mood today. Lots of useless, stream of consciousness information Embarassed
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Wed Apr 11, 2007 4:45 am    Post subject: Reply with quote

Picklesworth wrote:

The build I managed to pop together did run, start and do everything except for create a session (and I didn't dare try the chat option). Some kind of memory management problem with calloc returning NULL a lot of of the time made it crash in create_session.

It's possible it crashes on string = strdup(""); which makes sense if tintin crashes on an enter. In that case entering 'bla' right after the start wouldn't crash it either.

Quote:

Important question: What the heck is gtd? I bet it's NULL.

Instead of using a lot of global variables I have one global structure that holds most global variables. I find it tidier, which I guess means I code like a girl. Totally Sweet

Quote:

An error message is displayed, consistently, every time the login screen for the MUD comes up: "#Failed to initialize MCCP2."

The failure to initialize MCCP has probably to do with your OS since it is properly enabled upon connect for me.

Quote:

By the way, something weird that isn't to do with crashes: If I start Tintin while not connected to the network, it seems to permanently assume that I am not connected. If I go over to another terminal and connect, attempts to start a session still fail with an immediate claim that it cannot connect. Is this an expected behaviour? (Does it check if the network is up when it initiates and then remember that?)

It doesn't.

Quote:
Err, sorry, I'm in a very verbose mood today. Lots of useless, stream of consciousness information Embarassed

Don't worry, I prefer it to the occasional 'yo tintin dos not wok lol, help?' shout outs I get.

Anyway, can you install version 1.96.8, disable the threaded code in chat.c and see if it runs better? Memory allocation wise I made some huge changes between 1.96.8 and 1.96.9. So it's possible 1.96.8 will work for you.
Back to top
View user's profile Send private message Send e-mail
Picklesworth



Joined: 09 Apr 2007
Posts: 4

PostPosted: Thu Apr 12, 2007 12:38 am    Post subject: Reply with quote

Aha!
1.96.8 works BEAUTIFULLY with your changes to chat.c!
My suspicion was 100% accurate, too: This client fits the DS wonderfully. Even that weird problem I had earlier (the one that wasn't to do with crashes) and the failure to initiate MCCP no longer happening with this version. So far it is completely error free.

Thank you very much for your help and your time, Scandum.
By the way, if the thought for some reason crosses your mind, there is no need to support this weird platform by downgrading the memory management; I can see that a lot indeed has been done under the hood between the two versions and it's probably for the better on every other computer out there.
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Thu Apr 12, 2007 3:28 am    Post subject: Reply with quote

Hopefully DS will fix the issue eventually, assuming a lot of software malfunctions.

If you experience any other weirdness it's possible you have to use: #class default open when starting tintin.


Additionally, it might be possible to fix the issue without too much trouble: in memory.c replace the two instances of

mem->data = strdup(string);

with:

mem->data = *string ? strdup(string) : calloc(1, 1);
Back to top
View user's profile Send private message Send e-mail
Picklesworth



Joined: 09 Apr 2007
Posts: 4

PostPosted: Fri May 25, 2007 8:58 am    Post subject: Reply with quote

Hi again. Just thought you might want to see your project living on this game console Smile
http://picasaweb.google.co.uk/DylanMcCall/TintinOnDSLinux?authkey=_f6CKf7C-fA
Kinda cool!


(Can't really see it because of the lighting, but the 2nd image shows the whole thing)


Last edited by Picklesworth on Fri May 25, 2007 5:34 pm; edited 1 time in total
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Fri May 25, 2007 5:27 pm    Post subject: Reply with quote

Looks pretty cool, you might want to try #map flag asciigraphics.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> General Discussion All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads
TinTin++ Homepage

Powered by phpBB © 2001, 2002 phpBB Group