At Tue, 14 Jan 2014 10:17:09 +0000, Patrick Welche wrote:
On Mon, Jan 13, 2014 at 01:13:23PM +0100, Takashi Iwai wrote:
At Fri, 10 Jan 2014 15:37:00 +0000, Patrick Welche wrote:
I am currently successfully running alsa-lib 1.0.22 with oss plugins on a non-linux box. The advantage is that programs written to use libasound work.
I just tried to update alsa-lib, and see that now alsa-lib directly includes headers like linux/types.h, and all protection, such as
#if defined(LINUX) || defined(__LINUX__) || defined(__linux__)
has been removed. This means that compilation on non-linux is essentially impossible.
Is it that there is now a different way of obtaining that alsa lib front end / oss back end layer?
Feel free to submit a fix patch :)
The inclusions of linux/*.h are mostly due to laziness. If a patch is confirmed to work on both Linux glibc and others, we'll happily take that patch.
I started out, writing the attached patch in November, but then it looked as though the boundaries of application library interface and linux sound chip driver had become so blurred that I thought that a decision had been taken to bin all OSes bar linux, hence the question. Can you give me a hint on how you think it is supposed to work? (Which bits you know are meant to be linux only, as they are the actual drivers, which bits you think should be OS agnositic...)
The Linux-specific part is only the type definitions. There are a few Linux-kernel specific types and modifiers like __kernel_off_t or __bitwise, which are provided in linux/types.h. This is the only reason of linux/types.h inclusion. The inclusion of linux/ioct.h. can be well replaced with sys/ioctl.h, I guess.
BTW, about your patch: I don't think it's good to embed the endianness in asoundlib.h. It makes the header file appearing differently, depending on the architecture, which is rather confusing.
Takashi