Welcome, Guest. Please login or register. Did you miss your activation email?
Pages: 1 [2]

Author Topic: SFML2.0 on OSX wrong OpenAL version  (Read 12880 times)

0 Members and 1 Guest are viewing this topic.

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
SFML2.0 on OSX wrong OpenAL version
« Reply #15 on: February 16, 2011, 02:51:34 pm »
From the SFML 2 SDK.
Logged
SFML / OS X developer

yttrill

  • Newbie
  • *
  • Posts: 15
    • View Profile
SFML2.0 on OSX wrong OpenAL version
« Reply #16 on: February 16, 2011, 02:54:43 pm »
Ok, the problem is narrowed down to cmake screwing up.

I deleted ALL copies of OpenAL from my system. Including the /System one. Then I built OpenAL from svn and installed it by moving the Deployment target into /System/.../

Then i noticed sfml2 has a directory called extlibs/Headers containing al.h etc do I deleted that too. That's what's causing the error. Has to be.

Then I re-ran cmake and the make and get the same error.

So now I delete the cmake cache and retry, same error.

No, I'm NOT going to read a whole lot of arcane details about Cmake, I don't care about Cmake. I don't care about SFML. I'm just a compiler writer trying to create a binding to your product for a client.

There is one copy of OpenAL on my system now. In al.h we have

#define AL_SEC_OFFSET                             0x1024

but I still get an error. So clearly sfml2's build system is getting the header from somewhere else.
Logged

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
SFML2.0 on OSX wrong OpenAL version
« Reply #17 on: February 16, 2011, 03:18:55 pm »
As I said :
Quote from: "Hiura"
extlibs/headers/AL/ header files are not used on OS X. CMake should have configured the project include path with the installed OpenAL framework. (On my computer this framework is in /System/Library/Frameworks/.)

What is the OPENAL_LIBRARY and OPENAL_INCLUDE_DIR variables content when you configure the project with CMake (click advanced to unhide them) ?


Did you get a fresh copy of SFML 2 SDK ?
Logged
SFML / OS X developer

yttrill

  • Newbie
  • *
  • Posts: 15
    • View Profile
SFML2.0 on OSX wrong OpenAL version
« Reply #18 on: February 16, 2011, 03:58:00 pm »
Quote from: "Hiura"
As I said :
Quote from: "Hiura"
extlibs/headers/AL/ header files are not used on OS X. CMake should have configured the project include path with the installed OpenAL framework. (On my computer this framework is in /System/Library/Frameworks/.)

What is the OPENAL_LIBRARY and OPENAL_INCLUDE_DIR variables content when you configure the project with CMake (click advanced to unhide them) ?


Did you get a fresh copy of SFML 2 SDK ?


And as I said I'm not using a GUI so I have nothing to "click".

I don't understand "fresh copy of SFML". I'm using the SVN repository.
I cleaned it, I cleaned a lot of things.

I checked and al.h MUST be coming from /System because there's no other copy anywhere (that I know of)

