Problems compiling from Source

[Cmd. Cheyd]

At this point Ean - from the Oolite board - reports that
I had to add /Local/include to the include search path - dunno why but it works now.

There's no explanation on how to tell if this is still required, or how to do it... So, ummm..... ??????

11. Now you need to rename oolite.debug and copy dll files around. Ean has provided a fixwin shell script to do that automatically. An updated - and hopefully problem free - version of that script is inside this zip file [2]. Once extracted, put the file in C:\GNUstep\Local\oolite\trunk\

If everything goes well, these are the last two lines you need to type to get the compiled oolite to run:

1. fixwin
2. openapp oolite.app
If you have a problem running fixwin, do the following instead:

12. Still inside the GNUstep shell, type mv oolite.debug oolite.app

fixwin
"No Resources to move. Exiting..."

openapp oolite.app
"Could not fine /Local/oolite/trunk/oolite.app/oolite.exe executable/script

mv oolite.debug oolite.app
"mv: cannot stat 'oolite.debug': No such file or directory


I DO have an oolite.app folder, and inside is an oolite.dbg.exe however...?

[Kaks]

It looks like things have moved around somewhat from the good old days. From what you're saying you probably need to rename oolite.dbg.exe to oolite.exe

After that, typing openapp oolite.app from inside gnustep should hopefully start the compiled program... which might well complain about wrong dlls!

hope this helps...

[another_commander]

Not sure what version of GNUstep you are running, but the newer versions (post 1.13.x) build debug by default. To make it correspond to the wiki instructions, try executing a make debug=no instead of just make.

[Kaks]

I've just rebuilt my PC development environment, and I spent a while trying to find an up-to-date Local.zip file. Then I noticed there's no more need to move files around after compiling.
And now that I've got myself a nice 1-click-to-compile setup I wanted to share!

Here's a recap of what I did. I'm putting it here until we're able to update the wiki again...
Edit:(Feb 2010) recent sources shouldn't need local.zip anymore, so I'm crossing out the local.zip bits!

got tortoiseSVN from sourceforge:
http://sourceforge.net/project/showfile ... _id=138498

got the 2 gnustep packages:
http://ftpmain.gnustep.org/pub/gnustep/ ... -setup.exe

http://ftpmain.gnustep.org/pub/gnustep/ ... -setup.exe

got a recent copy of local.zip
ftp://ftp.alioth.net/oolite/Local_20090108.zip

installed gnustep-system-0.19.2 first, then gnustep-core-0.19.2

installed tortoiseSVN, restarted the computer.

After restarting, started gnustep:
Start>Programs>GNUstep>Shell

at the shell's command prompt I entered these 3 lines in rapid succession

mkdir /Local
mkdir /Local/oolite
mkdir /Local/oolite/trunk

I'm just going to use gnustep to compile oolite, so I customised it to compile oolite every single time I start gnustep. That's how I did it: first I closed gnustep, then - from windows - I found the file
C:\GNUstep\etc\profile
clicked on it, then opened in wordpad.
Added the following lines at the bottom of the file

export PATH=$PATH:/Local/bin
cd /Local/oolite/trunk
make debug=no

then saved the file & exited wordpad

extracted Local_20090108.zip, and copied its contents to C:\Gnustep\Local

finally I went to C:\Gnustep\Local\oolite\trunk
Right clicked on the empty directory then chose SVN checkout from the menu. The repository is svn://svn.berlios.de/oolite-linux/trunk . Waited for it to finish.

restarted gnustep:
Start>Programs>GNUstep>Shell

everything was in the right place, compile started immediately.
Compile finished with no problems, I typed

openapp oolite.app

bingo. A brand new oolite!

Edit: it should work, but I haven't tested it without local.zip

[Screet]

Hi,

I finally managed to build oolite from trunk. Sadly, I first had the older gnustep-syste-0.19.1 installed, as the wiki said, before I found this one here. I ran into a problem and then found that this thread suggests to use the newer version, thus I uninstalled the gnustep system and core and then installed the 0.19.2 versions.

However, that did not fix my problem. Everytime I try to start oolite, I get the error message that the dll entry point for "__objc_class_name_NXConstantString" cannot be found in the DLL "gnustep-base-1_15.dll".

Any suggestions as what might have gone wrong? This sounds to me as if I still have an older dll version than necessary. Do I need a newer local-zip than mentioned above? If so, where to find it?

Screet

[another_commander]

