Getting .90 to compile on linux

Csonicgo · Post by **Csonicgo** » Mon Oct 25, 2004 8:26 pm

I sure hopeyou all get the "bugs" out... playing zdoom in linux would rock.

A question- will Wine run it? i haven't tried, I'm not on my linix comp at the moment. I will soon be getting linux for my big computer anyays- knoppix.

Post by **Chris** » Mon Oct 25, 2004 9:11 pm

Wine seems to be hit and miss (with more miss than hit). I wouldn't count on Wine running it.

guru · Post by **guru** » Tue Oct 26, 2004 3:11 am

nopes neither zdoom, nor zdoomgl work with wine. there is a runtime error even before opening the sourface

haven't tried wineX CVS though

rpeter · Post by **rpeter** » Tue Oct 26, 2004 7:30 am

I haven't tried v91, but that iterator thing was in earlier versions, too. In v63a:

#if defined(_MSC_VER) || defined(__GNUC__)
#include "autosegs.h"

TypeInfo DObject::_StaticType =
{
"DObject",
NULL,
sizeof(DObject),
};

void TypeInfo::StaticInit ()
{
TAutoSegIterator<TypeInfo *, &CRegHead, &CRegTail> probe;

while (++probe != NULL)
{
probe->RegisterType ();
}
}
#else
TypeInfo DObject::_StaticType(NULL, "DObject", NULL, sizeof(DObject));
#endif

And mingw's gcc (3.2.3) compiled it.

Post by **Chris** » Tue Oct 26, 2004 7:54 am

I didn't have any problems compiling it. But it seems that the objects that are supposed to be auto-insterted between CRegHead and CRegTail don't, so they never get registered and the game dies when it tries to use them.

rpeter · Post by **rpeter** » Tue Oct 26, 2004 12:03 pm

Well, all I can think of is either there's a #ifdef missing or misplaced somewhere or gcc has taken another turn. I'm not following the Linux world, but I guess gcc on Linux could be up to 3.4 or 3.5 version, breaking somewhere some compatibility with older versions, like that of mingw's. Provided mingw can build v91 at all, not just v63a. I haven't tried it, it's a pain in the ass compiling ZDoom on a 560MHz Celeron CPU...

Post by **Chris** » Tue Oct 26, 2004 6:32 pm

I guess gcc on Linux could be up to 3.4

Linux GCC is up to 3.4, though I'm using 3.3(.2).

ryan · Post by **ryan** » Tue Oct 26, 2004 10:08 pm

hey guys, nice to see another effort in the portability department. before i start i'm just going to say i wish i could help (meaning i have no knowlege of c++, or c) but thats not possible at this point in time. however while i'm running freebsd i would like the chance to take some of the code you have hacked and try to build it. however this could only happen by building it without fmod, as fmod isn't as portable as they claim

on the other hand, there is the possibility of running the linux binary straight up, which for the most part works great with other linux binaries suck as quake3 and doom3, but the closest thing to zdoom, which is zdaemon, segfaults. the third closest thing to zdoom, skulltag, has a linux binary that _does_ run but has some weird issue where it goes sorta slow motion (lord only knows) anyway, good luck.

- ryan

Mannequin · Post by **Mannequin** » Tue Oct 26, 2004 10:27 pm

Psycho Siggi wrote:I find it kinda funny that all the linux users don't have an avatar.

Huh! That's funny... I've always had an avatar since Randy switched to the new forums...

I'm running Debian Testing/SID kernel 2.6.8 on a PPC. I'd try and offer help along with the others, but ZDoom isn't exactly set up for the PPC architecture.

-M.

Post by **Chris** » Tue Oct 26, 2004 10:45 pm

ryan wrote:hey guys, nice to see another effort in the portability department. before i start i'm just going to say i wish i could help (meaning i have no knowlege of c++, or c) but thats not possible at this point in time. however while i'm running freebsd i would like the chance to take some of the code you have hacked and try to build it. however this could only happen by building it without fmod, as fmod isn't as portable as they claim ;)

