Re: [AD] acodec proposal

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On April 11, 2010, Matthew Leverton wrote:
> On Mon, Apr 12, 2010 at 12:33 AM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> > I think al_init_acodec_addon() should be required to maintain the
> > separation.
> 
> Currently it wouldn't do anything. That is, al_load_sample() already
> automatically calls it.
> 
> >> * "foo" autodetect full name => "libfoo.so" (UNIX) or "foo.dll" or
> >> "libfoo.dll" (Windows)
> >> * "foo.dll" only try foo.dll, since the extension is present.
> > 
> > Firstly, on Linux that's going to be a problem due to distribution
> > quirks. On one distro, foo might be named libfoo.so, another might
> > have it as libfoo-1.so.  libfoo.so might be ABI-incompatible with the
> > version that acodec was compiled with, e.g. different structure sizes.
> 
> Distros would be free to specify a fully qualified name.
> 
> cmake .. -DLIBFOO=libfoo-1.so
>
> > On Windows, I don't know if the problem is acute but I've seen
> > different copies of FLAC around, under the names so similar problems
> > might apply.
> 
> Then the user already is experiencing "DLL Hell," and Allegro isn't
> contributing to it. We can be careful to specify names that are
> version qualified, if such a standard library exists. (e.g.,
> png12.dll) We only are generally working with a known subset of
> external libraries; I don't particularly care if the above
> al_open_library functions, etc, are even part of the documented API.
> 
> > DUMB's build system doesn't even build a shared library as far as I
> > remember.
> 
> I've updated it to support that.
> 
> > I think the more robust solution is for acodec to load our own DLLs
> > (like allegro_acodec-FLAC.dll) which link to FLAC. The number of DLLs
> > will not increase if you statically link the dependencies into the
> > Allegro modules.
> 
> How does that help us know that flac.dll is the same across different
> PCs?

flac would be static linked into allegro_acodec-FLAC.dll in most cases. 
instant surety that it would work fine. In case that dynamic linking the 
dependency into the loadable modules is supported, dlopen/LoadLibrary will 
fail, and the format support won't be added.

> --
> Matthew Leverton



-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/