[Trac3R]

I' ve downloaded the CVS version (3.6.9?) and tried to compile it without any additional options:

Code: [Select]

if g++ -DPACKAGE_NAME=\"fs2_open\" -DPACKAGE_TARNAME=\"fs2_open\" -DPACKAGE_VERSION=\"3.6.9\" -DPACKAGE_STRING=\"fs2_open\ 3.6.9\" -DPACKAGE_BUGREPORT=\"\" -DNO_CD_CHECK=1 -DNDEBUG=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSCP_UNIX=1 -DNO_DIRECT3D=1 -DUSE_OPENAL=1  -I. -I.    -g -Os -Wall -funroll-loops -I/usr/include/SDL -D_REENTRANT -fsigned-char -Wno-unknown-pragmas  -Wno-deprecated -Wno-char-subscripts -I../lua  -MT ds.o -MD -MP -MF ".deps/ds.Tpo" -c -o ds.o `test -f 'sound/ds.cpp' || echo './'`sound/ds.cpp; \
then mv -f ".deps/ds.Tpo" ".deps/ds.Po"; else rm -f ".deps/ds.Tpo"; exit 1; fi
sound/ds.cpp: In function 'int ds_init(int, int, unsigned int, short unsigned int)':
sound/ds.cpp:1790: error: invalid conversion from 'const char*' to 'const ALubyte*'
sound/ds.cpp:1790: error:   initializing argument 1 of 'ALboolean alIsExtensionPresent(const ALubyte*)'
make[1]: *** [ds.o] Fehler 1
make[1]: Leaving directory `/home/shared/FS2_open/fs2_open/code'
make: *** [all-recursive] Fehler 1

Write-error? What do I change in line 1790 of ds.cpp to fix this?

[taylor]

Currently the code will only compile with OpenAL 1.1, and not 1.0.  That error is an indicator that you are using 1.0.  I'm not sure of the SuSE versioning, but in Fedora Core, the OpenAL 1.1 versions are 0.0.9.*.  Try and find a newer package for SuSE and you should be ok.  If that fails I'll try and get you a patch so that it will compile with 1.0 again.

[Trac3R]

Suse 10.0 uses a 2005...anything version of OpenAL, dont know which version it really is. There are no newer versions on rpmseek, packman or guru-suse.
But even ArchLinux 0.7.2 uses OpenAl-0.0.8-1, though it's up-to-date in everything... strange.
I tried to download the source from openal.org (newer versions than 0.0.8-1 are only for Windoze (1.1) and Mac(1.0)). With

svn checkout http://www.openal.org/repos/openal/trunk openal

I get 1.1, but this (sample) stuff doesnt work with my systems . I can build a *.rpm, but after installation all programms which depend on openal crash then. Same with Arch after make install.
This can't be the sollution. Are you sure that an 1.1 version for linux exists?

Maybe you rather help me to fix my old (3.6.7) fs2_open version, which runs but crashes at some special events. Also there are problems with the pilots data, I receive messages that they are read only, but they are obviosly not. What do you prefer?

[Trac3R]

A stable OpenAL 1.1 only exists for Windows and the MacOSX-version is still being build, but at least there is a unstable one. For Linux-Systems there's absolutely nothing. 0.0.8-1 is the recent build. I found this info in the Mailinglist-Archive of OpenAL.
It's seems like it was a little bit to fast, to migrate completely to OpenAL 1.1. In view of the crossplattform development.

[taylor]

OpenAL 1.1. has been available for Linux for quite a while, it's just that there aren't tarballs of it.  The various distros (except Fedora Core and Ubuntu at this point, which are shipping with OpenAL 1.1) have always lagged very behind on the OpenAL versions.  I looked around for a SuSE package of 1.1 but haven't found anything yet.  I might just end up building one myself to get around this problem.

OpenAL 1.1 officially shiped with the 10.4.7 OS X update so it's good there.  But then OpenAL 1.0 worked ok on the OS X builds previously anyway.

I waited a year to move to OpenAL 1.1, but it's more of a pain to try and maintain compatibility for 1.1-only on Windows and OS X, and 1.0/1.1 under Linux.  The problem is just a compile one too, OpenAL 1.1 finally standardized on some of the function calls so that's the problem, 1.0 just wasn't readily compatible code across platforms.  We aren't actually using any OpenAL 1.1 specific features (yet), but support for 1.0 is officially dropped, it's just too much trouble to deal with.  OpenAL 1.1 is just plain easier to support in a cross-platform environment.

[Trac3R]

I had compiled the 1.1 version for my Suse, but it doesn't work. Maybe it's because of the dependencies of some packages, maybe the source was wrong - I honestly don't know. When you download the CVS-source, you receive three folders with it: "OpenAL-Windows", "...MACOSX" and "...SAMPLE". There is no specific Linux source, so I tried to compile the Sample one, the result I told you before. In addition to that problem, I'd no OpenAL-devel package anymore. Even the guys on irc.freenode.net #openal where not able to tell me somthing of a stable Linux version, they lead me to the Mailinglist. If one exist, why should there be no tarball? Are they too lazy? And why even the Mac version on openal.org is only 1.0? And why there is a thread about 1.1 for Mac from Aug.2006, where it's still being build? Is OpenAL a fork and I visited the wrong website? I know that the distros lag always behind the programmers, but this time this is all too strange for me. I really don't understand, why openal.org only distributes version 0.0.8-1 for Linux, that's too far behind. Especially if you say it's out there for more than a year (acknowledged, I read a archived tread from last October about that). If 1.1 is good for cross-platform this might be really fine. But it doesn't answer this questions and doesn't solve my problems. Please give me a link to a stable source, I will try to compile it again. There's no need for a binary package, just give me a source that works with Linux. I also started a thread in the Mailinglist, hth. I hope you don't become angry because I bother you with this things all the time. Thank you for being so patient with me.

[taylor]

There is no specific Linux source, so I tried to compile the Sample one, the result I told you before. In addition to that problem, I'd no OpenAL-devel package anymore.  If one exist, why should there be no tarball? Are they too lazy?

As far as I know the Linux specific developer for OpenAL has been busy with other things for quite a while.  So the Linux version is not as complete as the Windows and OS X versions (especially the Windows version), and various parts of it are out of date, such as the .spec file to build an RPM with.  Basically there is just no one to update it right now.

And why even the Mac version on openal.org is only 1.0?

Apple maintains their own code.  Eventually it gets back to the real OpenAL code tree, but Apple actually appears to break things because of how they think it should be done.  In other words, they have a tendency to violate the OpenAL specs.  This makes folding their code back in the public tree difficult since the main OpenAL devs won't accept a broken implementation (my words).

Is OpenAL a fork and I visited the wrong website?

The problem is that Creative does their own thing for the Windows version (but they are pretty good about keeping to spec and getting most of the changes back into CVS) and Apple gets pretty freaky with the OS X version.  The Linux version doesn't have an active maintainer.  Creative is going to help out the Linux version some, so we'll get EAX support before too much longer, but that doesn't really solve the basic OpenAL-on-Linux issues.  It's all strange and confusing and there are too many companies involved who prefer to do their own thing.  It's problematic for those of us who tend to get left in the lurch, but I don't have to the time to offer a better sound alternative in FSO in addition to OpenAL.  We all just have to deal with it.

Please give me a link to a stable source, I will try to compile it again.

I have no idea if this will work, I was trying to find out before suggesting it, but you can always try the Fredora Core SRPM and see if it builds and runs ok on SuSE.  It should give you the source, some patches, and some basic build settings at the least.  Here is a link to it:
http://download.fedora.redhat.com/pub/fedora/linux/extras/5/SRPMS/openal-0.0.9-0.6.20060204cvs.fc5.src.rpm

[Trac3R]

Code: [Select]

C3PO:/home/sadow # rpmbuild --rebuild --target=i686 bin/6814.0.openal-0.0.9-0.6.20060204cvs.fc5.src.rpm
Installing bin/6814.0.openal-0.0.9-0.6.20060204cvs.fc5.src.rpm
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
Building target platforms: i686
Building for target i686
error: Failed build dependencies:
        texinfo is needed by openal-0.0.9-0.6.20060204cvs
C3PO:/home/sadow #   
Did make I something wrong? RPM does not build binary packages of it. Always these dependencies.
However, thanks for your help. Looks like I have to wait for judgement day till Suse is ready to run fs_open...

[taylor]

See if rpm -qf `which makeinfo` gives you anything, if it does then make a note of the package name it gives.  Replace "texinfo" the rpm spec with that package name and see if that fixes it.  If you do have makeinfo (if "which makeinfo" by itself returns something), but can't figure out the package it's in, then just remove "texinfo" line from the BuildRequires in the spec and it should work ok.

[Trac3R]

texinfo was not installed, that's all. The packages seem to work good, fs2_open_r has been build and I found no problems with this version, yet.
The dependency of the other crashing programm (torcs) I mentioned, has nothing to do with the OpenAL source itself, maybe the original source one would work ,too (though there's no devel package). Looks like it needs a special patched version of OpenAL. This was my fault, I should have known that, sorry.
Thanks for help again, I hope that there's no need for further.

[Lone_Wolf]

I am currently making a package for fs2_open on Archlinux and have no problems with compiling.
Archlinux uses freealut 1.1 which depends on openal 0.8 . Freealut is the utility toolkit from openal and that seems to be the versionnumber that matters.