Hi again, Tanks for the pointers.
My comments was to elaborate on the consequences of the removed alut support by Apple. It is dangerous to use any alut.h you find on the web. As you point out using Creatives alut.h may make things simpler (macports.org is another option). I used freealuts alut.h which made the compiler to choose an unexpected path (for macs) in the source during compilation. The path chosen by the compiler required more alut functionality than provided by my mac. However, using freealut libs and alut.h, and Apples OpenAL framework works perfectly, I have done that for a while. (Now I changed strategy as outlined in other postings in this thread.) Cheers, Jari Tatsuhiro Nishioka wrote: >> Jari Häkkinen wrote: >>> Tatsuhiro Nishioka wrote: Ah, so there is no real need for alut.h >>> at all. Hm, so the alut.h issue should rather go in to simgear. I >>> now tested with a zero length alut.h and no libalut. Compiling >>> works but the linker fails with alut-complaints Undefined >>> symbols: "_alutInitWithoutContext", referenced from: >>> SGSoundMgr::SGSoundMgr()in libsgsound.a(soundmgr_openal.o) > > I guess you're using SG from Tim's git repository (or similar). > >> To get simgear I of course had to provide an alut.h but the one I >> have is from freealut-1.1 which gives me unwanted consequences. I >> am not sure about the #if statements on ALUT_API_MAJOR_VERSION in >> simgear/soundmgr_openal.cxx but I think that the compiler should >> not compile code calling alutInitWithoutContext on Apple computers. >> With my below suggested changes this issue will go away. >> > > Using alut.h from freealut-1.1 with Apple's OpenAL.framework (0.0.8) > is a big problem. You need to use alut.h that comes with > OpenAL.framework in Creative's OpenAL installer. SimGear's > sound_manager.cxx uses free-alut's ALUT functions only if > ALUT_API_MAJOR_VERSION is defined (free-alut's alut.h defines it, but > (older) alut.h in OpenAL.framework doesn't), so using alut.h that > comes with Creative's OpenAL.framework gets rid of your linker error. > > > As a matter of fact, I have no linker errors in compiling SG @ Tim's > git with alut.h that comes with Creative's OpenAL installer. > > >>> and more. Listing alut-related functions in the OpenAL framwork >>> only gives a short list of alut related functions: #> nm openAL | >>> grep alut 00013133 T _alutExit 00013168 T _alutInit 00013a2e T >>> _alutLoadWAVFile 000136f8 T _alutLoadWAVMemory 0001311e T >>> _alutUnloadWAV I have freealut installed to resolve the above >>> linker problem Browsing through simgear/soundmgr_openal.cxx it >>> looks like the calls to non-supported alut functions can be >>> avoided. I look into that. >> I removed all dependencies on alut.h which all seems to be in >> simgear/sound only. I simply removed a few include statements and >> added one function declaration (see attached patch file). All of >> the fg components now compiles without any alut/freealut added >> (except for the backward compatibility stuff in OpenAL framework >> supplied by Apple). >> >> Isn't there non-alut replacement for alutLoadWAVFile? If there is >> then alut could be removed completely. >> >> I have not yet had the possiblity to extensively test the changes >> suggested in the patch but during a short flight the changes seems >> to work. >> >> If the proposed changes is pushed to the official simgear CVS then >> the configure scripting will be easier for simgear and fg/source >> wrt alut (at least for mac developers). > > > Using the alut.h in Creative's OpenAL.framework will get the job > done, so you don't have to do this yourself. If you want to use more > embedded way rather than adding alut.h to Mac's Developer SDK, then > you can locally add alut.h to simgear/sound folder. I used this way > to avoid changing headers on every OS update. > > You can also use the following patches for this purpose. > http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk/patches/SimGear-0.3-cvs-20061203-MacOSX.diff?revision=170&view=markup > > http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk/patches/alc.patch?revision=217&view=markup > > > First one is a patch for local alut.h inside SimGear and the second > one is a patch to alc.h for compiling with gcc 4.2.x (optional) Maybe > you want to change the folder name from MacOSX10.5.sdk to > MacOSX10.6.sdk in the second patch. > > Best, > > Tat > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day trial. Simplify your report design, integration and deployment > - and focus on what you do best, core application coding. Discover > what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > ------------------------------------------------------------------------ > > > _______________________________________________ Flightgear-devel > mailing list Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
