akode for 3.3

[Allan Sandfeld Jensen]

On Saturday 17 July 2004 20:59, Charles Samuels wrote:
>
> > It kinda looks like this:
> > - aKodelib might not work on some platforms:
> >   * I know for certain that the pluginloader needs a few fixes for
> > non-ELF system (naively assumes .so extension). (HP-UX)
>
> IMO, they should be arts plugins, and then load a common akode.so. Move all
> the portability concerns to arts, where they're already solved (and only
> have to be solved once). And having the akode framework within the arts
> framework seems a little bit redundant to me...
>
aKode is a generic decoding-layer and it does not depend on aRts, thus it can 
still be usefull if we ditch aRts. There is no way I am depending on aRts. 

> >   * For some systems the plugins might also need to be statically linked
> > to their dependencies. (non-chained library loading)
>
> If it doesn't work on a platform, the people who compile for that platform
> can switch to mpeglib. To me, 90% of our users (Linux users) should get
> priority over the 10% who run other platforms.
>
Exactly, it is designed to currently work on at least Linux , *BSDs and 
Solaris; which is pretty much everything (>99%). Every other platform with 
modern ELF and POSIX support should work as well.

> >   * I am not sure all our supported platforms even have the dlopen/dlsym
> > calls... (?)
>
> Don't use dlopen, use lt_dlopen, if you don't already. KDE definitely
> requires lt_dlopen to function.
>
Depending in libltdl would mean adding yet another copy of it to KDE (already 
one in aRts and one in kdelibs). Ofcourse if someone has any good ideas as to 
how I can take advantage of libltdl I am still open for suggestions.

`Allan