I think you are right about an older gnustep-base dll being queried at startup. It could be that the uninstall of 0.19.1 did not go as planned. I would recommend fully purging gnustep from your system and attempting a reinstall of 0.19.2. After doing that, try to launch MSYS and use the set command to see what paths are set for gnustep and make sure that they all refer to the correct locations of your installation. Check also for any gnustep-base*.dll in your system, in case an older copy ended up somewhere where it does not belong. You should only have gnustep-base-1_15.dll in your system.

I am sure you have already thought of this, but I mention it just in case: could it be a problem with Vista's virtualization? I hope you have avoided Program Files and such, right?

Hope this helps a bit. Very soon, I will package and upload a stripped down version of my development environment, which will basically allow for a pretty simple and straightforward install-compile-play process, giving the opportunity to build from source for anyone interested.

[Micha]

Hi Screet,

Unfortunately I don't currently have a working Windows environment to test things and make sure it still works, but when I did I added a 'Makefile' in addition to the GNUmakefile to the project which made compiling a bit easier.

To use it:
make -f Makefile [debug | release]

That should also copy all the necessary DLLs into the build directory for you.

You can also use it to build a Windows Installer for Oolite:
make -f Makefile pkg-win

Hope this helps,
- Micha.

[another_commander]

Unfortunately I don't currently have a working Windows environment to test things and make sure it still works, but when I did I added a 'Makefile' in addition to the GNUmakefile to the project which made compiling a bit easier.

To use it:
make -f Makefile [debug | release]

That should also copy all the necessary DLLs into the build directory for you.

You can also use it to build a Windows Installer for Oolite:
make -f Makefile pkg-win

I can confirm that this still works beautifully and, in fact, this is what is going to be used for creating the next release installer when the right time comes.

[Screet]

After doing that, try to launch MSYS and use the set command to see what paths are set for gnustep and make sure that they all refer to the correct locations of your installation. Check also for any gnustep-base*.dll in your system, in case an older copy ended up somewhere where it does not belong. You should only have gnustep-base-1_15.dll in your system.

Turns out that the versions are all the same (including the one from svn) except one to be found in GNUstep\GNUstep\system which is three times larger. That one allows to launch without that error message, however, after a first splash-screen I only had a blacked Oolite v(nil) window with nothing to happen anymore.

I then tried both the larger dll and the oolite.exe from the oolite installation folder....it went fullscreen but did exit very soon without any logs written.

I am sure you have already thought of this, but I mention it just in case: could it be a problem with Vista's virtualization? I hope you have avoided Program Files and such, right?

GNUstep doesn't install itself to program files, thus it's safe from that problem

Screet

[Kaks]

Screet, you might have the wrong files inside c:\Gnustep\Local\

Try removing all the files from inside that directory & use the ones inside Local_20090108.zip instead, and recompile...
edit: keep the oolite directory, that should be fine regardless!
Does that help?

[another_commander]

Turns out that the versions are all the same (including the one from svn) except one to be found in GNUstep\GNUstep\system which is three times larger. That one allows to launch without that error message, however, after a first splash-screen I only had a blacked Oolite v(nil) window with nothing to happen anymore.

If you have a v(nil) on the game's title bar, then you are almost there. What happens is that the distributed Oolite is using a modified gnustep-base-1_15.dll, which does not do DTD validation. Obviously you are using the vanilla gnustep-base - which wants to validate DTDs - and this is why you can't run the game.

To fix this: In your SVN checkout, there is a folder called DTDs. It is located in deps\Cross-platform-deps. Copy this folder under oolite.app\GNUstep and you should be able to run the game. Also note that as of 1.73, we do not use any RunOolite.bat file to start the game. You now start by doubleclicking the executable directly.

[Screet]

Screet, you might have the wrong files inside c:\Gnustep\Local\

Try removing all the files from inside that directory & use the ones inside Local_20090108.zip instead, and recompile...
edit: keep the oolite directory, that should be fine regardless!
Does that help?

No...I did first install the older local from the wiki and then replaced the files by those from the newer local...and after reading your message, I deleted all those folders except the oolite one and only used the newer locals contents, but it didn't change anything.

The local files don't contain the dll which causes the problem.

Screet

[Screet]

If you have a v(nil) on the game's title bar, then you are almost there. What happens is that the distributed Oolite is using a modified gnustep-base-1_15.dll, which does not do DTD validation. Obviously you are using the vanilla gnustep-base - which wants to validate DTDs - and this is why you can't run the game.

