[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 12 April 2010 15:51, Matthew Leverton <meffer@xxxxxxxxxx> 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.
(I'm sorry, the diff is a bit hard to follow and I haven't been able
to apply it.)
Doesn't this mean that as soon as you link with allegro_audio, you
*must* link with allegro_acodec?
>>> * "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
Ok. The build system should set it automatically, according to the DLL
it found. [1]
>> 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?
It doesn't. It would have the same effect as [1], namely hard coding
the name of the DLL discovered at configure time into the module (to
be resolved by the dynamic linker), whereas [1] hard codes it into the
call to LoadLibrary.
Peter