Trying to compile GZDoom with Linux

Daniele C. · Post by **Daniele C.** » Mon Oct 22, 2007 8:26

Costja wrote:Are any changes required to run ZDoom on your system? IMHO, ZDoom supports Linux more "cleanly", so its better to patch it first.

ZDoom compiled without any issue (even if the executable hanged up my system...)

AFAIK configure script in gzdoom archive is not working. i compile GZDoom on my system without configuring it (after applying two latest patches from this thread). Makefile.linux is included from the makefile.

Ok, I applied patch27.zip and then moved platform.h into src/, it seems working now

@Graf: any chance you will register a SF.net project and use SVN there?

It would help mantaining working revisions of the code

Daniele C. · Post by **Daniele C.** » Mon Oct 22, 2007 8:38

AFAIK configure script in gzdoom archive is not working. i compile GZDoom on my system without configuring it (after applying two latest patches from this thread). Makefile.linux is included from the makefile.
Ok, I applied patch27.zip and then moved platform.h into src/, it seems working now

Nope, it failed to compile hardware.o because of source not specified...
I then applied patch27L.zip but result didn't change

Code: Select all

g++ -c -pipe -Wall -Wno-unused -O2 -fomit-frame-pointer `pkg-config gtk+-2.0 --cflags` -DHAVE_FILELENGTH -D__forceinline=inline `sdl-config --cflags` -Dstricmp=strcasecmp -Dstrnicmp=strncasecmp -DNEED_STRUPR -Isrc/ -Isrc/g_doom/ -Isrc/g_heretic/ -Isrc/g_hexen/ -Isrc/g_raven/ -Isrc/g_shared/ -Isrc/g_strife/ -Isrc/oplsynth/ -Isrc/sound/ -Isrc/fragglescript/ -Isrc/thingdef/ -Isrc/Linux/ -Isrc/sdl/ -Isrc/gl/ -Isrc/gl/r_render/ -Isrc/textures/ -DUSEASM=1 -DNDEBUG -o releaseobj/hardware.o -c 
g++: no input files

Daniele C. · Post by **Daniele C.** » Mon Oct 22, 2007 9:40

I manually compiled objects for the following source files:

Code: Select all

src/sdl/hardware.cpp
src/sdl/sdlglvideo.cpp
src/gl/a_dynlight.cpp

And now I could successfully compile the gzdoom binary

Edit: gzdoom does not start:

Code: Select all

GZDoom v1.0.27 - 2.1.7xx - SVN revision 553 - SDL version
Compiled on Oct 22 2007

M_LoadDefaults: Load system defaults.
W_Init: Init WADfiles.
 adding /home/tarogen/games/gzdoom/gzdoom.pk3
 adding ./doom2.wad (2919 lumps)
I_Init: Setting up machine state.
CPU Speed: ~1600.310697 MHz
CPU Vendor ID: GenuineIntel
  Name: Intel(R) Pentium(R) M processor 1600MHz 1600MHz
  Family 6, Model 9, Stepping 5
  Features: MMX SSE SSE2
I_InitSound: Initializing FMOD
  Setting OSS (Open Sound System) output succeeded
  Setting driver 0 succeeded
  Initialization succeeded
V_Init: allocate screen.
S_Init: Setting up sound.
ST_Init: Init startup screen.
P_Init: Checking cmd-line parameters...
G_ParseMapInfo: Load map definitions.
S_InitData: Load sound definitions.
LoadDecorations: Load external actors.
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init miscellaneous info.
P_Init: Init Playloop state.
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)
GL_VENDOR: Tungsten Graphics, Inc
GL_RENDERER: Mesa DRI Intel(R) 852GM/855GM 20061017 x86/MMX/SSE2
GL_VERSION: 1.3 Mesa 6.5.2
GL_EXTENSIONS: GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_point_parameters GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_cull_vertex GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_histogram GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_3DFX_texture_compression_FXT1 GL_APPLE_client_storage GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_NV_vertex_program1_1 GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SUN_multi_draw_arrays
Resolution: 640 x 480
gzdoom: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
DRM_I830_CMDBUFFER: -22
DRM_I830_CMDBUFFER: -22

What can it be? I have attached my xorg.conf

Post by **Gez** » Mon Oct 22, 2007 17:10

Daniele C. wrote:@Graf: any chance you will register a SF.net project and use SVN there? It would help mantaining working revisions of the code

If SF means Sourceforge, no, it's not possible, for the same reason ZDoom isn't on SVN.

Sourceforge's terms of services include this:

8. LICENSING AND OTHER TERMS APPLYING TO CODE AND OTHER CONTENT POSTED ON SOURCEFORGE.NET

