24 Apr, 2015, erdrick wrote in the 1st comment:
Votes: 0
So a few years back, this used to compile cleanly and with no issues. Now that I am trying to boot it up again, it is giving me an error, and it seems to be due to the compiler version. Any help would be appreciated.

The difference is that in the makefile….

#CC = gcc
CC = gcc-4.3.4 <—– I had to change this to 4.4
PROF = -O -g

With this changed, when it gets close to compiling it all cleanly, I get

string.c:634: error: conflicting types for getline
/usr/include/stdio.h:671: note: previous declaration of getline was here
make[1]: *** [o/string.o] Error 1

So lines 634-635 in string.c are…

char *getline (char *str, char *buf)
{


I'm rusty at this coding thing, so I can't seem to figure out what is wrong. Any help would be appreciated.
25 Apr, 2015, Davion wrote in the 2nd comment:
Votes: 0
There's an builtin function called getline. You'll have to change the definition to something like rom_getline() and then grep the .c files for calls, and change their calls also to rom_getline() so you don't accidentally call the builtin.
25 Apr, 2015, erdrick wrote in the 3rd comment:
Votes: 0
Uh…where do I change the definition of that? lol. Sorry. More exactly, what exactly am I changing? The getline portion to rom_getline is all the .c files?
25 Apr, 2015, erdrick wrote in the 4th comment:
Votes: 0
Woah. I changed the getline to rom_getline in string.c, tried the compile again..and it worked. Let's see if it boots…
25 Apr, 2015, Davion wrote in the 5th comment:
Votes: 0
erdrick said:
Woah. I changed the getline to rom_getline in string.c, tried the compile again..and it worked. Let's see if it boots…


It will boot. But you should look for other calls to getline. Do a grep in your src directory for "getline". I'm thinking they're all in string.c so you should be good just to change the calls in string.c from getline to rom_getline.
25 Apr, 2015, erdrick wrote in the 6th comment:
Votes: 0
Yeah, I went through string.c and there was only 2 getline lines. I'm checking the rest now, but it seems like it was only in that one file.
25 Apr, 2015, erdrick wrote in the 7th comment:
Votes: 0
Maybe you can help me with this….if I have to be in the area folder, but start the mud from the src folder, there is a command to do t hat right? Because I have to be in the area folder to start it…but the startup file is in src. I can't remember how to do that..
25 Apr, 2015, Nathan wrote in the 8th comment:
Votes: 0
I'm not sure why you'd need to be 'in' the area folder to start the mud, but you can call something in a different folder quite easily.

if directory structure is like this:
areas
src

If you are 'in' areas and want to run a script called 'startup' that is in src you can type this (I think): ./../src/startup &
25 Apr, 2015, Tijer wrote in the 9th comment:
Votes: 0
i think stock releases have it so you boot the mud from the areas directory…. startup is generally in the areas directory too!!
25 Apr, 2015, quixadhal wrote in the 10th comment:
Votes: 0
You need to be "in" the area directory because most Dikurivatives assume the pathnames of all the data files are rooted from the current working directory. So, they try to load "area.lst" instead of "areas/area.lst" or "../area.lst" or "/home/foo/mud/area.lst".
25 Apr, 2015, Nathan wrote in the 11th comment:
Votes: 0
@quixadhal
I see. Do you know if that was a silly choice on the part of the original developer (Diku) or if it came later?
25 Apr, 2015, Pymeus wrote in the 12th comment:
Votes: 0
FWIW, "getline" seems to have only been standardized in 2008, although glibc appears to have had an implementation for a long time before that.
26 Apr, 2015, quixadhal wrote in the 13th comment:
Votes: 0
Nathan said:
@quixadhal
I see. Do you know if that was a silly choice on the part of the original developer (Diku) or if it came later?


My DikuMUD alfa was like that, although we called them "zones", and there wasn't any list. It just loaded wld/tinyworld.zon and so forth. One of the very first changes I did was to make the path relative so you could be in any subdirectory, not just the world file one. It would, of course, be better to have it search around for them, or push all that crud into a database and stop worrying about files. :)
0.0/13