It should be possible to make FMOD disable-able.. although you'll get no sound unless compatible SDL code is written. And even then, you might have to do without music.

But we'll keep at it. Hopefully something will turn up to clear out this mystery.

Post by **Chris** » Wed Oct 27, 2004 2:24 am

Update:
In a PM, randy mentioned that my wildcard search was probably the culprit, since two of the files need to be linked in the proper order.. autostart.o first and autozend.o last. I modified the makefile slightly and that was indeed the case. Modify the makefile so that autostart.o is listed first and autozend.o is listed last.

Also, there's some source modifications that need to be made. First is in infodefaults.cpp, line 128:

Code: Select all

	while ((defnum = *(WORD *)parser) != ADEF_EOL)

/* change this to */
	while ((defnum = *(WORD *)parser) != ADEF_EOL && defnum != 0)

Also, while compiling you might have noticed a couple errors like this:

warning: `bool' is promoted to `int' when passed through
`...'
warning: (so you should pass `int' not `bool' to `va_arg')

This is fatal! I'm currently in the process of fixing it myself, so I'll report back. Apparently this only occurs in src/v_draw.cpp, lines 230 and 238. As the warning says, change bool to int.

EDIT:
It works! I successfully played through Doom2 MAP01 and killed the three zombies in MAP02. There seems to be some general bugginess with setting the keys in the in-game menu, though.. and trying to play with sound crashes my system. But it does run.

rpeter · Post by **rpeter** » Wed Oct 27, 2004 5:59 am

Well, did a build on mingw:

C/C++ only, without optimization.
Just 3 errors during compiling:
-eaxedit.cpp
#ifndef OFN_ENABLESIZING was interfering, it was in v63a also.

-p_doors.cpp EV_SlidingDoor: jumping into a loop.

-d_main.cpp D_DoStrifeAdvanceDemo: invalid conv. from const char * to char *.

Some minor stuff as well: HAVE_STRUPR, HAVE_FILELENGTH needed to be defined.

However the exe fails: Unknown class <chinese stuff> in TeleportFog's default list.

I guess that's the error you were getting on Linux.

I'll try that autostart/autozend trick, once I figure out how to do it with visula-mingw.

rpeter · Post by **rpeter** » Wed Oct 27, 2004 7:08 am

Well, there's a definit change, ZDoom now crashes without a dialogbox. Dr.Mingw crashes on debug. I think I'll stick to Randy's binary.

guru · Post by **guru** » Wed Oct 27, 2004 11:50 am

yehaa

[edit] yup. working fine here. I'm running gentoo linux with 2.6 kernel and xorg. same problems with keyconfig. again - thanks chris, and thanks randy

[edit] oh and sound not working either

Post by **Chris** » Wed Oct 27, 2004 5:07 pm

rpeter wrote:Well, did a build on mingw:

C/C++ only, without optimization.
Just 3 errors during compiling:
-eaxedit.cpp
#ifndef OFN_ENABLESIZING was interfering, it was in v63a also.

-p_doors.cpp EV_SlidingDoor: jumping into a loop.

-d_main.cpp D_DoStrifeAdvanceDemo: invalid conv. from const char * to char *.

Some minor stuff as well: HAVE_STRUPR, HAVE_FILELENGTH needed to be defined.

However the exe fails: Unknown class <chinese stuff> in TeleportFog's default list.

I guess that's the error you were getting on Linux.

Basically, yeah (sans OFN_ENABLESIZING, HAVE_STRUPR, and HAVE_FILELENGTH). And after I fixed the link-order problem, I got a similar failure like you did about unknown class <blank> in something's default list. It seems to be some kind of bug in FActorInfo::ApplyDefaults because the first time I ran it without the check-for-0 change, it said Cajun's default list, the next it said the Arachnotron's, and the third it segfaulted.

I do hope Randy's still reading this thread.

I'll try that autostart/autozend trick, once I figure out how to do it with visula-mingw.

That should only be needed for Linux. The Win32 port gets a handle to the program's module and reads the data sections directly. Though I personally think using the seperate data sections is ugly, and a better method would be to use resizeable vectors that are filled before (win)main is run.