SourceForge.net fosters software development and content creation under Open-Source Initiative ("OSI")-approved licenses or other arrangements relating to software and/or content development that may be approved by COMPANY. For more information about OSI, and OSI-approved licenses, visit http://www.opensource.org.

Use, reproduction, modification, and ownership of intellectual property rights to data stored in CVS, SVN or as a file release and posted by any user on SourceForge.net ("Source Code") shall be governed by and subject to the OSI-approved license, or to such other licensing arrangements approved by COMPANY, applicable to such Source Code.

Content located on any SourceForge.net-hosted subdomain which is subject to the sole editorial control of the owner or licensee of such subdomain, shall be subject to the OSI-approved license, or to such other licensing arrangements that may be approved by COMPANY, applicable to such Content.

The OSI-approved licenses are there. There's no point in copy/pasting the entire list, which is quite long; suffice to say the Doom source license (under which ZDoom and derived ports are released) is not among them.

"What if (G)ZDoom changed license and became, for example, GPL?" No can do. ZDoom uses a lot of Heretic and Hexen code, and they aren't GPL'ed. Therefore, Randy and Graf aren't allowed to change to a more open license as long as this code is there. Given how fundamental the Hexen map format (for example) has become, and how nobody wishes to lose Heretic and Hexen support, this is out of question.

