Tatsuhiro Nishioka wrote:
> Hi Jari,
>
> Thanks for your patch, and sorry for my very late reply.
No worries, I have a working development environment. I post my findings
and hope the information helps others facing similar issues as I have.
If my pathces are useful they might end up in the the official CVS/git/...
> It all seems good to me but I need to work a bit more on OpenAL and
> svn lib thingies.
>
> Mac OS X, by default, has OpenAL.framework with ALUT implementation.
> Only the problem is that it lacks alut.h in its Headers folder. So
> what we need to check is the existance of alut.h in SimGear's
> configure FlightGear's configure doesn't need to check the existance
> of alut.h since it doens't include the header.
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)
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.
> Anyway, we have to either install OpenAL with alut.h to
> /Library/Frameworks or manually add alut.h to
> /Developer/SDKs/*/System/Library/Frameworks/OpenAL.frameworks/Headers/
>
Shouldn't we make simgear ignore #include OpenAL/alut.h when compiling
on OSX instead of adding the non-required alut.h? The workaround now is
to simply add a zero length file (OpenAL/alut.h) somewhere in the
pre-processors include search path.
> svn library checks look good to me, but we probably should let the
> users specify the location of the libs. This is mainly because svn
> libs on 10.5.x is older and users usually install the newer ones to
> /usr/local or some other folder. LDFLAGS="-L/some/path/to/svn-libs"
> configure works in such case, but configure
> --with-svn-libs=/some/path/to/svnlibs could be better.
I agree, --with-svn-libs is the preferred route. The changes suggested
by me was the minimalistic changes to configure.ac that would actually
compile the svn API dependent code. There should also be a --with-apr
option.
Cheers,
Jari
------------------------------------------------------------------------------
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