To fix this: In your SVN checkout, there is a folder called DTDs. It is located in deps\Cross-platform-deps. Copy this folder under oolite.app\GNUstep and you should be able to run the game. Also note that as of 1.73, we do not use any RunOolite.bat file to start the game. You now start by doubleclicking the executable directly.

I first tried with the DTD file added to the oolite.app from the real installation and using the newer .exe and the larger dll there...however, the log and stderr were full of error messages and it did not help.

I then tried the DTD file in the GNUstep oolite.app dir - now it reads Oolite v.173 together with the current date, however the screen does stay black and the app doesn't respond.

stderr:

Code: Select all

.:3: validity error : Validation failed: no DTD found !
<plist version="1.0">
                    ^

log:

Code: Select all

[gnustep]: 2009-03-28 17:24:30.355 oolite[5400] unable to find GNUstep DTD - 'plist-0_9' for '-//Apple Computer//DTD PLIST 1.0//EN'

[log.header]: Opening log for Oolite version 1.73 (x86-32 test release) under Windows at 2009-03-28 17:24:30 +0000.
4 processors detected.
Oolite Options: [Procedural Planets] [Docking Clearance]

Note that the contents of the log file can be adjusted by editing logcontrol.plist.

[joystickHandler.init]: Number of joysticks detected: 1
[dataCache.rebuild]: Data cache version (1.72.2) does not match Oolite version (1.73), rebuilding cache.
[searchPaths.dumpAll]: ---> OXP search paths:
(Resources, ../AddOns)
[display.mode.list.native]: Windows native resolution detected: 1280 x 1024
[rendering.opengl.version]: OpenGL renderer version: 3.0.0 ("3.0.0")
Vendor: NVIDIA Corporation
Renderer: GeForce GTX 295/PCI/SSE2/3DNOW!
[rendering.opengl.extensions]: OpenGL extensions (159):
GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_framebuffer_object GL_ARB_geometry_shader4 GL_ARB_imaging GL_ARB_map_buffer_range GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_buffer_object GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add 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_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_bindable_uniform GL_EXT_depth_bounds_test GL_EXT_direct_state_access GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXTX_framebuffer_mixed_formats GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_buffer_object GL_EXT_texture_compression_latc GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_texture_swizzle GL_EXT_texture_shared_exponent GL_EXT_timer_query GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_buffer_float GL_NV_conditional_render GL_NV_depth_clamp GL_NV_explicit_multisample GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_geometry_shader4 GL_NV_gpu_program4 GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_coverage GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_parameter_buffer_object GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_transform_feedback GL_NV_transform_feedback2 GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_WIN_swap_hint WGL_EXT_swap_control 
[shipData.load.begin]: Loading ship data...
  [gnustep]: 2009-03-28 17:24:31.924 oolite[5400] unable to find GNUstep DTD - 'plist-0_9' for '-//GNUstep//DTD plist 0.9//EN'

  [gnustep]: 2009-03-28 17:24:32.047 oolite[5400] don't know how to load entity 'http://www.gnustep.org/plist-0_9.xml' id '-//GNUstep//DTD plist 0.9//EN'

[gnustep]: 2009-03-28 17:24:32.084 oolite[5400] unable to find GNUstep DTD - 'plist-0_9' for '-//GNUstep//DTD plist 0.9//EN'

Screet

[another_commander]

The entire DTDs folder should be under oolite.app\GNUstep, or wherever the Defaults and Library folders are in your system. You must put the entire folder containing the DTD files there, not just one file. From your log it is obvious that it still does not find the DTD it is looking for.

Also what do you mean when you say "real installation"? You did not try to put the 1.73 exe inside the 1.72.2 installation, by any chance? This would be a big no-no, as the datafiles are almost completely incompatible between these two versions and a crash would be the best case scenario.
[Edit]: Looks like that is exactly what you did.

[Screet]

The entire DTDs folder should be under oolite.app\GNUstep, or wherever the Defaults and Library folders are in your system. You must put the entire folder containing the DTD files there, not just one file. From your log it is obvious that it still does not find the DTD it is looking for.

Yes, it looks like that, however the folder is there with it's contents. That doesn't help. If I also copy it to the oolite.app folder directly, I get rid of the (nil) thing, but have those errors written to stderr and log.

Also what do you mean when you say "real installation"? You did not try to put the 1.73 exe inside the 1.72.2 installation, by any chance? This would be a big no-no, as the datafiles are almost completely incompatible between these two versions and a crash would be the best case scenario.

I tried both, from the oolite trunk folder and from the installation folder - with the same results.

Screet