(There would also be the question of closed-source derived ports like Skulltag, but with dual-licensing -- releasing ZDoom under both the old license and the new -- it wouldn't be a problem.)

Daniele C. · Post by **Daniele C.** » Mon Oct 22, 2007 19:12

Gez wrote:
Daniele C. wrote:@Graf: any chance you will register a SF.net project and use SVN there? It would help mantaining working revisions of the code
If SF means Sourceforge, no, it's not possible, for the same reason ZDoom isn't on SVN.

[...]

The OSI-approved licenses are there. There's no point in copy/pasting the entire list, which is quite long; suffice to say the Doom source license (under which ZDoom and derived ports are released) is not among them.

As far as I knew, the original Doom source code was released also under GPL. I didn't know about the Raven's licensing issue.
ZDoom is also on SF.net at http://sourceforge.net/projects/zdoom

"What if (G)ZDoom changed license and became, for example, GPL?" No can do. ZDoom uses a lot of Heretic and Hexen code, and they aren't GPL'ed. Therefore, Randy and Graf aren't allowed to change to a more open license as long as this code is there. Given how fundamental the Hexen map format (for example) has become, and how nobody wishes to lose Heretic and Hexen support, this is out of question.

(There would also be the question of closed-source derived ports like Skulltag, but with dual-licensing -- releasing ZDoom under both the old license and the new -- it wouldn't be a problem.)

It could be possible to have the non-GPL code in separate modules - and distribute them second their license.

I don't know how much technically feasible that would be - but separate modules for non-GPL code would be an excellent deal in my opinion.

Post by **Gez** » Mon Oct 22, 2007 19:51

Daniele C. wrote:As far as I knew, the original Doom source code was released also under GPL.

It has been released under the GPL later. (It's an example of dual-licensing.) See here. (Where we also learn that ZDoom is actually under the BSD license?)

As for the ZDoom SF site has been abandoned for this reason, IIRC. I recall on the ZDoom forums a post by Randy expressing surprise upon learning his SF account was still there...

Daniele C. · Post by **Daniele C.** » Mon Oct 22, 2007 20:44

Gez wrote:
Daniele C. wrote:As far as I knew, the original Doom source code was released also under GPL.
It has been released under the GPL later. (It's an example of dual-licensing.) See here. (Where we also learn that ZDoom is actually under the BSD license?)

I am pretty sure that most of ZDoom code is under BSD or GPL, while some parts - if derived from Hexen/Heretic code - must be under the originary license. But let's do not forget that GPL is an exclusive license vs non-free licenses, so a modularization of non GPL/BSD code might be necessary for the health - current and future - of ZDoom copyright

As for the ZDoom SF site has been abandoned for this reason, IIRC. I recall on the ZDoom forums a post by Randy expressing surprise upon learning his SF account was still there...

SourceForge.net projects are kept forever in order to not waste the open source contributes. If there's something released under a wrong license on SF.net, and only in that case, the project mantainer should ask them to discontinue the downloads and the project.

Post by **Graf Zahl** » Tue Oct 23, 2007 9:27

ZDoom doesn't contain any GPL code.

GZDoom does (the FraggleScript parser). but I got permission from the author to use that.

Daniele C. · Post by **Daniele C.** » Tue Oct 23, 2007 10:01

Graf Zahl wrote:ZDoom doesn't contain any GPL code.

GZDoom does (the FraggleScript parser). but I got permission from the author to use that.

Thanks for the precisation!

To get back on topic: would it be possible to register the project somewhere else (Google Code?) ?

I mean: is this an open source project? Because looks like it was... (no pun intended)

Daniele C. · Post by **Daniele C.** » Tue Oct 23, 2007 17:25

Daniele C. wrote:I manually compiled objects for the following source files:
Code: Select all
src/sdl/hardware.cpp
src/sdl/sdlglvideo.cpp
src/gl/a_dynlight.cpp
And now I could successfully compile the gzdoom binary

If I compile through

Code: Select all

make DEBUG=1

the above files get compiled correctly. Can somebody please fix the Makefile.linux?

Edit: gzdoom does not start:

Code: Select all

[...]
Resolution: 640 x 480
gzdoom: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
DRM_I830_CMDBUFFER: -22
DRM_I830_CMDBUFFER: -22

I have googled around and seems like a hardware acceleration issue, I will further investigate since when I run gzdoom or gzdoomd my notebook crashes and I will have to reboot it using ssh

The more I read about GZDoom, the more enthusiast I am about it!
I would really like it to be the best Doom source port working on linux - and I hope I can contribute for this goal

P.S. I can also compile it on WindowsXP with gcc, so I will eventually test the patches on Windows XP, Gentoo, Ubuntu (Debian) before committing...but...where? There is no public repository for GZDoom, as far as I know, and of course I don't have yet any formal authorization to work on it (and I don't have yet anything to commit, too).

I would really like to work side by side with other linux developers/users like Costja

Thanks

Daniele C. · Post by **Daniele C.** » Tue Oct 23, 2007 17:28

Graf Zahl wrote:GZDoom does (the FraggleScript parser). but I got permission from the author to use that.

It would be great to implement other ports' features through the same approach, and maybe we could ask to the authors to dual-license them with LGPL (for the code modularization I was trolling about previously), but I guess that Graf Zahl

has already tried this for the features which are part of GZDoom or are planned to be part of.

Post by **Graf Zahl** » Tue Oct 23, 2007 17:50

The GL renderer is already dually licensed (BSD for use in GZDoom, LGPL elsewhere), as is the DECORATE parser (again BSD for ZDoom but GPL elsewhere. But that's all the code I control myself. Since most of Randy's code is BSD and that is compatible with GPL it's not an issue for me. The problem comes with the Raven code and the Build stuff in the software renderer. I also don't care too much about the smaller modules I added. I think BSD is ok for them generally.

If Raven decided to re-release their code as GPL I'd rip out the few parts that are incompatible with it (software renderer and OPL music playback) - but that's a very big 'if'.

Daniele C. · Post by **Daniele C.** » Tue Oct 23, 2007 18:34

Daniele C. wrote:
Daniele C. wrote:I manually compiled objects for the following source files:
Code: Select all
src/sdl/hardware.cpp
src/sdl/sdlglvideo.cpp
src/gl/a_dynlight.cpp
And now I could successfully compile the gzdoom binary
If I compile through
Code: Select all
make DEBUG=1
the above files get compiled correctly. Can somebody please fix the Makefile.linux?

I ended up fixing it myself.

Here is a cumulative patch to be applied over the current GZDoom 1.0.27 which fixes everything up to now (Costja's re-diffed patch27.zip + my patch and also patch27L which fixes the libFLAC crashing).

Edit: see latest post for attachment

Daniele C. · Post by **Daniele C.** » Tue Oct 23, 2007 18:48

Graf Zahl wrote:The GL renderer is already dually licensed (BSD for use in GZDoom, LGPL elsewhere), as is the DECORATE parser (again BSD for ZDoom but GPL elsewhere. But that's all the code I control myself. Since most of Randy's code is BSD and that is compatible with GPL it's not an issue for me. The problem comes with the Raven code and the Build stuff in the software renderer. I also don't care too much about the smaller modules I added. I think BSD is ok for them generally.

I am also preferring more BSD over GPL in my most recent projects; BSD is a super-set of GPL when talking about freedom.

If Raven decided to re-release their code as GPL I'd rip out the few parts that are incompatible with it (software renderer and OPL music playback) - but that's a very big 'if'.

I see, that's because of the GPL viral nature.

I have also heard that timmy is going to use GZDoom for his next ZDoomGL - one more proof of GZDoom's goodness! I will personally stick to GZDoom as I plan to make it run with the best performance reachable on my linux boxes

Daniele C. · Post by **Daniele C.** » Wed Oct 24, 2007 0:39

I have now merged patch27L.zip into the cumulative patch.

It is needed because libFLAC also crashes netplay, even if -nomusic is specified