So it appears some macros are conditionally skipping stuff because the missing macros is definitely in the al.h header file (and there's only one such file on my system).
Logged

yttrill

  • Newbie
  • *
  • Posts: 15
    • View Profile
SFML2.0 on OSX wrong OpenAL version
« Reply #19 on: February 16, 2011, 04:06:14 pm »
Quote from: "Hiura"
From the SFML 2 SDK.


I don't understand. Please don't use vague marketing terms like "SDK".
Please name a directory. So I know where to look.

There is a directory called "extlibs" containing "Headers" which used to contain AL/al.h but I deleted that to make sure it wasn't used.
Logged

yttrill

  • Newbie
  • *
  • Posts: 15
    • View Profile
SFML2.0 on OSX wrong OpenAL version
« Reply #20 on: February 16, 2011, 04:37:02 pm »
Arggg .. I found ANOTHER copy of OpenAL. [Reason for not finding it before: Unix sucks. Hierarchical file system and no tools that know how to navigate it.. stupid beyond belief]

Ok, so now I am getting real errors finally:

[ 85%] Building CXX object src/SFML/Audio/CMakeFiles/sfml-audio.dir/ALCheck.cpp.o
[ 86%] Building CXX object src/SFML/Audio/CMakeFiles/sfml-audio.dir/AudioDevice.cpp.o
/Users/johnskaller/sfml/sfml/branches/sfml2/src/SFML/Audio/AudioDevice.cpp: In static member function ‘static bool sf::priv::AudioDevice::IsExtensionSupported(const std::string&)’:
/Users/johnskaller/sfml/sfml/branches/sfml2/src/SFML/Audio/AudioDevice.cpp:95: error: invalid conversion from ‘unsigned char*’ to ‘const ALCchar*’
/Users/johnskaller/sfml/sfml/branches/sfml2/src/SFML/Audio/AudioDevice.cpp:95: error:   initializing argument 2 of ‘ALCboolean alcIsExtensionPresent(ALCdevice*, const ALCchar*)’
/Users/johnskaller/sfml/sfml/branches/sfml2/src/SFML/Audio/AudioDevice.cpp:97: error: invalid conversion from ‘unsigned char*’ to ‘const ALchar*’
/Users/johnskaller/sfml/sfml/branches/sfml2/src/SFML/Audio/AudioDevice.cpp:97: error:   initializing argument 1 of ‘ALboolean alIsExtensionPresent(const ALchar*)’
/Users/johnskaller/sfml/sfml/branches/sfml2/src/SFML/Audio/AudioDevice.cpp: In static member function ‘static int sf::priv::AudioDevice::GetFormatFromChannelsCount(unsigned int)’:
/Users/johnskaller/sfml/sfml/branches/sfml2/src/SFML/Audio/AudioDevice.cpp:111: error: invalid conversion from ‘unsigned char*’ to ‘const ALchar*’
/Users/johnskaller/sfml/sfml/branches/sfml2/src/SFML/Audio/AudioDevice.cpp:111: error:   initializing argument 1 of ‘ALenum alGetEnumValue(const ALchar*)’
/Users/johnskaller/sfml/sfml/branches/sfml2/src/SFML/Audio/AudioDevice.cpp:112: error: invalid conversion from ‘unsigned char*’ to ‘const ALchar*’
/Users/johnskaller/sfml/sfml/branches/sfml2/src/SFML/Audio/AudioDevice.cpp:112: error:   initializing argument 1 of ‘ALenum alGetEnumValue(const ALchar*)’
/Users/johnskaller/sfml/sfml/branches/sfml2/src/SFML/Audio/AudioDevice.cpp:113: error: invalid conversion from ‘unsigned char*’ to ‘const ALchar*’
/Users/johnskaller/sfml/sfml/branches/sfml2/src/SFML/Audio/AudioDevice.cpp:113: error:   initializing argument 1 of ‘ALenum alGetEnumValue(const ALchar*)’
/Users/johnskaller/sfml/sfml/branches/sfml2/src/SFML/Audio/AudioDevice.cpp:114: error: invalid conversion from ‘unsigned char*’ to ‘const ALchar*’
/Users/johnskaller/sfml/sfml/branches/sfml2/src/SFML/Audio/AudioDevice.cpp:114: error:   initializing argument 1 of ‘ALenum alGetEnumValue(const ALchar*)’
make[2]: *** [src/SFML/Audio/CMakeFiles/sfml-audio.dir/AudioDevice.cpp.o] Error 1
make[1]: *** [src/SFML/Audio/CMakeFiles/sfml-audio.dir/all] Error 2
Logged

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
SFML2.0 on OSX wrong OpenAL version
« Reply #21 on: February 16, 2011, 04:39:16 pm »
Quote
I'm not using a GUI
You can find those variable in CMakeCache.txt.

Quote
I cleaned it, I cleaned a lot of things.
You should not : that might be the problem. Download the SVN directory (SDK) again and remove/edit nothing. Clean also your cmake cache just to be sure.

Now I checked the openal SVN and the Mac version seems to be the same as Apple shipped with its OS (at least the header are the same). Thus you should be able to use this one.
Logged
SFML / OS X developer

yttrill

  • Newbie
  • *
  • Posts: 15
    • View Profile
SFML2.0 on OSX wrong OpenAL version
« Reply #22 on: February 16, 2011, 05:19:41 pm »
Quote from: "Hiura"
Quote
I'm not using a GUI
You can find those variable in CMakeCache.txt.


yeah, I did, that's how I found yet another copy of OpenAL :)

Ok, so reloading svn now (because I think I added those unsigned chars to fix a bug binding to the other OpenAL .. :)

While waiting for the checkout .. I wonder why CMake found the wrong library? I also wonder, how can you get the generated Makefiles to echo the rules being executed .. if I could have done that the search path would have revealed the problem days ago.

BTW: SDL 1.3 builds right out of the box. It didn't work but the two bugs I found were fixed very quickly.

Argg .. OK everything compiles fine now, but unfortunately OpenAL.dylib is of the wrong architecture:

Linking CXX shared library ../../../lib/libsfml-audio.dylib
ld: warning: in /System/Library/Frameworks//OpenAL.framework/OpenAL, file is not of required architecture

I don't understand this. Grrr. I really hate idiot message like that one above, which neither tell you the architecture that it is, nor the architecture that's required.  Turns out I built 32 bit OpenAl. Curses to Creative!

Rebuilding 64 bit .. nope .. I can't Stupid Xcode GUI crap can't build 64 bit.
[And that's the one off Snow Leopard CD]
Logged

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
SFML2.0 on OSX wrong OpenAL version
« Reply #23 on: February 16, 2011, 05:36:30 pm »
The openal version shipped by Apple is build for multi-arch. You can use 'file' command to see the different arch of a binary.

Code: [Select]
$ file /System/Library/Frameworks/OpenAL.framework/OpenAL
/System/Library/Frameworks/OpenAL.framework/OpenAL: Mach-O universal binary with 3 architectures
/System/Library/Frameworks/OpenAL.framework/OpenAL (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
/System/Library/Frameworks/OpenAL.framework/OpenAL (for architecture i386): Mach-O dynamically linked shared library i386
/System/Library/Frameworks/OpenAL.framework/OpenAL (for architecture ppc7400): Mach-O dynamically linked shared library ppc


Here is my version : http://www.mediafire.com/?8cbmlq8kf1vbblj
but you might have some issue with simlink. I don't know.
Logged
SFML / OS X developer

yttrill

  • Newbie
  • *
  • Posts: 15
    • View Profile
SFML2.0 on OSX wrong OpenAL version
« Reply #24 on: February 16, 2011, 05:52:48 pm »
Quote from: "Hiura"
The openal version shipped by Apple is build for multi-arch. You can use 'file' command to see the different arch of a binary.


Yea, I definitely built a i386 library. Problem is I can't figure out how to fix it, Xcode is mess, like most of those IDEs, which is why I don't use them. Unfortunately its the only way to build OpenAL.

It won't let me change the arch in some places, does in others, makes copies of things left right and centre, and I can't figure out what's what. The "build" button on the IDE doesn't work at all (luckily the menu option does).

OMG:

~/openAL/OpenAL/trunk/OpenAL-MacOSX/build/Default>file openal.dylib
openal.dylib: Mach-O dynamically linked shared library ppc

What kind of crappy system is this?

I have to give up, Xcode now tells me a dylib depends on itself. Grrr .. I can't handle this rubbish anymore.
Logged

devlin

  • Full Member
  • ***
  • Posts: 128
    • View Profile
SFML2.0 on OSX wrong OpenAL version
« Reply #25 on: February 16, 2011, 06:48:00 pm »
Quote from: "yttrill"
Arggg .. I found ANOTHER copy of OpenAL. [Reason for not finding it before: Unix sucks. Hierarchical file system and no tools that know how to navigate it.. stupid beyond belief]

Code: [Select]
cd /
find . -name al.h
Completely stupid and sucky... ;)
Logged

yttrill

  • Newbie
  • *
  • Posts: 15
    • View Profile
SFML2.0 on OSX wrong OpenAL version
« Reply #26 on: February 16, 2011, 08:05:40 pm »
Quote from: "Hiura"

Here is my version : http://www.mediafire.com/?8cbmlq8kf1vbblj
but you might have some issue with simlink. I don't know.


Thanks. FINALLY with that installed sfml actually built correctly!

Thanks all for your patience. Now I can try to make a Felix binding for it and see if I can get it to work :)

Time to RTFM .. :)
Logged
Pages: 1 [2]
 

anything