Building gzdoom in linux with cmake

Advanced OpenGL source port fork from ZDoom, picking up where ZDoomGL left off.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Wiki] [Repo] [Bugs&Suggestions]

Moderator: Graf Zahl

Locked
User avatar
Rachael
Developer
Developer
Posts: 3651
Joined: Sat May 13, 2006 10:30

Re: Building gzdoom in linux with cmake

Post by Rachael »

Considering that we already have several people who hop right into the bugs forum very shortly after a commit if something doesn't compile, I think the best thing for Graf is probably either a remote or virtualized Linux computer to test compiles on.
Top
User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:
Contact GuntherDW

Re: Building gzdoom in linux with cmake

Post by GuntherDW »

the latest svn version is compileable without too much of a hassle, it just still checks for the snes dir, and you'll have to edit the linker flags to include the new GME folder.
You'll also have to tell the linker to use the bzip2 lib and iirc there is one file in the dumb lib that needs to be edited to be able to compile with gcc 4.3

I'll provide a small patch in a minute for this.

edit: as promised, patching the CMAKE files seems almost too easy
(i had to define _WIN32 though in the dumb project for that particular file, because it (gcc 4.3) was tripping over that particular line)
Attachments
gzdoom.r351.patch.zip
only a line or 3 needed to be patched in total!
(684 Bytes) Downloaded 124 times
Top
User avatar
Rachael
Developer
Developer
Posts: 3651
Joined: Sat May 13, 2006 10:30

Re: Building gzdoom in linux with cmake

Post by Rachael »

I hate to say it, but defining a system-specific macro such as that seems like a very bad idea to me - it's very hacky, and even if it pertains to only one particular project out of the many that have to compile, it just seems like a clusterfuck waiting to happen. Let's put it this way - not all hacky solutions are ideal. Fixing that one line that it's tripping over that requires the Win32 def seems much more ideal, even though doing so does not modify the CMakeLists.txt file.
Top
User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:
Contact GuntherDW

Re: Building gzdoom in linux with cmake

Post by GuntherDW »

SoulPriestess wrote:I hate to say it, but defining a system-specific macro such as that seems like a very bad idea to me - it's very hacky, and even if it pertains to only one particular project out of the many that have to compile, it just seems like a clusterfuck waiting to happen. Let's put it this way - not all hacky solutions are ideal. Fixing that one line that it's tripping over that requires the Win32 def seems much more ideal, even though doing so does not modify the CMakeLists.txt file.
that was my original fix, but that would mean that if graf were to update the dumb source files, that that fix might go lost/forgotten/... until someone picks it up again
besides, is cmake being used on windows?
Top
User avatar
Super Jamie
Posts: 6
Joined: Mon Jun 25, 2007 11:39
Location: Brisbane, Australia
Contact:
Contact Super Jamie

Re: Building gzdoom in linux with cmake

Post by Super Jamie »

Graf Zahl wrote:If you want to help, please use the SVN trunk
Of course. r351 I posted the output from is the current trunk :)

Remote or virtualised would probably only be reliable for testing compiles on. I know VirtualBox can pass limited OpenGL-only support to its' guests, but gameplay performance would probably be abysmal. I'm not sure of what GL extensions are/aren't provided (the docs aren't very clear as to how this works, maybe it passes all host extensions, maybe not) so effectiveness of testing new GL features could be limited, especially with the idea to move to OGL2.0 and SM2.0 exclusively. I'm happy to play around with this if more info (supported exts on different host/guest OSes and hardware, performance, etc) would be helpful?

Thanks heaps for the patch, will give it a try tonight.
Top
User avatar
Rachael
Developer
Developer
Posts: 3651
Joined: Sat May 13, 2006 10:30

Re: Building gzdoom in linux with cmake

Post by Rachael »

GuntherDW wrote:besides, is cmake being used on windows?
What is relevant here isn't whether or not CMake is being used on Windows - and the answer is usually no, anyhow, unless you're using an alternate compiler -

The issue at hand is that now the Dumb project thinks its on both Linux and Windows. Believe it or not, those definitions are system specific for a reason - and they should stay that way.

If the fix gets lost or forgotten, it can be reapplied later on.

The point here is: We never do a hacky solution if a different solution that's more viable is available, and in this case, it is. Especially system variables.
Top
User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:
Contact GuntherDW

Re: Building gzdoom in linux with cmake

Post by GuntherDW »

SoulPriestess wrote:
GuntherDW wrote:besides, is cmake being used on windows?
What is relevant here isn't whether or not CMake is being used on Windows - and the answer is usually no, anyhow, unless you're using an alternate compiler -

The issue at hand is that now the Dumb project thinks its on both Linux and Windows. Believe it or not, those definitions are system specific for a reason - and they should stay that way.

If the fix gets lost or forgotten, it can be reapplied later on.

The point here is: We never do a hacky solution if a different solution that's more viable is available, and in this case, it is. Especially system variables.
Have you even looked at the patch and the line of code?
it's because the code specifies a function called log2, but gcc 4.3 seems to have this function built-in already,
and because of the "if !defined(_WIN32) || .." command it "runs" that single line, it seems gcc doesn't like the OR there, or interprets it as an AND (?)

will it be better if i just modify dumb itself, and when graf decides to update the source code, that that fix, which might still be required to compile on linux, is gone?

