10.2 fails to compile on Ubuntu

[hanover.fiste]

Granted, this is barely an Ubuntu system any more. But...SDL 1.2OpenAL from cvsfmod 40105GCC 4.0.2scons fails at:<pre>g++ -O2 -g -Iinclude -c -o build/vamos/world/World.o src/vamos/world/World.ccar r build/vamos/libvamos.a build/vamos/body/Aerodynamic_Device.o build/vamos/body/Brake.o build/vamos/body/Car.obuild/vamos/body/Clutch.o build/vamos/body/Contact_Point.o build/vamos/body/Differential.o build/vamos/body/Drivetrain.o build/vamos/body/Engine.o build/vamos/body/Exerter.o build/vamos/body/Frame.obuild/vamos/body/Fuel_Tank.o build/vamos/body/Gauge.o build/vamos/body/Gl_Car.obuild/vamos/body/Particle.o build/vamos/body/Rigid_Body.o build/vamos/body/Suspension.o build/vamos/body/Tire.obuild/vamos/body/Transmission.o build/vamos/body/Wheel.o build/vamos/geometry/Gl_Texture_Image.obuild/vamos/geometry/Inertia_Tensor.o build/vamos/geometry/Linear_Interpolator.o build/vamos/geometry/Material.obuild/vamos/geometry/Sample.o build/vamos/geometry/Spline.o build/vamos/geometry/Texture_Image.obuild/vamos/geometry/Three_Matrix.o build/vamos/geometry/Three_Vector.o build/vamos/geometry/Two_Point.obuild/vamos/geometry/XML_Parser.o build/vamos/track/Road_Segment.o build/vamos/track/Strip_Track.obuild/vamos/world/World.oranlib build/vamos/libvamos.aar: creating build/vamos/libvamos.ag++ -O2 -g -DHAVE_OPENAL=1 -D_REENTRANT -DDATA_DIR="/usr/share/games/vdrift" -DSETTINGS_DIR=".vdrift"-DVERSION="2005-10-06" -Iinclude -I/usr/include/SDL -c -o build/main.o src/main.cpp/usr/include/AL/altypes.h:22: error: conflicting declaration 'typedef signed char ALbyte'/usr/include/AL/al.h:63: error: 'ALbyte' has a previous declaration as 'typedef char ALbyte'scons: *** [build/main.o] Error 1scons: building terminated because of errors.</pre>Also interesting is that it fails during the configuration stage if I use fmod=1 with <pre>Checking for C++ header file SDL/SDL_net.h... yesTypeError: Append() takes exactly 1 argument (2 given): File "SConstruct", line 174: SConscript('src/SConscript', build_dir='build', duplicate = 0) File "/usr/lib/scons/SCons/Script/SConscript.py", line 581: return apply(method, args, kw) File "/usr/lib/scons/SCons/Script/SConscript.py", line 508: return apply(_SConscript, [self.fs,] + files, {'exports' : exports}) File "/usr/lib/scons/SCons/Script/SConscript.py", line 239: exec _file_ in stack[-1].globals File "src/SConscript", line 52: local_env.Append('-DHAVE_FMOD=1')</pre>

[thelusiv]

I'm doing all my development on an Ubuntu Hoary system so this should work. I haven't tried compiling with that version of OpenAL, and it looks like they might have changed something in the headers thats causing some conflict with the OpenAL headers we provided. If you can get it to work feel free to post a patch.As for the FMOD bit, this is a bug I just discovered (thanks to Fabien Zouaoui who wrote an ebuild for Gentoo and found this). Change "src/SConscript", line 52 from<pre>local_env.Append('-DHAVE_FMOD=1')</pre>to<pre>local_env.Append(CCFLAGS = '-DHAVE_FMOD=1')</pre>And that should fix things up.

[hanover.fiste]

That does allow vdrift to compile, but only with scons fmod=1, then scons fmod=1 install. Just running scons fails with the original typedef error in the openal headers. Just running scons install also fails even after running scons fmod=1, so I guess scons doesn't remember the options it built the binaries with?

[thelusiv]

Just running scons install also fails even after running scons fmod=1, so I guess scons doesn't remember the options it built the binaries with?

Yep, that's another bug I have been trying to fix, it's supposed to remember the options but it doesn't. Not quite sure why...

[hanover.fiste]

So, I'm just barely even starting out on coding. Any ideas on the openal failure?

[joevenzon]

track down all of your openal header files, and make sure you don't have duplicates or somethingalso, did you get openal 1.1 or 1.0 from cvs?

[hanover.fiste]

Good thought on the dupe headers, but no, I'm very careful about that (checked anyway, libs too).I'm tracking 1.1.

[joevenzon]

try... 1.0?

[Nexus6]

Granted, this is barely an Ubuntu system any more. But...SDL 1.2OpenAL from cvsfmod 40105GCC 4.0.2scons fails at:<pre>-DVERSION="2005-10-06" -Iinclude -I/usr/include/SDL -c -o build/main.o src/main.cpp/usr/include/AL/altypes.h:22: error: conflicting declaration 'typedef signed char ALbyte'/usr/include/AL/al.h:63: error: 'ALbyte' has a previous declaration as 'typedef char ALbyte'scons: *** [build/main.o] Error 1scons: building terminated because of errors.</pre>

<P>You are using the new OpenAL (aka 1.1) and the API has changed. I'll try and work out what changes are required - I keep both 0.0.7 (aka 1.0) and 0.0.8-cvs (aka 1.1) on my Ubuntu system.<P>Cheers,<BR>Toby Haynes

[thelusiv]

It'd be great if you could do that, then we could easily have a compile-time setting that allows you to specify which version is to be used.

[hanover.fiste]

Couldn't you do that via openal-config --version in the make file?

[thelusiv]

Yes it probably could, I'd have to play with it to find out.