Subject:
|
Unable to compile LDGLite 1.0.7 from Source on SuSe Linux
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Sat, 27 May 2006 16:42:59 GMT
|
Viewed:
|
2713 times
|
| |
|
|
Having downloaded and unzipped the 1.0.7 source from SourceForge (and having had
similar errors trying the version recommended on the LDraw getting started
guide), I am having difficulty getting it to build.
At first, when I was building, it was complaining about a redefinition of the
implicit declaration of the ”translate_color” function, which I have remedied
by moving the one explicit declaration (with the extern) up to the top of the
main.c file.
It is now complaining of syntax errors in the osmesa.h file:
gcc -g -DUNIX -DUSE_OPENGL -DUSE_L3_PARSER -DUSE_BMP8 -DNEED_MIN_MAX
-DUSE_PNG -DTILE_RENDER_OPTION -DOSMESA_OPTION -DTEST_MUI_GUI
-I./mui/include -c -o ldglpr.o ldglpr.c
In file included from ldglpr.c:52:
/usr/include/GL/osmesa.h:120: error: syntax error before ‘OSMesaCreateContext’
/usr/include/GL/osmesa.h:133: error: syntax error before ‘OSMesaCreateContextExt’
/usr/include/GL/osmesa.h:143: error: syntax error before ‘OSMesaDestroyContext’
/usr/include/GL/osmesa.h:175: error: syntax error before ‘OSMesaMakeCurrent’
/usr/include/GL/osmesa.h:185: error: syntax error before ‘OSMesaGetCurrentContext’
/usr/include/GL/osmesa.h:203: error: syntax error before ‘OSMesaPixelStore’
/usr/include/GL/osmesa.h:219: error: syntax error before ‘OSMesaGetIntegerv’
/usr/include/GL/osmesa.h:234: error: syntax error before ‘OSMesaGetDepthBuffer’
/usr/include/GL/osmesa.h:250: error: syntax error before ‘OSMesaGetColorBuffer’
/usr/include/GL/osmesa.h:261: error: syntax error before ‘OSMesaGetProcAddress’
|
|
My compiler, and osmesa details:
$ gcc --version
gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,f95,java,ada --disable-checking
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk
--disable-libjava-multilib --with-slibdir=/lib --with-system-zlib
--enable-shared --enable-__cxa_atexit --without-system-libunwind
--host=i586-suse-linux
Thread model: posix
$ rpm -q --file /usr/include/GL/osmesa.h
xorg-x11-Mesa-devel-6.8.2-100
$ uname -a
Linux orion 2.6.13-15.8-default #1 Tue Feb 7 11:07:24 UTC 2006 i686
athlon i386 GNU/Linux
|
|
What is annoying is that the version of GCC states it is a “prerelease”, and yet
is actually the only one available from Yast (the SuSe package management).
I note that I can find the macro for GLAPI, but not GLAPIENTRY (although there
is one APIENTRY) in gl.h. Since it is this area in the osmesa.h that the
compiler is erroring out on, it may be unlikely to actually be a problem with
the compiler itself, and maybe to do with the xorg mesa devel package having a
broken gl.h or osmesa.h (I would define referring to a non-existant macro as
broken).
So I did some further investigation:
rpm -V --file /usr/include/GL/gl.h
S.5....T /usr/include/GL/gl.h
S.5....T /usr/include/GL/glext.h
S.5....T /usr/include/GL/glx.h
S.5....T /usr/include/GL/glxext.h
|
|
Hmm - interesting, osmesa.h is still from the rpm, but a bunch of other GL
includes have been replaced - likely culprit - NVidia. Just as I had began to
suspect.
So I double checked the files themselves. Behold - at the top of the files:
** Copyright 1998-2002, NVIDIA Corporation.
** All Rights Reserved.
|
|
Now, I have looked for NVidia on the lugnet forums, and found this
http://news.lugnet.com/cad/dev/?n=9758. I was not prepared to try the CVS
version yet, or comment out the Offscreen rendering. So my other idea was to
move the NVidia gl files to a temporary location, and reinstall the mesa devel
libraries, then recompile.
This actually builds, but when running it I was greeted with:
freeglut (ldglite): Unable to create direct context rendering for window 'ldglite - /home/xxxxx/cddata/lego/'
This may hurt performance.
GL_VERSION = 1.2 (2.0.2 NVIDIA 87.62)
GL_EXTENSIONS = GL_ARB_depth_texture GL_ARB_imaging GL_ARB_multitexture
GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow
GL_ARB_texture_border_clamp GL_ARB_texture_cube_map GL_ARB_texture_env_add
GL_ARB_texture_env_combine GL_ARB_texture_env_dot3
GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two
GL_ARB_transpose_matrix GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra
GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_blend_minmax
GL_EXT_blend_subtract GL_EXT_draw_range_elements GL_EXT_fog_coord
GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_point_parameters
GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color
GL_EXT_shadow_funcs GL_EXT_stencil_wrap 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 GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp
GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array
GL_ATI_texture_float GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip
GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate
GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp
GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_multisample_filter_hint
GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_NV_texture_rectangle
GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp
GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGIX_depth_texture
GL_SGIX_shadow GL_SUN_multi_draw_arrays GL_SUN_slice_accum
GL_VENDOR ='NVIDIA Corporation'
GL_RENDERER ='GeForce 6600/AGP/SSE2/3DNOW!/forceSW'
GL_RGBA_BITS: (8, 8, 8, 0)
GL_DEPTH_BITS = 24
GL_STENCIL_BITS = 8
Stencil buffer disabled for XOR with NVIDIA driver.
Buffer Swap Mode = 0
VISIBILITY = GLUT_NOT_VISIBLE
VISIBILITY = GLUT_VISIBLE
|
|
And it does not actually render a thing, although I can happily change the
background colours. My next attempt is to put the NV headers back, and take out
the OffScreen rendering as per the earlier thread. This was acheived by
commenting out from the makefile so I have:
UnComment this to build in support for Mesa Offscreen rendering
# This needs (namespace?) fixing to work with GLX mesa.
#OFFSCREEN_FLAGS=-DOSMESA_OPTION
#OFFSCREEN_LIBS= -lOSMesa
|
|
So did a make clean (with -f makefile.linux - it would be great to capture some
of this be in a ./configure script?), and a make and it built. At least I
thought so - but it was still not showing a thing. And still complained:
freeglut (ldglite): Unable to create direct context rendering for window ...
|
|
So furthar on the instructions of the thread, I grabbed the CVS daily snapshop
version. Try make -f makefile.linux.
I got the error I saw earlier:
main.c: In function ‘setBackgroundColor’:
main.c:2431: error: incompatible implicit declaration of function ‘translate_color’
main.c:1453: error: previous implicit declaration of ‘translate_color’ was here
|
|
Which is easily solved by pulling the extern def to the top of the file.
Next error was:
In file included from main.c:1023:
L3Def.h:237: error: ‘_MAX_PATH’ undeclared here (not in a function)
L3Def.h:254: error: syntax error before ‘Rgbs’
|
|
And also:
main.c:3005:20: error: stdafx.h: No such file or directory
|
|
Hmm - isnt this a windows file, crept into the linux build?
Solving the _MAX_PATH first, this is defined only for turbo c. I take it this
is a definition that is expected to be available building on windows and not
using turboC, but my environment doesnt seem to have it.
There are many, many ifdefs here, and it may be in the interests of
maintainability to put a comment on the #endif’s and #else’s to say which ifdef
they belong to - this is especially pertinent if they are nested, and span over
multiple screenfulls of code. It would also be a good plan to put the rats nest
of platform specific defs elsewhere, or into the makefile, and use a configure
script to sort it out.
I give _MAX_PATH an arbitrary value of 1024 to keep it happy, as an else on
the ifdef TURBOC and also an else on the first ifdef L3P.
#else
#define _MAX_PATH 1024
|
|
Which then gives the new error:
In file included from main.c:1025:
L3Def.h:257: error: syntax error before ‘Rgbs’
L3Def.h:257: warning: data definition has no type or storage class
|
|
Line 257 is:
The definition for COLORREF is DWORD, which is furthar defined as unsigned long,
but only ifdef L3P. This is interesting - why is this file being built to depend
on parts that only exist with ifdef L3P with parts that arent constrained by the
ifdef? Okay - I put -DL3P into the linux.makefile and try again. This multiplied
into some new errors:
In file included from main.c:1025:
L3Def.h:46: error: duplicate ‘short’
L3Def.h:46: warning: useless type name in empty declaration
L3Def.h:47: error: duplicate ‘unsigned’
L3Def.h:47: warning: useless type name in empty declaration
L3Def.h:48: error: duplicate ‘unsigned’
L3Def.h:48: error: two or more data types in declaration specifiers
L3Def.h:48: warning: useless type name in empty declaration
L3Def.h:50: warning: useless type name in empty declaration
L3Def.h:51: warning: useless type name in empty declaration
|
|
Now could some of these problems be down to the fact that L3Defs is included
late in Main.c and potentially twice depending on defines? The main.c almost
seems to be two files, with a large ifdef windows section which I would advise
pulling out into a file and including when appropriate. Okay - before I get in
too deep (might be a bit late for that) - its become pretty clear why the
version on the daily is not suitable for release, and that its time to back off.
I can probably run the precompiled win binary in wine (that might need to be
transgaming), but that really doesnt suit my purposes. Does anyone have any
ideas?
My other big question, is after having a fairly good look at the source, and
with the last check in at around 8 months ago, is it still being maintained?
Don? Had I the time, I would volunteer myself.
Danny
http://orionrobots.co.uk
|
|
Message has 1 Reply:
3 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
