Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
Jari Häkkinen wrote: Ideally for macs, alut should be removed altogether but that is probably not an viable option. The second best option would be to include alut I disagree, alut has one important feature: it supports all supported WAV files on all supported platforms. So if the audio works on the development platform it'll work everywhere. No surprises that some plane doesn't work on Macs. And that's the reason I would go for FreeALUT, it supports more compression types: raw, ulaw, alaw and adpcm. function declarations for the 5 backward compatibility function in the Apple OpenAL framework in soundmgr_openal.hxx (or cxx if they does not need to be exposed, alut is only used in soundmgr_openal.cxx, I think ... I still have a lot of fg code to read). Is there planned increased use of alut functionality? If not, then the choice is a no-brainer. A No, In fact I've removed some alut functionality in the overhauling process. Erik -- 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
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
On Nov 29, 2009, at 8:12 AM, Jari Häkkinen wrote: On 2009-11-28 23.01, Erik Hofman wrote: Jari Häkkinen wrote: 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.) From what I understand Apple is depreciating those old alut functions (but still keeps hem in the library for backwards compatibility) and is encouraging everyone to use the freealut package instead. And so do I. Erik Yes, you are right. FYI, Here is Apple's policy on ALUT thing. http://developer.apple.com/mac/library/qa/qa2006/qa1504.html I believe we have a few options to use ALUT thingie in your code on Mac. 1) Use OpenAL.framework's backward compatibility (You need alut.h that comes with Creative's OpenAL.framework) 2) Use OpenAL framework + free-alut (You need to change some API names for avoiding name conflicts) 3) Change your code not to use ALUT (without embedding ALUT source code) One thing you must avoid is to add free-alut's alut.h to Apple's OpenAL.framework since this causes linker errors due to version mismatch. Anyway, I'll make a patch for configure.ac so we can support case 1 and 2 above so you can safely use free-alut. 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
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
I am not sure if this thread is going anywhere. This will be my last post in this thread. I think we (Eric and Tat) should decide for one strategy. They may already have done so but this is my last try to persuade a change in alut usage. As Tat outlines below there are several ways to deal with alut on mac and I use a fourth variant myself. The reason to keep bugging you on this issue is that there are many patches required to compile fg on mac. I would like to see a flighgear et al. code base that actually compiles everywhere without requiring patches. In this case it is possible to make the build path simpler on mac, removing Tats patching or the need to compile freealut. Ideally for macs, alut should be removed altogether but that is probably not an viable option. The second best option would be to include alut function declarations for the 5 backward compatibility function in the Apple OpenAL framework in soundmgr_openal.hxx (or cxx if they does not need to be exposed, alut is only used in soundmgr_openal.cxx, I think ... I still have a lot of fg code to read). Is there planned increased use of alut functionality? If not, then the choice is a no-brainer. A third option is to use freealut as Eric does and I did until recently. A forth is to use Tats strategy with adding alut.h from Creatives OpenAL framework. Which one of the four above to use depends on the implementers but when you decide please take into account that every step of user (and developer) friendliness is a good thing. And believe me, fg needs developer friendliness. Some background: I work on macs with 64-bit SnowLeopard (10.6.2) and I do not cross compile (i.e., I do not create universal binaries) and use terminal tools in the compilation process (no xcode). The discussion in this thread has been confusing since the code itself is slightly confusing, at least for an outsider, and the preprocessor makes different code selections depending on which alut.h is used. In simgear/simgear/sound/soundmgr_openal.cxx there are several #if statements. Naively one would think that compiling on macs the code path is to go through section inside #if defined( __APPLE__ ) conditionals. However, what happens depends on which alut.h is used by the preprocessor because of conditionals like #if defined(ALUT_API_MAJOR_VERSION) ALUT_API_MAJOR_VERSION = 1 and consequently the requirements on the underlying alut library changes. 1) Adopting my strategy to not include any alut.h at all and simply adding a declaration for alutLoadWAVFile will make the preprocessor to select the code inside the __APPLE__ conditionals. 2) Adopting Tats strategy to use Creatives alut.h will also make the preprocessor to use code inside __APPLE__ conditionals. I have not tried it myself but I have deduced it from Tats postings. 3) Use freeglut libraries and headers. This will actually make use of alut functionality not included in the Apple OpenAL framework (remember there is only 5 of them left) because of #if defined(ALUT_API_MAJOR_VERSION) ALUT_API_MAJOR_VERSION = 1 conditionals. The preprocessor will include code inside this type of conditionals, and actually ignore one __APPLE__ conditional. (Interestingly the code ignored is the only Apple compatibility alut function, alutLoadWAVFile, call in simgear ... is it coincidence or made on purpose?) However, this is all valid since freeglut of course provides the required underlying functionality. My experience is that this works perfectly without any need to change API names as claimed by Tat. One further confusion is that the alut.h is unnecessarily included in soundmgr_openal.hxx and alut becomes exposed to code that includes soundmgr_openal.hxx, i.e., fg source. To compile fg/source you need to have alut.h as the code is today. If nothing else, please remove the include in soundmgr_openal.hxx, the file itself does not use anything from alut.h. All alut.h usages is in the cxx-file. One of my coding rules is to avoid including header files not needed. I post this with good intent, Cheers Jari On 2009-11-29 19.35, Tatsuhiro Nishioka wrote: On Nov 29, 2009, at 8:12 AM, Jari Häkkinen wrote: On 2009-11-28 23.01, Erik Hofman wrote: Jari Häkkinen wrote: 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.) From what I understand Apple is depreciating those old alut functions
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
Tatsuhiro Nishioka wrote:
Hi Jari,
First, I made patches for configure.ac in both SimGear and FlightGear
(except svn lib part) so please give it a try.
I tried your changes and they work well. However, I have a slightly
different strategy so I took your changes and adopted them to my
configure.ac files.
I have added a check for the OpenAL framework in my fg configure.ac, in
your diff you simply assume that OpenAL is available. It may be true but
better safe than sorry. (See fg-check4OpenAL-confgure.diff for details.)
I added a same check to sg configure.ac (sg-check4OpenAL-configure.diff)
Your strategy with adding alut.h to your mac and use your patch to the
sg/fg configure.ac files works well. I would like you to consider the
below replacement strategy
# This assumes you have alut.h (that comes with Creative's
OpenAL.framework) in
/Developer/SDKs/MacOSX10.6/System/Library/OpenAL.framework/Headers
As I wrote in my previous posting I removed all dependency on alut.h.
This was trivial and required only changes in a few files in directory
simgear/simgear/sound. My understanding of the code is that the only
alut function used in simgear for mac is alutLoadWAVFile. If the changes
proposed in my previous post in this thread are made to simgear CVS
there is no need to add alut.h (and my sg configure.ac diff provided
here can be used with the trivial change outlined in the diff).
My proposed changes could be augmented with declarations of all five
alut functions in the OpenAL framework supplied by Apple. Use of any
other alut functionality will break simgear on default mac OpenAL
installation anyway. (It is possible to install freealut 1.1 and get
support for more alut functionality).
My point is, we can add some declarations to
simgear/simgear/sound/soundmgr_openal.hxx (or cxx) and get rid of
alut.h. This is how I do it and it works.
Cheers,
Jari
Index: configure.ac
===
RCS file: /var/cvs/SimGear-0.3/source/configure.ac,v
retrieving revision 1.118
diff -u -p -r1.118 configure.ac
--- configure.ac22 Nov 2009 22:23:01 - 1.118
+++ configure.ac28 Nov 2009 20:34:19 -
@@ -303,12 +303,6 @@ case ${host} in
*-apple-darwin*)
dnl Mac OS X
-LIBS=$LIBS -framework IOKit -framework OpenAL
-openal_LIBS=$LIBS
-# not sure how to test if OpenAL exists on MacOS (does it come by default?)
-OPENAL_OK=yes
-ALUT_OK=yes
-
dnl Thank you Christian Bauer from SheepSaver
dnl Modified by Tatsuhiro Nishioka for accepting a given framework path
dnl AC_CHECK_FRAMEWORK($1=NAME, $2=INCLUDES, $3=FRAMEWORK_PATH) ; $3 is
optional
@@ -338,6 +332,32 @@ case ${host} in
AS_VAR_POPDEF([ac_Framework])dnl
])
+LIBS=$LIBS -framework IOKit -framework OpenAL
+openal_LIBS=$LIBS
+
+if test x$with_openal_lib != x; then
+echo libopenal is not supported on Mac OS platform.
+openal_LIBS=
+else
+dnl Check that OpenAL framework can be found
+save_CPPFLAGS=$CPPFLAGS
+CPPFLAGS=
+AC_CHECK_FRAMEWORK(OpenAL,[#include OpenAL/al.h])
+if test x$ac_cv_framework_OpenAL = xyes ; then
+openal_LIBS=$FRAMEWORKS
+OPENAL_OK=yes
+# alut backward compatibility libs are provided by Apple
+# OpenAL (at least for OSX 10.5 and 10.6), no alut.h file
+# is provided. Just un-comment below line, and remove the
+# check in alut.h header.
+# ALUT_OK=yes
+dnl Looking for alut.h, if found assume that it is a part
+dnl of the OpenAL package.
+AC_CHECK_HEADERS([OpenAL/alut.h],[ALUT_OK=yes])
+fi
+CPPFLAGS=$save_CPPFLAGS
+fi
+
;;
*)
Index: configure.ac
===
RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v
retrieving revision 1.156
diff -u -p -r1.156 configure.ac
--- configure.ac22 Nov 2009 22:23:40 - 1.156
+++ configure.ac28 Nov 2009 20:28:04 -
@@ -399,11 +410,22 @@ case ${host} in
*-apple-darwin*)
dnl Mac OS X
-LIBS=$LIBS -framework IOKit -framework OpenAL
-openal_LIBS=$LIBS
-# not sure how to test if OpenAL exists on MacOS (does it come by default?)
-OPENAL_OK=yes
-ALUT_OK=yes
+if test x$with_openal_lib != x; then
+# Check for openal libs with AC_CHECK_LIB() missing here!
+openal_LIBS=
+else
+# Check that OpenAL framework can be found
+save_CPPFLAGS=$CPPFLAGS
+CPPFLAGS=
+AC_CHECK_FRAMEWORK(OpenAL,[#include OpenAL/al.h])
+if test x$ac_cv_framework_OpenAL = xyes ; then
+openal_LIBS=$FRAMEWORKS
+OPENAL_OK=yes
+ALUT_OK=yes
+fi
+CPPFLAGS=$save_CPPFLAGS
+fi
+
;;
*)
--
Let Crystal
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
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=170view=markup http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk/patches/alc.patch?revision=217view=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
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
Jari Häkkinen wrote: 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.) From what I understand Apple is depreciating those old alut functions (but still keeps hem in the library for backwards compatibility) and is encouraging everyone to use the freealut package instead. And so do I. Erik -- 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
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
On 2009-11-28 23.01, Erik Hofman wrote: Jari Häkkinen wrote: 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.) From what I understand Apple is depreciating those old alut functions (but still keeps hem in the library for backwards compatibility) and is encouraging everyone to use the freealut package instead. And so do I. Erik Yes, you are right. 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
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
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)
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.
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).
Cheers,
Jari
? simgear_sound4mac.patch
Index: simgear/sound/openal_test1.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/openal_test1.cxx,v
retrieving revision 1.13
diff -u -p -r1.13 openal_test1.cxx
--- simgear/sound/openal_test1.cxx 22 Oct 2009 08:32:04 - 1.13
+++ simgear/sound/openal_test1.cxx 27 Nov 2009 11:04:22 -
@@ -13,7 +13,6 @@ static unsigned int sleep(unsigned int s
# define AL_ILLEGAL_COMMAND AL_INVALID_OPERATION
# include OpenAL/al.h
# include OpenAL/alc.h
-# include OpenAL/alut.h
#elif defined(OPENALSDK)
# include al.h
# include alc.h
Index: simgear/sound/soundmgr_openal.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/soundmgr_openal.cxx,v
retrieving revision 1.74
diff -u -p -r1.74 soundmgr_openal.cxx
--- simgear/sound/soundmgr_openal.cxx 26 Nov 2009 13:05:44 - 1.74
+++ simgear/sound/soundmgr_openal.cxx 27 Nov 2009 11:04:22 -
@@ -30,7 +30,25 @@
#endif
#if defined( __APPLE__ )
-# include OpenAL/alut.h
+# include OpenAL/al.h
+# include OpenAL/alc.h
+
+// Definitions taken from alut.h (from #if defined (__APPLE__)
+// clauses) with the aim to become independent of alut.h since alut is
+// not available in a standard OpenAL installation on mac (since xcode
+// 2.4). Five alut functions are still included in the OpenAL
+// framework libraries but they are not declared in any header file
+// (at least in OSX 10.6.2): alutExit, alutInit, alutLoadWAVFile,
+// alutLoadWAVMemory, and alutUnloadWAV
+extern C {
+
+#define ALUT_API extern
+#define ALUT_APIENTRY
+#define ALUT_ATTRIBUTE_DEPRECATED __attribute__((deprecated))
+
+ALUT_API ALUT_ATTRIBUTE_DEPRECATED void ALUT_APIENTRY alutLoadWAVFile (ALbyte
*fileName, ALenum *format, void **data, ALsizei *size, ALsizei *frequency);
+}
+
#else
# include AL/alut.h
#endif
Index: simgear/sound/soundmgr_openal.hxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/soundmgr_openal.hxx,v
retrieving revision 1.35
diff -u -p -r1.35 soundmgr_openal.hxx
--- simgear/sound/soundmgr_openal.hxx 23 Nov 2009 10:32:28 - 1.35
+++ simgear/sound/soundmgr_openal.hxx 27 Nov 2009 11:04:22 -
@@ -48,7 +48,6 @@
# define AL_ILLEGAL_COMMAND AL_INVALID_OPERATION
# include OpenAL/al.h
# include OpenAL/alc.h
-# include OpenAL/alut.h
#elif defined(OPENALSDK)
# include al.h
# include alc.h
--
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___
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
Hi Jari, First, I made patches for configure.ac in both SimGear and FlightGear (except svn lib part) so please give it a try. # This assumes you have alut.h (that comes with Creative's OpenAL.framework) in /Developer/SDKs/MacOSX10.6/System/Library/OpenAL.framework/Headers On Nov 27, 2009, at 10:37 PM, Jari Häkkinen 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=170view=markup http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk/patches/alc.patch?revision=217view=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 fg-configure.diff Description: Binary data sg-configure.diff Description: Binary data -- 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
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
Hi Jari,
Thanks for your patch, and sorry for my very late reply.
I'm back from my vacation and have been catching up the discussions on the list.
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.
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/
We also need some hacks to alc.h for avoiding error messages (invalid type
conversion between ALvoid and void) when using g++ 4.2.x.
Maybe we should add some note on this issue to README.OpenAL.
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.
Anyway, I'll apply your patch and make some modifications for better usability,
so be patient for a bit more please.
Best,
Tat
On Nov 1, 2009, at 7:03 AM, Jari Häkkinen wrote:
I have made changes (improvements?) to the configure script. I have
attached a patch file for configure.ac with changes targeting issues
with building flightgear on my mac. The changes will only impact mac
users.
Changes made:
1) Fixed mixup in AC_ARG_WITH between osg and plib.
2) Added check for that openal framework can be located in the default
framework path. Test for non-standard path is not implemented.
3) Added check if alut is a part of the OpenAL framework, if not the a
AC_SEARCH_LIBS os performed to search for freealut. Snow Leopard
does not provide alut as a part of the OpenAL framework.
4) I added --with-cocoa-framework option. This enables the user to
switch from the default Carbon framework to Cocoa.
Comments:
Change 1) is an error in configure.ac and should be fixed even if the
rest of my changes are rejected.
Change 2) and 3) may break things for other mac users since there was
no checks before, configure simply set some variables without testing.
Change 4) is needed to compile 64-bit binaries on mac but the change
will not affect Carbon users. Carbon is 32-bit only whereas Cocoa
comes also in 64-bit flavour. (OSG works with Cocoa but OSG quicktime
support must be dropped and the ImageIO plug-in must probably be used
in OSG).
Can some other mac users try my changes and report back? If the
changes work on other machines than mine then can convince someone to
commit the changes to CVS.
Cheers,
Jari
Index: configure.ac
===
RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v
retrieving revision 1.154
diff -u -p -r1.154 configure.ac
--- configure.ac 17 Sep 2009 07:39:04 - 1.154
+++ configure.ac 31 Oct 2009 21:55:35 -
@@ -85,16 +85,27 @@ case ${host} in
])
# Mac OS X specific configure options
-AC_ARG_WITH(osg_framework, [ --with-osg-framework=PREFIX Specify
the prefix path to osg frameworks [default=standard framework paths]])
-if test x$with_plib_framework != x ; then
-echo plib prefix is $with_plib_framework
+# OpenAL framework is used by default, no openal_framework implemented.
+
+AC_ARG_WITH(cocoa_framework, [ --with-cocoa-framework Use the
Cocoa rather than Carbon]])
+if test x$with_cocoa_framework != x ; then
+macAPI=Cocoa
+AC_MSG_NOTICE([Using Cocoa framework])
+else
+macAPI=Carbon
+AC_MSG_NOTICE([Using Carbon framework])
fi
-AC_ARG_WITH(plib_framework, [ --with-plib-framework=PREFIX
Specify the prefix path to PLIB framework [default=standard framework paths]])
+AC_ARG_WITH(osg_framework, [ --with-osg-framework=PREFIX Specify
the prefix path to osg frameworks [default=standard framework paths]])
if test x$with_osg_framework != x ; then
echo osg prefix is $with_osg_framework
fi
+
+AC_ARG_WITH(plib_framework, [ --with-plib-framework=PREFIX
Specify the prefix path to PLIB framework [default=standard framework paths]])
+if test x$with_plib_framework != x ; then
+echo plib prefix is $with_plib_framework
+fi
;;
esac
@@ -335,7 +346,7 @@ case ${host} in
*-apple-darwin*)
dnl Mac OS X
-LIBS=$LIBS -framework GLUT -framework OpenGL -framework AGL -framework
Carbon -lobjc
+LIBS=$LIBS -framework GLUT -framework OpenGL -framework AGL -framework
$macAPI -lobjc
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
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
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
Jari Häkkinen wrote: 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. Of course, simgear needs alut.h so the above statemens are plain wrong. Maybe the simgear package can provide declarations for the alut functionality it uses (at least for macusers)? Still on OSX10.6, currently the simplest workaround is to install freealut from http://connect.creativelabs.com/openal/Downloads/Forms/AllItems.aspx 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
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
On 31 Oct 2009, at 22:03, Jari Häkkinen wrote: I have made changes (improvements?) to the configure script. I have attached a patch file for configure.ac with changes targeting issues with building flightgear on my mac. The changes will only impact mac users. These all sound good, but I don't (yet) use the configure -based build system on Mac. I can commit, but I'd prefer to wait for Tat to look these changes over. Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
I have made changes (improvements?) to the configure script. I have
attached a patch file for configure.ac with changes targeting issues
with building flightgear on my mac. The changes will only impact mac
users.
Changes made:
1) Fixed mixup in AC_ARG_WITH between osg and plib.
2) Added check for that openal framework can be located in the default
framework path. Test for non-standard path is not implemented.
3) Added check if alut is a part of the OpenAL framework, if not the a
AC_SEARCH_LIBS os performed to search for freealut. Snow Leopard
does not provide alut as a part of the OpenAL framework.
4) I added --with-cocoa-framework option. This enables the user to
switch from the default Carbon framework to Cocoa.
Comments:
Change 1) is an error in configure.ac and should be fixed even if the
rest of my changes are rejected.
Change 2) and 3) may break things for other mac users since there was
no checks before, configure simply set some variables without testing.
Change 4) is needed to compile 64-bit binaries on mac but the change
will not affect Carbon users. Carbon is 32-bit only whereas Cocoa
comes also in 64-bit flavour. (OSG works with Cocoa but OSG quicktime
support must be dropped and the ImageIO plug-in must probably be used
in OSG).
Can some other mac users try my changes and report back? If the
changes work on other machines than mine then can convince someone to
commit the changes to CVS.
Cheers,
Jari
Index: configure.ac
===
RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v
retrieving revision 1.154
diff -u -p -r1.154 configure.ac
--- configure.ac17 Sep 2009 07:39:04 - 1.154
+++ configure.ac31 Oct 2009 21:55:35 -
@@ -85,16 +85,27 @@ case ${host} in
])
# Mac OS X specific configure options
-AC_ARG_WITH(osg_framework, [ --with-osg-framework=PREFIX Specify
the prefix path to osg frameworks [default=standard framework paths]])
-if test x$with_plib_framework != x ; then
-echo plib prefix is $with_plib_framework
+# OpenAL framework is used by default, no openal_framework implemented.
+
+AC_ARG_WITH(cocoa_framework, [ --with-cocoa-framework Use the Cocoa
rather than Carbon]])
+if test x$with_cocoa_framework != x ; then
+macAPI=Cocoa
+AC_MSG_NOTICE([Using Cocoa framework])
+else
+macAPI=Carbon
+AC_MSG_NOTICE([Using Carbon framework])
fi
-AC_ARG_WITH(plib_framework, [ --with-plib-framework=PREFIX Specify
the prefix path to PLIB framework [default=standard framework paths]])
+AC_ARG_WITH(osg_framework, [ --with-osg-framework=PREFIX Specify
the prefix path to osg frameworks [default=standard framework paths]])
if test x$with_osg_framework != x ; then
echo osg prefix is $with_osg_framework
fi
+
+AC_ARG_WITH(plib_framework, [ --with-plib-framework=PREFIX Specify
the prefix path to PLIB framework [default=standard framework paths]])
+if test x$with_plib_framework != x ; then
+echo plib prefix is $with_plib_framework
+fi
;;
esac
@@ -335,7 +346,7 @@ case ${host} in
*-apple-darwin*)
dnl Mac OS X
-LIBS=$LIBS -framework GLUT -framework OpenGL -framework AGL -framework
Carbon -lobjc
+LIBS=$LIBS -framework GLUT -framework OpenGL -framework AGL -framework
$macAPI -lobjc
joystick_LIBS=$joystick_LIBS -framework IOKit -framework CoreFoundation
;;
@@ -399,11 +410,27 @@ case ${host} in
*-apple-darwin*)
dnl Mac OS X
-LIBS=$LIBS -framework IOKit -framework OpenAL
-openal_LIBS=$LIBS
-# not sure how to test if OpenAL exists on MacOS (does it come by default?)
-OPENAL_OK=yes
-ALUT_OK=yes
+if test x$with_openal_lib != x; then
+# Check for openal libs with AC_CHECK_LIB() missing here!
+openal_LIBS=
+else
+# Check that OpenAL framework can be found
+AC_CHECK_FRAMEWORK(OpenAL,[#include OpenAL/al.h])
+if test x$ac_cv_framework_OpenAL = xyes ; then
+openal_LIBS=$FRAMEWORKS
+OPENAL_OK=yes
+# Looking for alut.h, if found assume that it is a part of
+# the OpenAL package.
+AC_CHECK_HEADERS([OpenAL/alut.h],[ALUT_OK=yes])
+fi
+fi
+
+# Check if alut was considered to be a part of the OpenAL
+# framework above, if not try to locate a alut library.
+if test x$ALUT_OK = xno ; then
+AC_SEARCH_LIBS(alutInit, alut,
+ [ ALUT_OK=yes openal_LIBS=$openal_LIBS -lalut ])
+fi
;;
*)
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12,
