Re: [AD] acodec proposal

[Matthew Leverton <meffer@xxxxxxxxxx>]

On Mon, Apr 12, 2010 at 11:05 PM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> True enough for DUMB (though that struct is still unsafe), but you're not
> going to get away with that for either FLAC or Vorbis.  From a quick
> glance, I can see that we would need to replicate constants like
> FLAC__STREAM_DECODER_SEEK_STATUS_ERROR, and structures like vorbis_info.
>
If they change the values of constants or rearrange structures while
keeping the name of the DLL the same, every dynamic linked executable
will cease to work, regardless if dlopen() is used.

e.g., In your method (from what I understand), the link between
allegro_acodec.dll (or audio.dll) and allegro_acodec_flac.dll will
still work, but the link between allegro_acodec_flac.dll and flac.dll
will break due to allegro_acodec_flac.dll mishandling the codes
returned from flac.dll. End result: same error as with dlopen().

So you say, then static link FLAC into allegro_acodec_flac.dll. But we
already do that with allegro_flac.dll (in Windows binary builds) and
my proposal doesn't prevent it either.

>> I wouldn't be against requiring header files per se, but then there
>> must be a requirement that you have all headers of all external codec
>> libraries to build Allegro.
>
> Fine by me.  If you are building Allegro binaries for wider distribution
> you better have all the libraries installed so you can make sure it all
> works.  If you are building Allegro for yourself, you'd obviously install
> the libraries that you want to use.
>
I was speaking in the context of my version of run time linking.
Because the interface code is mandatory in allegro_acodec.dll (or
audio.dll, depending on implementation), the only way to build it is
to duplicate or require the headers of all the third party libraries.
If the interfaces (e.g., dumb loaders) were optional, then the dynamic
loading would be for naught, as you'd have to then recompile acodec to
get dumb support.

This is a non issue in your dynamic linking or the current version.
And I happily admit that this is the weakness of my method, but I
don't believe that it makes it any less binary compatible.

> Here's how I imagine it on Windows:
>
> - user installs FLAC, Vorbis, DUMB onto his development system
> - user builds and installs Allegro (dynamic loading enabled by default)
> - user makes his game. He uses .wav sound effects and .ogg music
>  so he links with allegro_acodec.
>
> (binary packages can help with the first two steps)
>
> Now user wants to show off his game to others.  He just has to zip up his
> .exe, and the DLLs he requires.  flac.dll and dumb.dll are not required.
>
> So we have a monolithic acodec library, but still achieve the goal of
> programs not pulling in libraries they don't need.  Well, that was my
> goal.
>
But it already effectively works that way. You have:

allegro.dll
allegro_audio.dll
allegro_flac.dll (static link FLAC to it)

In your proposal, we'd have:

allegro.dll
allegro_audio.dll
allegro_audio-FLAC.dll (static link FLAC to it)

Correct?

The only difference I see between that and the current method is that
somebody could drop allegro_audio-vorbis.dll somewhere in the
filesystem, and if allegro_audio were hard coded to associate ogg
files with that particular DLL name, you could load ogg files without
the original programmer "wanting" you to.

Unless of course, the version of vorbis.dll was incompatible with
allegro_audio-vorbis.dll because the vorbis_info struct was changed.
;)

With mine (assuming acodec loader functions were put into
allegro_audio) you'd have:

allegro.dll
allegro_audio.dll
FLAC.dll

or:

allegro.dll
allegro_audio.dll (static link FLAC in it)

I'm looking at this as a way to making building Allegro easier, while
you are looking at it as a way to make distribution easier. (Mine
actually does both.)

If you want to implement your version, go ahead... I cannot imagine
why anybody would complain as it hardly changes anything except which
library you link to. But it really doesn't solve all of the issues
that I care about, so I don't feel compelled to do it.

--
Matthew Leverton