Fine, i'll modify the source and post it (along with the fix to the age-old 2x video init + mouse cursor on screen bug as well according my post in the bug forum)
the only thing that's actually needed is to spread it out on 2 lines in stead of 1
Attachments
gzdoom.r351.v3.patch.zip
(925 Bytes) Downloaded 122 times
Top
User avatar
Rachael
Developer
Developer
Posts: 3651
Joined: Sat May 13, 2006 10:30

Re: Building gzdoom in linux with cmake

Post by Rachael »

Sorry I don't mean to seem such an ass about it. Yes, modifying the source would be better.
Top
User avatar
Super Jamie
Posts: 6
Joined: Mon Jun 25, 2007 11:39
Location: Brisbane, Australia
Contact:
Contact Super Jamie

Re: Building gzdoom in linux with cmake

Post by Super Jamie »

r352 with the above v3 patch compiles and runs great, however when I go to quit, I get a crash and freeze.
http://i113.photobucket.com/albums/n232 ... 2-quit.png
I've sat for several minutes, but it never seems to write more to zdoom-crash.log than:

Code: Select all

superjamie@one:~$ cat zdoom-crash.log 
*** Fatal Error ***
Address not mapped to object (signal 11)
Address: 0x1

System: Linux one 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux
GCC version: 4.3.3
A task manager shows I have two gzdoom processes running, one (the numbered one in the console) is in "futex_wait", the other (with a PID always incremented by 4) sits in "do_wait". Killing the second process does nothing. I can either kill the first process, or ctrl+c in my terminal. If I'm fullscreen I am able to alt+tab to the console to do that. A config file is not written to ~/.gzdoom/zdoom.ini, though the ~/.gzdoom folder is created.

Skulltag displays the same freeze-on-quit behaviour for me, though I haven't checked all the process stuff. ZDoom stable 2.3.1 r1480 exits properly, as does ZDoom trunk r1673.

Edit: If I copy my working zdoom.ini to ~/.gzdoom, run the game, then try and quit, I get this output:
Spoiler:
Also, if I run GZdoom fullscreen at say 800x600, and I normally run my desktop at 1920x1200, I'm left at 800x600 when it crashes.
Top
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:
Contact Graf Zahl

Re: Building gzdoom in linux with cmake

Post by Graf Zahl »

The patch does not work under Windows. What's the change in itrender.c about? When compiling with VC++ I get errors now.

In this case I think renaming the function and removing the #ifdefs sounds better, even though it skips the system provided function on GCC.
Top
User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:
Contact GuntherDW

Re: Building gzdoom in linux with cmake

Post by GuntherDW »

Super Jamie wrote:r352 with the above v3 patch compiles and runs great, however when I go to quit, I get a crash and freeze.
http://i113.photobucket.com/albums/n232 ... 2-quit.png
I've sat for several minutes, but it never seems to write more to zdoom-crash.log than:
...
that's because of your ATI card, the only pc i've got with an ATi card is my laptop, and i haven't really debugged on that machine yet so i can't help you (yet).
I do however (sometimes) have the same problems.

Graf, the only change in itrender it the removal of the || on line ~3558, and expanding it onto 2 lines
when i leave it in 1 line gcc 4.3 moans and tries to compile that code, but it's a function GCC already has so it errors out
Top
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:
Contact Graf Zahl

Re: Building gzdoom in linux with cmake

Post by Graf Zahl »

Yes, but your change effectively changes the || to && so it didn't compile properly under Windows anymore.

The easiest way to address this seemed to rename the function to remove the name collision.
Top
User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:
Contact GuntherDW

Re: Building gzdoom in linux with cmake

Post by GuntherDW »

Graf, you changed the setmodeneeded from false to true,
which inherits this "2x video init, and mouse pointer on screen bug"

Now that my finals are over I think i'll start looking into linux ATi support, if you don't mind?

also, my GCC seems to have problems with the "src/gl/old_renderer/gl1_sprite.cpp" file,
more precisely if you leave the extern TArray<PalEntry> BloodTranslationColors; on line ~630 LD (gnu's linker) doesn't find that BloodTranslationColors and whoops out

Code: Select all

Linking CXX executable ../gzdoom
CMakeFiles/zdoom.dir/tempfiles.o: In function `FTempFileName::FTempFileName(char const*)':
tempfiles.cpp:(.text+0x96): warning: the use of `tempnam' is dangerous, better use `mkstemp'
CMakeFiles/zdoom.dir/gl/old_renderer/gl1_sprite.o: In function `GLRendererOld::GLSprite::Process(AActor*, sector_t*)':
gl1_sprite.cpp:(.text+0x1bed): undefined reference to `GLRendererOld::BloodTranslationColors'
collect2: ld returned 1 exit status
make[2]: *** [gzdoom] Error 1
make[1]: *** [src/CMakeFiles/zdoom.dir/all] Error 2
make: *** [all] Error 2
making that variable a global variable seemed to fix it, altouhg it's a little too overboard i think
Attachments
gzdoom.r359.v1.patch.zip
(729 Bytes) Downloaded 135 times
Top
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:
Contact Graf Zahl

Re: Building gzdoom in linux with cmake

Post by Graf Zahl »

Won't fix yet. I am currently doing a complete reorganization of the GL code so over the next few days you have to live with occasional problems.
Top
User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:
Contact GuntherDW

Re: Building gzdoom in linux with cmake

Post by GuntherDW »

It also seems that an old friend has sprung up again,
do you remember that i was talking about strange "freezes" that almost happen at random and dissapear as random as they came?

they've started occuring again, but i never quite seem to get a nice fixed testbed :(

I'll do whatever i can to try to make it as clear as possible.
Top
Locked

Return to “GZDoom”