[openal] Alure problem with vs2013

[developer at oldunreal.com]

On 16.05.2015 01:17, Chris Robinson wrote:
> On 05/14/2015 08:40 AM, developer at oldunreal.com wrote:
>> I rebuilt all my project files with visual studio 2013 when I moved to
>> this platform. Now I have a problem with alure-1.2 - using cmake already
>> was a bit of a problem since it is asking for some VORBISENC_LIBRARY
>> which I am already unable to find - and still have no clue where to get
>> it from, vorbis only contains vorbisenc.exe and not some lib.
>
> Odd, Alure itself doesn't use a vorbisenc lib. FindOggVorbis.cmake 
> will look for one and add it to the list of libraries if it's found, 
> but if it's not found it should be ignored by cmake.
>
It doesn't ignore it, at least it wants to have something in there in 
order to enable it. Which file doesn't seem to make any difference 
though. Just added vorbisfile for now in there as well.
>> Anyway the real problem is, no matter what I try, alure doesn't seem to
>> be able to play any of the additional filetypes I tried (ogg, flac and
>> mp3). Trying to play any of these always results in "Unsupported Type".
>> It doesn't make any difference if I try it statically or dynamically
>> linked.
>
> Hmm. does cmake list VorbisFile, FLAC, or SndFile as supported in its 
> message output? Assuming it does, there's not too much I can think of 
> that could be the problem.
>
Yes, both show enabled and I manually enabled mpg123 as well in the 
cmake file (which also worked with vs2008 build), all of these also show 
up in the project and is being built as well.

> Alure 1.x uses global object initialization to self-register the 
> built-in set of decoders. I've run into problems before of over- 
> enthusiastic compiler optimizations completely removing such objects 
> so the constructors are never run (thus the codecs are never properly 
> registered). I'd be surprised that it's affecting even a DLL build 
> though, since the 1.2 release does a number of things to try and make 
> the compiler not optimize the objects away. But I suppose a really 
> super-aggressive optimizer can still find ways to convince itself to 
> get rid of them.
>
> This is one of the things I set out to fix with Alure 2.0 (along with 
> many other things), since I couldn't figure out a proper fix that 
> didn't break ABI, expose internals, or necessitate a redesign anyway.
>
> I suppose a quick-fix workaround might be to edit the codec_* sources 
> and change the 'static DecoderDecl...' to 'ALURE_API DecoderDecl...', 
> and hope that stops the optimizer from dropping the objects, assuming 
> that's the problem.
Looking forward to 2.0 but will it support both mpg123 and ogg yet?

Tried the workaround with ALURE_API, but it didn't change a thing, with 
dynamic build at least which worked in older builds for me.  In the 
moment I'm a bit clueless, but will make some more tests, also with 
static builds now. If nothing helps with make another attempt with 
vs2010 to see if it behaves any different.