At Wed, 1 Oct 2003 12:37:48 +0300 (EEST), Kai Vehmanen wrote: > > >> - use of more advanced c-lib features such as dynamic loading (dlopen(), > > it's possible to create a static library which doesn't need dlopen(). > > but it will eventually link the whole plugin objects statically. > [...] > > so, maybe a compromise is to add configure options or something to > > choose the components (e.g. plugins) to be built in. this will reduce > > the size of binary, too. > > Ok, this is good to know. Does this already work now (i.e. when dlopen() > is not available)?
no, volunteers wanted :) > > there are some parts which use glibc's extension (like jump to label > > address or function-in-function). but these can be fixed with the > > standard style, too. they are mostly optmizations only. > > Hmm, so I guess we'd need someone who actively uses dietlibc (or some > other) with ALSA. Otherwise it will be hard to keep alsa-lib > clean from glibc-isms. Any volunteers? :) ah, sorry, the above is a typo. i wanted to write "gcc". it should be independent from glibc or dietlibc. > >> apps to directly communicate with ALSA's kernel interface. > > mmm, this should be never done. > > one of the reason to have alsa-lib is to avoid this. > > But the risk is there, see my comments above about libasound size. for that, we'll need a diet alsa-lib. this wouldn't be too big, since it's just a wrapper. Takashi ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
