[alsa-devel] alsa on non-linux
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?
Cheers,
Patrick
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.
Takashi
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...)
Cheers,
Patrick
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
On Tue, Jan 14, 2014 at 02:23:01PM +0100, Takashi Iwai wrote:
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.
Is this more what you have in mind? (Less portable than autoconf, but not set at configure time.)
The four files which included endian.h were:
- include/asoundlib-head.h - include/local.h - include/sound/type_compat.h - src/pcm/pcm_file.c
The endian.h line(s) in asoundlib.h is now generated by configure.
local.h includes the appropriate endian.h vs sys/endian.h file & defines the relevant macros.
type_compat.h doesn't seem to be used anywhere? So I left it alone.
pcm_file.c includes pcm_local.h which includes local.h, so I removed the #include <endian.h>
(Still far from being able to compile alsa-lib, but it's a start...)
Cheers,
Patrick
At Fri, 21 Feb 2014 01:27:04 +0000, Patrick Welche wrote:
On Tue, Jan 14, 2014 at 02:23:01PM +0100, Takashi Iwai wrote:
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.
Is this more what you have in mind? (Less portable than autoconf, but not set at configure time.)
Yes, I supposed something like that.
The four files which included endian.h were:
- include/asoundlib-head.h
- include/local.h
- include/sound/type_compat.h
- src/pcm/pcm_file.c
The endian.h line(s) in asoundlib.h is now generated by configure.
Looks almost good, but I prefer seeing it just after #include <stdarg.h> instead of the middle in alsa/* inclusions.
Other than that, all look good to me. Could you fix and resubmit with your sign-off?
thanks,
Takashi
local.h includes the appropriate endian.h vs sys/endian.h file & defines the relevant macros.
type_compat.h doesn't seem to be used anywhere? So I left it alone.
pcm_file.c includes pcm_local.h which includes local.h, so I removed the #include <endian.h>
(Still far from being able to compile alsa-lib, but it's a start...)
Cheers,
Patrick
From 5885d2e79dfd8f788177a95c70967d9a3c9a2cb6 Mon Sep 17 00:00:00 2001
From: Patrick Welche prlw1@cam.ac.uk Date: Fri, 21 Feb 2014 01:18:01 +0000 Subject: [PATCH] Portability fix: look for sys/endian.h as well as endian.h
- define __BYTE_ORDER and friends.
- adjust asoundlib.h accordingly.
configure.in | 19 +++++++++++++++++-- include/asoundlib-head.h | 1 - include/local.h | 18 +++++++++++++++++- src/pcm/pcm_file.c | 1 - 4 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/configure.in b/configure.in index bb56eb6..60d4ae1 100644 --- a/configure.in +++ b/configure.in @@ -309,8 +309,8 @@ fi
AC_SUBST(ALSA_DEPLIBS)
-dnl Check for wordexp.h -AC_CHECK_HEADERS([wordexp.h]) +dnl Check for headers +AC_CHECK_HEADERS([wordexp.h endian.h sys/endian.h])
dnl Check for resmgr support... AC_MSG_CHECKING(for resmgr support) @@ -660,6 +660,21 @@ AC_OUTPUT(Makefile doc/Makefile doc/pictures/Makefile doc/doxygen.cfg \ dnl Create asoundlib.h dynamically according to configure options echo "Creating asoundlib.h..." cp "$srcdir"/include/asoundlib-head.h include/asoundlib.h +test "$ac_cv_header_endian_h" = "yes" && echo "#include <endian.h>" >> include/asoundlib.h +if test "$ac_cv_header_sys_endian_h" = "yes"; then +cat >> include/asoundlib.h <<EOF +#include <sys/endian.h> +#ifndef __BYTE_ORDER +#define __BYTE_ORDER BYTE_ORDER +#endif +#ifndef __LITTLE_ENDIAN +#define __LITTLE_ENDIAN LITTLE_ENDIAN +#endif +#ifndef __BIG_ENDIAN +#define __BIG_ENDIAN BIG_ENDIAN +#endif +EOF +fi test "$build_pcm" = "yes" && echo "#include <alsa/pcm.h>" >> include/asoundlib.h test "$build_rawmidi" = "yes" && echo "#include <alsa/rawmidi.h>" >> include/asoundlib.h test "$build_pcm" = "yes" && echo "#include <alsa/timer.h>" >> include/asoundlib.h diff --git a/include/asoundlib-head.h b/include/asoundlib-head.h index 71b5c29..31408a4 100644 --- a/include/asoundlib-head.h +++ b/include/asoundlib-head.h @@ -35,7 +35,6 @@ #include <string.h> #include <fcntl.h> #include <assert.h> -#include <endian.h> #include <sys/poll.h> #include <errno.h> #include <stdarg.h> diff --git a/include/local.h b/include/local.h index 9464efa..2fe9a27 100644 --- a/include/local.h +++ b/include/local.h @@ -22,13 +22,30 @@ #ifndef __LOCAL_H #define __LOCAL_H
+#include "config.h"
#include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <fcntl.h> #include <assert.h> +#ifdef HAVE_ENDIAN_H #include <endian.h> +#elif defined(HAVE_SYS_ENDIAN_H) +#include <sys/endian.h> +#ifndef __BYTE_ORDER +#define __BYTE_ORDER BYTE_ORDER +#endif +#ifndef __LITTLE_ENDIAN +#define __LITTLE_ENDIAN LITTLE_ENDIAN +#endif +#ifndef __BIG_ENDIAN +#define __BIG_ENDIAN BIG_ENDIAN +#endif +#else +#error Header defining endianness not defined +#endif #include <stdarg.h> #include <sys/poll.h> #include <sys/types.h> @@ -36,7 +53,6 @@ #include <linux/types.h> #include <linux/ioctl.h>
-#include "config.h" #ifdef SUPPORT_RESMGR #include <resmgr.h> #endif diff --git a/src/pcm/pcm_file.c b/src/pcm/pcm_file.c index 7123025..b1f2330 100644 --- a/src/pcm/pcm_file.c +++ b/src/pcm/pcm_file.c @@ -26,7 +26,6 @@
*/
-#include <endian.h> #include <byteswap.h> #include <ctype.h>
#include <string.h>
1.8.5.4
On Fri, Feb 21, 2014 at 12:04:03PM +0100, Takashi Iwai wrote:
At Fri, 21 Feb 2014 01:27:04 +0000, Patrick Welche wrote:
On Tue, Jan 14, 2014 at 02:23:01PM +0100, Takashi Iwai wrote:
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.
Is this more what you have in mind? (Less portable than autoconf, but not set at configure time.)
Yes, I supposed something like that.
The four files which included endian.h were:
- include/asoundlib-head.h
- include/local.h
- include/sound/type_compat.h
- src/pcm/pcm_file.c
The endian.h line(s) in asoundlib.h is now generated by configure.
Looks almost good, but I prefer seeing it just after #include <stdarg.h> instead of the middle in alsa/* inclusions.
Other than that, all look good to me. Could you fix and resubmit with your sign-off?
Version 2 with some of asoundlib-head.h moved to configure.in. (Fancy a patch to rename configure.in configure.ac, s/INCLUDES/AM_CPPFLAGS/?)
Cheers,
Patrick
At Sun, 23 Feb 2014 11:12:48 +0000, Patrick Welche wrote:
On Fri, Feb 21, 2014 at 12:04:03PM +0100, Takashi Iwai wrote:
At Fri, 21 Feb 2014 01:27:04 +0000, Patrick Welche wrote:
On Tue, Jan 14, 2014 at 02:23:01PM +0100, Takashi Iwai wrote:
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.
Is this more what you have in mind? (Less portable than autoconf, but not set at configure time.)
Yes, I supposed something like that.
The four files which included endian.h were:
- include/asoundlib-head.h
- include/local.h
- include/sound/type_compat.h
- src/pcm/pcm_file.c
The endian.h line(s) in asoundlib.h is now generated by configure.
Looks almost good, but I prefer seeing it just after #include <stdarg.h> instead of the middle in alsa/* inclusions.
Other than that, all look good to me. Could you fix and resubmit with your sign-off?
Version 2 with some of asoundlib-head.h moved to configure.in.
Thanks, applied now.
(Fancy a patch to rename configure.in configure.ac, s/INCLUDES/AM_CPPFLAGS/?)
Not bad, but I'm too tired to follow stupid policy changes of auto-tools, so basically I don't care much unless the upstream really breaks it :)
Takashi
Cheers,
Patrick
From b14f62d1345b563e9b8f525efb00f30312b17cc2 Mon Sep 17 00:00:00 2001
From: Patrick Welche prlw1@cam.ac.uk Date: Sun, 23 Feb 2014 11:02:28 +0000 Subject: [PATCH] Portability fix: look for sys/endian.h as well as endian.h
- define __BYTE_ORDER and friends.
- adjust asoundlib.h accordingly.
Signed-off-by: Patrick Welche prlw1@cam.ac.uk
configure.in | 33 +++++++++++++++++++++++++++++++-- include/asoundlib-head.h | 13 ------------- include/local.h | 18 +++++++++++++++++- src/pcm/pcm_file.c | 1 - 4 files changed, 48 insertions(+), 17 deletions(-)
diff --git a/configure.in b/configure.in index bb56eb6..9463b5a 100644 --- a/configure.in +++ b/configure.in @@ -309,8 +309,8 @@ fi
AC_SUBST(ALSA_DEPLIBS)
-dnl Check for wordexp.h -AC_CHECK_HEADERS([wordexp.h]) +dnl Check for headers +AC_CHECK_HEADERS([wordexp.h endian.h sys/endian.h])
dnl Check for resmgr support... AC_MSG_CHECKING(for resmgr support) @@ -660,6 +660,35 @@ AC_OUTPUT(Makefile doc/Makefile doc/pictures/Makefile doc/doxygen.cfg \ dnl Create asoundlib.h dynamically according to configure options echo "Creating asoundlib.h..." cp "$srcdir"/include/asoundlib-head.h include/asoundlib.h +test "$ac_cv_header_endian_h" = "yes" && echo "#include <endian.h>" >> include/asoundlib.h +if test "$ac_cv_header_sys_endian_h" = "yes"; then +cat >> include/asoundlib.h <<EOF +#include <sys/endian.h> +#ifndef __BYTE_ORDER +#define __BYTE_ORDER BYTE_ORDER +#endif +#ifndef __LITTLE_ENDIAN +#define __LITTLE_ENDIAN LITTLE_ENDIAN +#endif +#ifndef __BIG_ENDIAN +#define __BIG_ENDIAN BIG_ENDIAN +#endif +EOF +fi +cat >> include/asoundlib.h <<EOF
+#ifndef __GNUC__ +#define __inline__ inline +#endif
+#include <alsa/asoundef.h> +#include <alsa/version.h> +#include <alsa/global.h> +#include <alsa/input.h> +#include <alsa/output.h> +#include <alsa/error.h> +#include <alsa/conf.h> +EOF test "$build_pcm" = "yes" && echo "#include <alsa/pcm.h>" >> include/asoundlib.h test "$build_rawmidi" = "yes" && echo "#include <alsa/rawmidi.h>" >> include/asoundlib.h test "$build_pcm" = "yes" && echo "#include <alsa/timer.h>" >> include/asoundlib.h diff --git a/include/asoundlib-head.h b/include/asoundlib-head.h index 71b5c29..1ec611e 100644 --- a/include/asoundlib-head.h +++ b/include/asoundlib-head.h @@ -35,19 +35,6 @@ #include <string.h> #include <fcntl.h> #include <assert.h> -#include <endian.h> #include <sys/poll.h> #include <errno.h> #include <stdarg.h>
-#ifndef __GNUC__ -#define __inline__ inline -#endif
-#include <alsa/asoundef.h> -#include <alsa/version.h> -#include <alsa/global.h> -#include <alsa/input.h> -#include <alsa/output.h> -#include <alsa/error.h> -#include <alsa/conf.h> diff --git a/include/local.h b/include/local.h index 9464efa..2fe9a27 100644 --- a/include/local.h +++ b/include/local.h @@ -22,13 +22,30 @@ #ifndef __LOCAL_H #define __LOCAL_H
+#include "config.h"
#include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <fcntl.h> #include <assert.h> +#ifdef HAVE_ENDIAN_H #include <endian.h> +#elif defined(HAVE_SYS_ENDIAN_H) +#include <sys/endian.h> +#ifndef __BYTE_ORDER +#define __BYTE_ORDER BYTE_ORDER +#endif +#ifndef __LITTLE_ENDIAN +#define __LITTLE_ENDIAN LITTLE_ENDIAN +#endif +#ifndef __BIG_ENDIAN +#define __BIG_ENDIAN BIG_ENDIAN +#endif +#else +#error Header defining endianness not defined +#endif #include <stdarg.h> #include <sys/poll.h> #include <sys/types.h> @@ -36,7 +53,6 @@ #include <linux/types.h> #include <linux/ioctl.h>
-#include "config.h" #ifdef SUPPORT_RESMGR #include <resmgr.h> #endif diff --git a/src/pcm/pcm_file.c b/src/pcm/pcm_file.c index 7123025..b1f2330 100644 --- a/src/pcm/pcm_file.c +++ b/src/pcm/pcm_file.c @@ -26,7 +26,6 @@
*/
-#include <endian.h> #include <byteswap.h> #include <ctype.h>
#include <string.h>
1.8.5.4
On Mon, Feb 24, 2014 at 11:03:35AM +0100, Takashi Iwai wrote:
At Sun, 23 Feb 2014 11:12:48 +0000, Patrick Welche wrote:
Version 2 with some of asoundlib-head.h moved to configure.in.
Thanks, applied now.
Thank you!
(Fancy a patch to rename configure.in configure.ac, s/INCLUDES/AM_CPPFLAGS/?)
Not bad, but I'm too tired to follow stupid policy changes of auto-tools, so basically I don't care much unless the upstream really breaks it :)
It turns out that most of the warnings come from m4/attributes.m4 which seems to have been taken from xine-lib...
Here is a patch for some minor cleanup (not touching m4/attributes.m4)
Cheers,
Patrick
At Tue, 25 Feb 2014 12:40:21 +0000, Patrick Welche wrote:
On Mon, Feb 24, 2014 at 11:03:35AM +0100, Takashi Iwai wrote:
At Sun, 23 Feb 2014 11:12:48 +0000, Patrick Welche wrote:
Version 2 with some of asoundlib-head.h moved to configure.in.
Thanks, applied now.
Thank you!
(Fancy a patch to rename configure.in configure.ac, s/INCLUDES/AM_CPPFLAGS/?)
Not bad, but I'm too tired to follow stupid policy changes of auto-tools, so basically I don't care much unless the upstream really breaks it :)
It turns out that most of the warnings come from m4/attributes.m4 which seems to have been taken from xine-lib...
Here is a patch for some minor cleanup (not touching m4/attributes.m4)
Thanks, applied.
Takashi
Patrick Welche wrote:
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?
Only the "hw" plugins access the Linux kernel drivers. Anything else should be portable (with the exception of plugins like "dmix" that require a "hw" plugin as their slave).
For most device types (hwdep/seq/rawmidi/timer), the hw plugin is the only implementation, so a portable alsa-lib has only control and pcm devices at the moment.
Regards, Clemens
On Tue, Jan 14, 2014 at 03:04:58PM +0100, Clemens Ladisch wrote:
Patrick Welche wrote:
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?
Only the "hw" plugins access the Linux kernel drivers. Anything else should be portable (with the exception of plugins like "dmix" that require a "hw" plugin as their slave).
For most device types (hwdep/seq/rawmidi/timer), the hw plugin is the only implementation, so a portable alsa-lib has only control and pcm devices at the moment.
So, rephrasing for the novice that I am, e.g., include/local.h contains
#include <endian.h> ... #if __BYTE_ORDER == __LITTLE_ENDIAN ... #include <linux/types.h> #include <linux/ioctl.h>
which are portability headaches. local.h is included by
src/alisp/alisp.c:#include "local.h" src/conf.c:#include "local.h" src/confmisc.c:#include "local.h" src/control/control_local.h:#include "local.h" src/control/namehint.c:#include "local.h" src/control/setup.c:#include "local.h" src/dlmisc.c:#include "local.h" src/error.c:#include "local.h" src/hwdep/hwdep_local.h:#include "local.h" src/input.c:#include "local.h" src/mixer/mixer_local.h:#include "local.h" src/names.c:#include "local.h" src/output.c:#include "local.h" src/pcm/pcm_local.h:#include "local.h" src/rawmidi/rawmidi_local.h:#include "local.h" src/seq/seq_event.c:#include "local.h" src/seq/seq_local.h:#include "local.h" src/seq/seq_midi_event.c:#include "local.h" src/seq/seq_old.c:#include "local.h" src/socket.c:#include "local.h" src/timer/timer_local.h:#include "local.h" src/ucm/ucm_local.h:#include "local.h"
That is fine except for files under directories src/control and src/pcm which ought to be portable? Or is it stronger, and everything should be portable except files under directory src/hwdep?
Cheers,
Patrick
At Thu, 16 Jan 2014 13:27:17 +0000, Patrick Welche wrote:
On Tue, Jan 14, 2014 at 03:04:58PM +0100, Clemens Ladisch wrote:
Patrick Welche wrote:
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?
Only the "hw" plugins access the Linux kernel drivers. Anything else should be portable (with the exception of plugins like "dmix" that require a "hw" plugin as their slave).
For most device types (hwdep/seq/rawmidi/timer), the hw plugin is the only implementation, so a portable alsa-lib has only control and pcm devices at the moment.
So, rephrasing for the novice that I am, e.g., include/local.h contains
#include <endian.h> ... #if __BYTE_ORDER == __LITTLE_ENDIAN ... #include <linux/types.h> #include <linux/ioctl.h>
which are portability headaches. local.h is included by
src/alisp/alisp.c:#include "local.h" src/conf.c:#include "local.h" src/confmisc.c:#include "local.h" src/control/control_local.h:#include "local.h" src/control/namehint.c:#include "local.h" src/control/setup.c:#include "local.h" src/dlmisc.c:#include "local.h" src/error.c:#include "local.h" src/hwdep/hwdep_local.h:#include "local.h" src/input.c:#include "local.h" src/mixer/mixer_local.h:#include "local.h" src/names.c:#include "local.h" src/output.c:#include "local.h" src/pcm/pcm_local.h:#include "local.h" src/rawmidi/rawmidi_local.h:#include "local.h" src/seq/seq_event.c:#include "local.h" src/seq/seq_local.h:#include "local.h" src/seq/seq_midi_event.c:#include "local.h" src/seq/seq_old.c:#include "local.h" src/socket.c:#include "local.h" src/timer/timer_local.h:#include "local.h" src/ucm/ucm_local.h:#include "local.h"
That is fine except for files under directories src/control and src/pcm which ought to be portable? Or is it stronger, and everything should be portable except files under directory src/hwdep?
Why excluding hwdep...? And, no, the codes have been written to be portable, but the primary goal is a thin layer for Linux kernel ABI, thus its support is the highest priority.
The linux/*.h file inclusions are basically for allowing to include sound/asound.h as is. It's a part of the Linux kernel code, and I don't think we'd add any extra ifdefs there just for non-Linux.
IOW, you'd need to prepare some compatible defines before including sound/asound.h if you need to compile for non-Linux systems.
Takashi
On Thu, Jan 16, 2014 at 02:46:52PM +0100, Takashi Iwai wrote:
At Thu, 16 Jan 2014 13:27:17 +0000, Patrick Welche wrote: Why excluding hwdep...? And, no, the codes have been written to be portable, but the primary goal is a thin layer for Linux kernel ABI, thus its support is the highest priority.
The linux/*.h file inclusions are basically for allowing to include sound/asound.h as is. It's a part of the Linux kernel code, and I don't think we'd add any extra ifdefs there just for non-Linux.
IOW, you'd need to prepare some compatible defines before including sound/asound.h if you need to compile for non-Linux systems.
I should have read this more carefully before preparing the attached patch... I changed asound.h.
The attached is what I needed to be able to build with
../configure --prefix=/tmp \ --enable-debug \ --disable-resmgr \ --disable-aload \ --disable-mixer \ --disable-pcm \ --disable-rawmidi \ --disable-hwdep \ --disable-seq \ --disable-ucm \ --disable-alisp \ --disable-old-symbols \ --disable-python \ --with-debug \ --without-libdl \ --without-librt
so not very useful, but at least it compiles. (This is on top of 0001-autotools-update-style.patch)
Suggestions on what to try to make it acceptable?
(byteswap.h needs tackling next...)
Cheers,
Patrick
At Tue, 25 Feb 2014 12:45:14 +0000, Patrick Welche wrote:
On Thu, Jan 16, 2014 at 02:46:52PM +0100, Takashi Iwai wrote:
At Thu, 16 Jan 2014 13:27:17 +0000, Patrick Welche wrote: Why excluding hwdep...? And, no, the codes have been written to be portable, but the primary goal is a thin layer for Linux kernel ABI, thus its support is the highest priority.
The linux/*.h file inclusions are basically for allowing to include sound/asound.h as is. It's a part of the Linux kernel code, and I don't think we'd add any extra ifdefs there just for non-Linux.
IOW, you'd need to prepare some compatible defines before including sound/asound.h if you need to compile for non-Linux systems.
I should have read this more carefully before preparing the attached patch... I changed asound.h.
The attached is what I needed to be able to build with
../configure --prefix=/tmp \ --enable-debug \ --disable-resmgr \ --disable-aload \ --disable-mixer \ --disable-pcm \ --disable-rawmidi \ --disable-hwdep \ --disable-seq \ --disable-ucm \ --disable-alisp \ --disable-old-symbols \ --disable-python \ --with-debug \ --without-libdl \ --without-librt
so not very useful, but at least it compiles. (This is on top of 0001-autotools-update-style.patch)
This isn't a way I supposed. In principle, you must not touch include/sound/*.h files. These are just copies from Linux kernel tree, thus they are managed there.
For any lacking linux/*.h files, you can create the own in somewhere locally by detecting in configure script. For example, keep a directory include-compat/linux/types.h, and add -Iinclude-compat for non-Linux systems.
Takashi
participants (3)
-
Clemens Ladisch -
Patrick Welche -
Takashi Iwai