[Buildroot] [PATCH 0 of 4] alsa-lib/alsa-utils autobuild fixes

[Buildroot] [PATCH 0 of 4] alsa-lib/alsa-utils autobuild fixes

[Thomas De Schampheleire]

Hi, 

This series fixes the alsa-lib / alsa-utils autobuild failures, most notably
seen on Blackfin FLAT, but the alsa-utils problem was also seen on ARM.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/alsa-lib/alsa-lib-avr32-bad-inline.patch                         |   0 
 package/alsa-lib/alsa-lib-no-mmu.patch                                   |   0 
 package/alsa-lib/alsa-lib-0003-dlmisc.patch                              |  59 +++++++++
 package/alsa-lib/alsa-lib-0004-conditional-enabling-of-libdl-in-m4.patch |  35 +++++
 package/alsa-utils/alsa-utils-0001-no-mmu.patch                          |  61 ++++++++++
 package/alsa-utils/alsa-utils.mk                                         |   1 +
 6 files changed, 156 insertions(+), 0 deletions(-)

[Buildroot] [PATCH 1 of 4] alsa-lib: add sequence number to existing patches

[Thomas De Schampheleire]

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---

diff --git a/package/alsa-lib/alsa-lib-avr32-bad-inline.patch b/package/alsa-lib/alsa-lib-0001-avr32-bad-inline.patch
rename from package/alsa-lib/alsa-lib-avr32-bad-inline.patch
rename to package/alsa-lib/alsa-lib-0001-avr32-bad-inline.patch
diff --git a/package/alsa-lib/alsa-lib-no-mmu.patch b/package/alsa-lib/alsa-lib-0002-no-mmu.patch
rename from package/alsa-lib/alsa-lib-no-mmu.patch
rename to package/alsa-lib/alsa-lib-0002-no-mmu.patch

[Buildroot] [PATCH 2 of 4] alsa-lib: add a fake dlfcn.h header if dynamic load is not supported

[Thomas De Schampheleire]

The FLAT GNU toolchain doesn't include the dlfcn.h header file.
Provide a fake header file dlmisc.h with enough declarations to make
alsa-lib happy.

Fixes
http://autobuild.buildroot.org/results/706/7069e1f43cbed745d65f7dd9904a3fff034530ac/build-end.log

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
[Thomas: change sequence number from 003 to 0003, update commit message ]
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/alsa-lib/alsa-lib-0003-dlmisc.patch |  59 ++++++++++++++++++++++++
 1 files changed, 59 insertions(+), 0 deletions(-)

diff --git a/package/alsa-lib/alsa-lib-0003-dlmisc.patch b/package/alsa-lib/alsa-lib-0003-dlmisc.patch
new file mode 100644
--- /dev/null
+++ b/package/alsa-lib/alsa-lib-0003-dlmisc.patch
@@ -0,0 +1,59 @@
+alsa-lib: dlmisc: Add a fake dl lib head file when dl lib is not supported by the toolchain.
+
+The FLAT GNU toolchain doesn't include the dlfcn.h header file.
+
+--- alsa-lib-1.0.26/src/mixer/simple_abst.c	2012-09-06 16:55:14.000000000 +0800
++++ alsa-lib-1.0.26.bak/src/mixer/simple_abst.c	2013-11-25 14:53:07.739275843 +0800
+@@ -34,7 +34,11 @@
+ #include <fcntl.h>
+ #include <sys/ioctl.h>
+ #include <math.h>
++#ifdef HAVE_LIBDL
+ #include <dlfcn.h>
++#else
++#include <dlmisc.h>
++#endif
+ #include "config.h"
+ #include "asoundlib.h"
+ #include "mixer_simple.h"
+--- alsa-lib-1.0.26/modules/mixer/simple/sbasedl.c	2012-09-06 16:55:14.000000000 +0800
++++ alsa-lib-1.0.26.bak/modules/mixer/simple/sbasedl.c	2013-11-25 14:53:40.871279553 +0800
+@@ -27,7 +27,11 @@
+ #include <fcntl.h>
+ #include <sys/ioctl.h>
+ #include <math.h>
++#ifdef HAVE_LIBDL
+ #include <dlfcn.h>
++#else
++#include <dlmisc.h>
++#endif
+ #include "config.h"
+ #include "asoundlib.h"
+ #include "mixer_abst.h"
+--- /dev/null	2013-11-25 21:32:41.194714253 +0800
++++ alsa-lib-1.0.26.bak/include/dlmisc.h	2013-11-25 15:03:11.031307047 +0800
+@@ -0,0 +1,24 @@
++/*
++ *   This library is free software; you can redistribute it and/or modify
++ *   it under the terms of the GNU Lesser General Public License as
++ *   published by the Free Software Foundation; either version 2.1 of
++ *   the License, or (at your option) any later version.
++ *
++ *   This program is distributed in the hope that it will be useful,
++ *   but WITHOUT ANY WARRANTY; without even the implied warranty of
++ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++ *   GNU Lesser General Public License for more details.
++ *
++ *   You should have received a copy of the GNU Lesser General Public
++ *   License along with this library; if not, write to the Free Software
++ *   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
++ *
++ */
++
++#ifndef __ALSA_DLMISC_H
++#define __ALSA_DLMISC_H
++
++#define RTLD_NOW	0x00002
++#define RTLD_GLOBAL	0x00100
++
++#endif

[Buildroot] [PATCH 2 of 4] alsa-lib: add a fake dlfcn.h header if dynamic load is not supported

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:

 > The FLAT GNU toolchain doesn't include the dlfcn.h header file.
 > Provide a fake header file dlmisc.h with enough declarations to make
 > alsa-lib happy.

 > Fixes
 > http://autobuild.buildroot.org/results/706/7069e1f43cbed745d65f7dd9904a3fff034530ac/build-end.log

 > Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
 > [Thomas: change sequence number from 003 to 0003, update commit message ]
 > Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

 > ---
 >  package/alsa-lib/alsa-lib-0003-dlmisc.patch |  59 ++++++++++++++++++++++++
 >  1 files changed, 59 insertions(+), 0 deletions(-)

 > diff --git a/package/alsa-lib/alsa-lib-0003-dlmisc.patch b/package/alsa-lib/alsa-lib-0003-dlmisc.patch
 > new file mode 100644
 > --- /dev/null
 > +++ b/package/alsa-lib/alsa-lib-0003-dlmisc.patch
 > @@ -0,0 +1,59 @@
 > +alsa-lib: dlmisc: Add a fake dl lib head file when dl lib is not supported by the toolchain.
 > +
 > +The FLAT GNU toolchain doesn't include the dlfcn.h header file.
 > +
 > +--- alsa-lib-1.0.26/src/mixer/simple_abst.c	2012-09-06 16:55:14.000000000 +0800
 > ++++ alsa-lib-1.0.26.bak/src/mixer/simple_abst.c	2013-11-25 14:53:07.739275843 +0800
 > +@@ -34,7 +34,11 @@
 > + #include <fcntl.h>
 > + #include <sys/ioctl.h>
 > + #include <math.h>
 > ++#ifdef HAVE_LIBDL
 > + #include <dlfcn.h>
 > ++#else
 > ++#include <dlmisc.h>

This is not a system header, so it should use #include "dlmisc.h".

What the the upstream status of this patch? We don't usually carry
feature patches in buildroot (besides backports).

Are those two defines the only part of dlfcn.h used? If so, how about
protection the pieces of code using them with #ifdef HAVE_LIBDL instead?


 > ++#endif
 > + #include "config.h"
 > + #include "asoundlib.h"
 > + #include "mixer_simple.h"
 > +--- alsa-lib-1.0.26/modules/mixer/simple/sbasedl.c	2012-09-06 16:55:14.000000000 +0800
 > ++++ alsa-lib-1.0.26.bak/modules/mixer/simple/sbasedl.c	2013-11-25 14:53:40.871279553 +0800
 > +@@ -27,7 +27,11 @@
 > + #include <fcntl.h>
 > + #include <sys/ioctl.h>
 > + #include <math.h>
 > ++#ifdef HAVE_LIBDL
 > + #include <dlfcn.h>
 > ++#else
 > ++#include <dlmisc.h>
 > ++#endif
 > + #include "config.h"
 > + #include "asoundlib.h"
 > + #include "mixer_abst.h"
 > +--- /dev/null	2013-11-25 21:32:41.194714253 +0800
 > ++++ alsa-lib-1.0.26.bak/include/dlmisc.h	2013-11-25 15:03:11.031307047 +0800
 > +@@ -0,0 +1,24 @@
 > ++/*
 > ++ *   This library is free software; you can redistribute it and/or modify
 > ++ *   it under the terms of the GNU Lesser General Public License as
 > ++ *   published by the Free Software Foundation; either version 2.1 of
 > ++ *   the License, or (at your option) any later version.
 > ++ *
 > ++ *   This program is distributed in the hope that it will be useful,
 > ++ *   but WITHOUT ANY WARRANTY; without even the implied warranty of
 > ++ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 > ++ *   GNU Lesser General Public License for more details.
 > ++ *
 > ++ *   You should have received a copy of the GNU Lesser General Public
 > ++ *   License along with this library; if not, write to the Free Software
 > ++ *   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
 > ++ *
 > ++ */
 > ++
 > ++#ifndef __ALSA_DLMISC_H
 > ++#define __ALSA_DLMISC_H
 > ++
 > ++#define RTLD_NOW	0x00002
 > ++#define RTLD_GLOBAL	0x00100
 > ++
 > ++#endif
 > _______________________________________________
 > buildroot mailing list
 > buildroot at busybox.net
 > http://lists.busybox.net/mailman/listinfo/buildroot


-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 2 of 4] alsa-lib: add a fake dlfcn.h header if dynamic load is not supported

[Thomas De Schampheleire]

Hi Peter,

Thanks for reviewing...

On Tue, Feb 18, 2014 at 12:28 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:
>
>  > The FLAT GNU toolchain doesn't include the dlfcn.h header file.
>  > Provide a fake header file dlmisc.h with enough declarations to make
>  > alsa-lib happy.
>
>  > Fixes
>  > http://autobuild.buildroot.org/results/706/7069e1f43cbed745d65f7dd9904a3fff034530ac/build-end.log
>
>  > Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
>  > [Thomas: change sequence number from 003 to 0003, update commit message ]
>  > Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
>
>  > ---
>  >  package/alsa-lib/alsa-lib-0003-dlmisc.patch |  59 ++++++++++++++++++++++++
>  >  1 files changed, 59 insertions(+), 0 deletions(-)
>
>  > diff --git a/package/alsa-lib/alsa-lib-0003-dlmisc.patch b/package/alsa-lib/alsa-lib-0003-dlmisc.patch
>  > new file mode 100644
>  > --- /dev/null
>  > +++ b/package/alsa-lib/alsa-lib-0003-dlmisc.patch
>  > @@ -0,0 +1,59 @@
>  > +alsa-lib: dlmisc: Add a fake dl lib head file when dl lib is not supported by the toolchain.
>  > +
>  > +The FLAT GNU toolchain doesn't include the dlfcn.h header file.
>  > +
>  > +--- alsa-lib-1.0.26/src/mixer/simple_abst.c 2012-09-06 16:55:14.000000000 +0800
>  > ++++ alsa-lib-1.0.26.bak/src/mixer/simple_abst.c     2013-11-25 14:53:07.739275843 +0800
>  > +@@ -34,7 +34,11 @@
>  > + #include <fcntl.h>
>  > + #include <sys/ioctl.h>
>  > + #include <math.h>
>  > ++#ifdef HAVE_LIBDL
>  > + #include <dlfcn.h>
>  > ++#else
>  > ++#include <dlmisc.h>
>
> This is not a system header, so it should use #include "dlmisc.h".

Correct, will fix.

>
> What the the upstream status of this patch? We don't usually carry
> feature patches in buildroot (besides backports).

It was submitted by Sonic Zhang, but without response:
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-November/069218.html
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069587.html

I can try to resubmit it after the above change and see what happens...

>
> Are those two defines the only part of dlfcn.h used? If so, how about
> protection the pieces of code using them with #ifdef HAVE_LIBDL instead?

Typical usage is:
./src/mixer/simple_abst.c:82:   h = snd_dlopen(xlib, RTLD_NOW);
./src/mixer/simple_abst.c:129:  h = snd_dlopen(xlib, RTLD_NOW|RTLD_GLOBAL);

where snd_dlopen is a wrapper:

/**
 * \brief Opens a dynamic library - ALSA wrapper for \c dlopen.
 * \param name name of the library, similar to \c dlopen.
 * \param mode mode flags, similar to \c dlopen.
 * \return Library handle if successful, otherwise \c NULL.
 *
 * This function can emulate dynamic linking for the static build of
 * the alsa-lib library. In that case, \p name is set to \c NULL.
 */
void *snd_dlopen(const char *name, int mode)
{
#ifndef PIC
        if (name == NULL)
                return &snd_dlsym_start;
#else
#ifdef HAVE_LIBDL
        if (name == NULL) {
                static const char * self = NULL;
                if (self == NULL) {
                        Dl_info dlinfo;
                        if (dladdr(snd_dlopen, &dlinfo) > 0)
                                self = dlinfo.dli_fname;
                }
                name = self;
        }
#endif
#endif
#ifdef HAVE_LIBDL
        return dlopen(name, mode);
#else
        return NULL;
#endif
}

Due to the special PIC exception, I don't think we can remove the call
to snd_dlopen() entirely if !HAVE_LIBDL.

Best regards,
Thomas

[Buildroot] [PATCH 2 of 4] alsa-lib: add a fake dlfcn.h header if dynamic load is not supported

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:

Hi,

 >> What the the upstream status of this patch? We don't usually carry
 >> feature patches in buildroot (besides backports).

 > It was submitted by Sonic Zhang, but without response:
 > http://mailman.alsa-project.org/pipermail/alsa-devel/2013-November/069218.html
 > http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069587.html

Ok :/

 > I can try to resubmit it after the above change and see what happens...

 >> 
 >> Are those two defines the only part of dlfcn.h used? If so, how about
 >> protection the pieces of code using them with #ifdef HAVE_LIBDL instead?

 > Typical usage is:
 > ./src/mixer/simple_abst.c:82:   h = snd_dlopen(xlib, RTLD_NOW);
 > ./src/mixer/simple_abst.c:129:  h = snd_dlopen(xlib, RTLD_NOW|RTLD_GLOBAL);

 > where snd_dlopen is a wrapper:

Ok, why don't we then just stick:

#ifndef RTLD_NOW
#define RTLD_NOW 0
#endif

#ifndef RTLD_GLOBAL
#define RTLD_GLOBAL 0
#endif

To the header where snd_dlopen is defined?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 2 of 4] alsa-lib: add a fake dlfcn.h header if dynamic load is not supported

[Thomas De Schampheleire]

On Tue, Feb 18, 2014 at 3:14 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:
>
> Hi,
>
>  >> What the the upstream status of this patch? We don't usually carry
>  >> feature patches in buildroot (besides backports).
>
>  > It was submitted by Sonic Zhang, but without response:
>  > http://mailman.alsa-project.org/pipermail/alsa-devel/2013-November/069218.html
>  > http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069587.html
>
> Ok :/
>
>  > I can try to resubmit it after the above change and see what happens...
>
>  >>
>  >> Are those two defines the only part of dlfcn.h used? If so, how about
>  >> protection the pieces of code using them with #ifdef HAVE_LIBDL instead?
>
>  > Typical usage is:
>  > ./src/mixer/simple_abst.c:82:   h = snd_dlopen(xlib, RTLD_NOW);
>  > ./src/mixer/simple_abst.c:129:  h = snd_dlopen(xlib, RTLD_NOW|RTLD_GLOBAL);
>
>  > where snd_dlopen is a wrapper:
>
> Ok, why don't we then just stick:
>
> #ifndef RTLD_NOW
> #define RTLD_NOW 0
> #endif
>
> #ifndef RTLD_GLOBAL
> #define RTLD_GLOBAL 0
> #endif
>
> To the header where snd_dlopen is defined?

That could be done, but we still need something like:
#ifdef HAVE_LIBDL
#include <dlfcn.h>
#endif

right?

Best regards,
Thomas

[Buildroot] [PATCH 2 of 4] alsa-lib: add a fake dlfcn.h header if dynamic load is not supported

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:

Hi,

 >> > where snd_dlopen is a wrapper:
 >> 
 >> Ok, why don't we then just stick:
 >> 
 >> #ifndef RTLD_NOW
 >> #define RTLD_NOW 0
 >> #endif
 >> 
 >> #ifndef RTLD_GLOBAL
 >> #define RTLD_GLOBAL 0
 >> #endif
 >> 
 >> To the header where snd_dlopen is defined?

 > That could be done, but we still need something like:
 > #ifdef HAVE_LIBDL
 > #include <dlfcn.h>
 > #endif

Ehh yes, but atleast we don't need to introduce a new file.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 3 of 4] alsa-lib: add patch to remove hardcoded -ldl

[Thomas De Schampheleire]

The AM_PATH_ALSA macro in utils/alsa.m4 unconditionally uses -ldl. This
breaks compilation of alsa-utils (and probably other packages using this
macro) for targets that do not support dynamic loading, such as for
Blackfin FLAT binaries.

This patch updates the macro to check if dlopen is available, and use that
result to conditionally add -ldl to the list of libraries.

Fixes
http://autobuild.buildroot.org/results/de2/de286880973be956f6c504aa9a758171d6f49674/build-end.log

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/alsa-lib/alsa-lib-0004-conditional-enabling-of-libdl-in-m4.patch |  35 ++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/package/alsa-lib/alsa-lib-0004-conditional-enabling-of-libdl-in-m4.patch b/package/alsa-lib/alsa-lib-0004-conditional-enabling-of-libdl-in-m4.patch
new file mode 100644
--- /dev/null
+++ b/package/alsa-lib/alsa-lib-0004-conditional-enabling-of-libdl-in-m4.patch
@@ -0,0 +1,35 @@
+alsa-lib: conditionally enable libdl in AM_PATH_ALSA m4 macro
+
+The AM_PATH_ALSA macro in utils/alsa.m4 unconditionally uses -ldl. This
+breaks compilation of alsa-utils (and probably other packages using this
+macro) for targets that do not support dynamic loading, such as for
+Blackfin FLAT binaries.
+
+This patch updates the macro to check if dlopen is available, and use that
+result to conditionally add -ldl to the list of libraries.
+
+Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
+
+---
+
+diff --git a/utils/alsa.m4 b/utils/alsa.m4
+--- a/utils/alsa.m4
++++ b/utils/alsa.m4
+@@ -44,6 +44,8 @@ if test "$alsa_inc_prefix" != "" ; then
+ fi
+ AC_MSG_RESULT($ALSA_CFLAGS)
+ 
++AC_CHECK_LIB(c, dlopen, LIBDL="", [AC_CHECK_LIB(dl, dlopen, LIBDL="-ldl")])
++
+ dnl add any special lib dirs
+ AC_MSG_CHECKING(for ALSA LDFLAGS)
+ if test "$alsa_prefix" != "" ; then
+@@ -52,7 +54,7 @@ if test "$alsa_prefix" != "" ; then
+ fi
+ 
+ dnl add the alsa library
+-ALSA_LIBS="$ALSA_LIBS -lasound -lm -ldl -lpthread"
++ALSA_LIBS="$ALSA_LIBS -lasound -lm $LIBDL -lpthread"
+ LIBS="$ALSA_LIBS $LIBS"
+ AC_MSG_RESULT($ALSA_LIBS)
+ 

[Buildroot] [PATCH 4 of 4] alsa-utils: fix build on no-mmu targets

[Thomas De Schampheleire]

alsa-utils uses fork, which doesn't work on targets without mmu, such as
Blackfin. Apply a patch by the Blackfin developers to fix this.

Fixes
http://autobuild.buildroot.org/results/9f8/9f8e572c9f1c677155cc7d1828371bcf572ff878

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/alsa-utils/alsa-utils-0001-no-mmu.patch |  61 ++++++++++++++++++++
 package/alsa-utils/alsa-utils.mk                |   1 +
 2 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/package/alsa-utils/alsa-utils-0001-no-mmu.patch b/package/alsa-utils/alsa-utils-0001-no-mmu.patch
new file mode 100644
--- /dev/null
+++ b/package/alsa-utils/alsa-utils-0001-no-mmu.patch
@@ -0,0 +1,61 @@
+Signed-off-by: Aaron Wu <Aaron.wu@analog.com>
+
+Add no-mmu support for alsa-utils mainly for Blackfin
+---
+ alsactl/init_utils_run.c |    4 ++++
+ alsaloop/alsaloop.c      |    8 ++++++++
+ configure.in             |    1 +
+ 3 files changed, 13 insertions(+)
+
+diff --git a/alsactl/init_utils_run.c b/alsactl/init_utils_run.c
+--- a/alsactl/init_utils_run.c
++++ b/alsactl/init_utils_run.c
+@@ -89,7 +89,11 @@ int run_program0(struct space *space,
+ 		argv[0] = program;
+ 	}
+ 
++	#ifdef HAVE_FORK
+ 	pid = fork();
++	#else
++	pid = vfork();
++	#endif
+ 	switch(pid) {
+ 	case 0:
+ 		/* child closes parent ends of pipes */
+diff --git a/alsaloop/alsaloop.c b/alsaloop/alsaloop.c
+--- a/alsaloop/alsaloop.c
++++ b/alsaloop/alsaloop.c
+@@ -850,14 +850,22 @@ int main(int argc, char *argv[])
+ 			logit(LOG_CRIT, "daemon() failed: %s\n", strerror(errno));
+ 			exit(EXIT_FAILURE);
+ 		}
++		#ifdef HAVE_FORK
+ 		i = fork();
++		#else
++		i = vfork();
++		#endif
+ 		if (i < 0) {
+ 			logit(LOG_CRIT, "fork() failed: %s\n", strerror(errno));
+ 			exit(EXIT_FAILURE);
+ 		}
+ 		if (i > 0) {
+ 			/* wait(&i); */
++			#ifdef HAVE_FORK
+ 			exit(EXIT_SUCCESS);
++			#else
++			_exit(EXIT_SUCCESS);
++			#endif
+ 		}
+ 	}
+ 
+diff --git a/configure.in b/configure.in
+--- a/configure.in
++++ b/configure.in
+@@ -23,6 +23,7 @@ then
+   AC_MSG_RESULT($CC)
+ fi
+ 
++AC_CHECK_FUNC([fork])
+ AC_PROG_CC
+ dnl AC_PROG_CXX
+ AC_PROG_INSTALL
diff --git a/package/alsa-utils/alsa-utils.mk b/package/alsa-utils/alsa-utils.mk
--- a/package/alsa-utils/alsa-utils.mk
+++ b/package/alsa-utils/alsa-utils.mk
@@ -9,6 +9,7 @@ ALSA_UTILS_SOURCE = alsa-utils-$(ALSA_UT
 ALSA_UTILS_SITE = http://alsa.cybermirror.org/utils
 ALSA_UTILS_LICENSE = GPLv2
 ALSA_UTILS_LICENSE_FILES = COPYING
+ALSA_UTILS_AUTORECONF = YES
 ALSA_UTILS_INSTALL_STAGING = YES
 ALSA_UTILS_DEPENDENCIES = host-gettext host-pkgconf alsa-lib \
 	$(if $(BR2_PACKAGE_NCURSES),ncurses)

[Buildroot] [PATCH 4 of 4] alsa-utils: fix build on no-mmu targets

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:

 > alsa-utils uses fork, which doesn't work on targets without mmu, such as
 > Blackfin. Apply a patch by the Blackfin developers to fix this.

 > Fixes
 > http://autobuild.buildroot.org/results/9f8/9f8e572c9f1c677155cc7d1828371bcf572ff878

 > Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

What is the upstream status of this?

 > ---
 >  package/alsa-utils/alsa-utils-0001-no-mmu.patch |  61 ++++++++++++++++++++
 >  package/alsa-utils/alsa-utils.mk                |   1 +
 >  2 files changed, 62 insertions(+), 0 deletions(-)

 > diff --git a/package/alsa-utils/alsa-utils-0001-no-mmu.patch b/package/alsa-utils/alsa-utils-0001-no-mmu.patch
 > new file mode 100644
 > --- /dev/null
 > +++ b/package/alsa-utils/alsa-utils-0001-no-mmu.patch
 > @@ -0,0 +1,61 @@
 > +Signed-off-by: Aaron Wu <Aaron.wu@analog.com>
 > +
 > +Add no-mmu support for alsa-utils mainly for Blackfin
 > +---
 > + alsactl/init_utils_run.c |    4 ++++
 > + alsaloop/alsaloop.c      |    8 ++++++++
 > + configure.in             |    1 +
 > + 3 files changed, 13 insertions(+)
 > +
 > +diff --git a/alsactl/init_utils_run.c b/alsactl/init_utils_run.c
 > +--- a/alsactl/init_utils_run.c
 > ++++ b/alsactl/init_utils_run.c
 > +@@ -89,7 +89,11 @@ int run_program0(struct space *space,
 > + 		argv[0] = program;
 > + 	}
 > + 
 > ++	#ifdef HAVE_FORK
 > + 	pid = fork();
 > ++	#else
 > ++	pid = vfork();
 > ++	#endif

I would be a lot happier with a patch simply doing s/fork/vfork/. If
vfork is safe to use, we might as well use it everywhere - And if not,
we shouldn't do it on nommu either.


 > + 	switch(pid) {
 > + 	case 0:
 > + 		/* child closes parent ends of pipes */

I'm far from a vfork expert, but as parent and child shares stack, how
does it work with both calling close() on the pipes?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 4 of 4] alsa-utils: fix build on no-mmu targets

[Thomas De Schampheleire]

Hi Peter,

On Tue, Feb 18, 2014 at 12:40 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:
>
>  > alsa-utils uses fork, which doesn't work on targets without mmu, such as
>  > Blackfin. Apply a patch by the Blackfin developers to fix this.
>
>  > Fixes
>  > http://autobuild.buildroot.org/results/9f8/9f8e572c9f1c677155cc7d1828371bcf572ff878
>
>  > Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
>
> What is the upstream status of this?

This has also been submitted without response:
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069749.html

>
>  > ---
>  >  package/alsa-utils/alsa-utils-0001-no-mmu.patch |  61 ++++++++++++++++++++
>  >  package/alsa-utils/alsa-utils.mk                |   1 +
>  >  2 files changed, 62 insertions(+), 0 deletions(-)
>
>  > diff --git a/package/alsa-utils/alsa-utils-0001-no-mmu.patch b/package/alsa-utils/alsa-utils-0001-no-mmu.patch
>  > new file mode 100644
>  > --- /dev/null
>  > +++ b/package/alsa-utils/alsa-utils-0001-no-mmu.patch
>  > @@ -0,0 +1,61 @@
>  > +Signed-off-by: Aaron Wu <Aaron.wu@analog.com>
>  > +
>  > +Add no-mmu support for alsa-utils mainly for Blackfin
>  > +---
>  > + alsactl/init_utils_run.c |    4 ++++
>  > + alsaloop/alsaloop.c      |    8 ++++++++
>  > + configure.in             |    1 +
>  > + 3 files changed, 13 insertions(+)
>  > +
>  > +diff --git a/alsactl/init_utils_run.c b/alsactl/init_utils_run.c
>  > +--- a/alsactl/init_utils_run.c
>  > ++++ b/alsactl/init_utils_run.c
>  > +@@ -89,7 +89,11 @@ int run_program0(struct space *space,
>  > +            argv[0] = program;
>  > +    }
>  > +
>  > ++   #ifdef HAVE_FORK
>  > +    pid = fork();
>  > ++   #else
>  > ++   pid = vfork();
>  > ++   #endif
>
> I would be a lot happier with a patch simply doing s/fork/vfork/. If
> vfork is safe to use, we might as well use it everywhere - And if not,
> we shouldn't do it on nommu either.

It's been done before in commits
c2abc61d028b9e9cc602108ce1ad03942092bed2 and
d4b074554faa9451630cde47eb8378a8b0803252.
But it's far from pretty code, true.

>
>
>  > +    switch(pid) {
>  > +    case 0:
>  > +            /* child closes parent ends of pipes */
>
> I'm far from a vfork expert, but as parent and child shares stack, how
> does it work with both calling close() on the pipes?

I'm no vfork expert either, but, from the manpage of vfork:

       vfork() differs from fork(2) in that the calling thread  is  sus?
       pended  until  the  child terminates (either normally, by calling
       _exit(2), or abnormally, after delivery of a fatal signal), or it
       makes  a  call  to execve(2).  Until that point, the child shares
       all memory with its parent, including the stack.  The child  must
       not  return  from  the  current function or call exit(3), but may
       call _exit(2).

       As with fork(2), the child process created  by  vfork()  inherits
       copies  of various of the caller's process attributes (e.g., file
       descriptors, signal dispositions, and current working directory);
       the  vfork()  call  differs  only in the treatment of the virtual
       address space, as described above.


so the behavior of file descriptors seems the same as in fork.
The child basically does:
    setup input/output (pipes)
    execv()

The parent does:
    setup input/output (pipes)
    read output from child and store it

As the parent is blocked during the execution of the child, the child
will first fill the pipe with its data, then exit, and only then the
parent will read it. This is unlike the fork case where parent could
start reading data while the child is writing into the pipe.

This code (run_program) is executed when a PROGRAM directive is
encountered in the alsactl configuration. From 'man alsactl_init':

       PROGRAM
           Execute external program. The key is true, if the program
           returns without exit code zero. The whole event environment
           is available to the executed program. The program's output
           printed to stdout is available for the RESULT key.


Based on this, and the code described above, it is not a problem that
the parent is blocked during execution of the child, in run_program.
I therefore think the vfork should work (untested).


The other introduction of fork in alsaloop/alsaloop.c is basically:
if (daemonize) {
    daemon();
    fork();
    if (parent) { exit() };
}

So the child is the only one doing actual work, there is no
communication between parent and child.
Also here, I believe the vfork change is acceptable...


What should we do with your comment on the HAVE_FORK check?
I'm not sure what upstream would think of either alternative...

Thanks,
Thomas

[Buildroot] [PATCH 4 of 4] alsa-utils: fix build on no-mmu targets

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Tue, 18 Feb 2014 14:47:45 +0100, Thomas De Schampheleire wrote:

> > I'm far from a vfork expert, but as parent and child shares stack, how
> > does it work with both calling close() on the pipes?
> 
> I'm no vfork expert either, but, from the manpage of vfork:
> 
>        vfork() differs from fork(2) in that the calling thread  is  sus?
>        pended  until  the  child terminates (either normally, by calling
>        _exit(2), or abnormally, after delivery of a fatal signal), or it
>        makes  a  call  to execve(2).  Until that point, the child shares
>        all memory with its parent, including the stack.  The child  must
>        not  return  from  the  current function or call exit(3), but may
>        call _exit(2).
> 
>        As with fork(2), the child process created  by  vfork()  inherits
>        copies  of various of the caller's process attributes (e.g., file
>        descriptors, signal dispositions, and current working directory);
>        the  vfork()  call  differs  only in the treatment of the virtual
>        address space, as described above.
> 
> 
> so the behavior of file descriptors seems the same as in fork.
> The child basically does:
>     setup input/output (pipes)
>     execv()
> 
> The parent does:
>     setup input/output (pipes)
>     read output from child and store it
> 
> As the parent is blocked during the execution of the child, the child
> will first fill the pipe with its data, then exit, and only then the
> parent will read it. This is unlike the fork case where parent could
> start reading data while the child is writing into the pipe.
> 
> This code (run_program) is executed when a PROGRAM directive is
> encountered in the alsactl configuration. From 'man alsactl_init':
> 
>        PROGRAM
>            Execute external program. The key is true, if the program
>            returns without exit code zero. The whole event environment
>            is available to the executed program. The program's output
>            printed to stdout is available for the RESULT key.
> 
> 
> Based on this, and the code described above, it is not a problem that
> the parent is blocked during execution of the child, in run_program.
> I therefore think the vfork should work (untested).

I believe that the problem Peter is pointing at is not really that the
parent is blocked until the child execs, but rather that the child
shares all its data (including global and local variables) with the
parent, until the child execs.

Example:

	int foo = 2;

	pid = fork();
	if (pid == 0) {
		foo = 3;
		_exit(0);
	}
	else {
		sleep(1);
		printf("%d\n", foo);
	}

This will show "2" because the data is not shared between the child and
parent with fork().

Try the same example after replacing fork() with vfork(). The program
will show "3".

You can try the example above, it really shows the behavior I'm
explaining.

This means that if a single variable is modified by the child before it
exits or execs, then fork() cannot be replaced by vfork().

Now, I looked again at the alsa-utils code in alsactl/init_utils_run.c,
and I indeed don't see any variable being changed. Only file
descriptors are changed.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 4 of 4] alsa-utils: fix build on no-mmu targets

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:

Hi,

 > Hi Peter,
 > On Tue, Feb 18, 2014 at 12:40 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
 >>>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:
 >> 
 >> > alsa-utils uses fork, which doesn't work on targets without mmu, such as
 >> > Blackfin. Apply a patch by the Blackfin developers to fix this.
 >> 
 >> > Fixes
 >> > http://autobuild.buildroot.org/results/9f8/9f8e572c9f1c677155cc7d1828371bcf572ff878
 >> 
 >> > Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
 >> 
 >> What is the upstream status of this?

 > This has also been submitted without response:
 > http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069749.html

:/

 >> I would be a lot happier with a patch simply doing s/fork/vfork/. If
 >> vfork is safe to use, we might as well use it everywhere - And if not,
 >> we shouldn't do it on nommu either.

 > It's been done before in commits
 > c2abc61d028b9e9cc602108ce1ad03942092bed2 and
 > d4b074554faa9451630cde47eb8378a8b0803252.
 > But it's far from pretty code, true.

My point is that if nommu follows a different code path than "normal"
Linux (and upstream doesn't test on nommu), then it is bound to break
sooner or later.

 >> > +    switch(pid) {
 >> > +    case 0:
 >> > +            /* child closes parent ends of pipes */
 >> 
 >> I'm far from a vfork expert, but as parent and child shares stack, how
 >> does it work with both calling close() on the pipes?

 > I'm no vfork expert either, but, from the manpage of vfork:

 >        vfork() differs from fork(2) in that the calling thread  is  sus?
 >        pended  until  the  child terminates (either normally, by calling
 >        _exit(2), or abnormally, after delivery of a fatal signal), or it
 >        makes  a  call  to execve(2).  Until that point, the child shares
 >        all memory with its parent, including the stack.  The child  must
 >        not  return  from  the  current function or call exit(3), but may
 >        call _exit(2).

 >        As with fork(2), the child process created  by  vfork()  inherits
 >        copies  of various of the caller's process attributes (e.g., file
 >        descriptors, signal dispositions, and current working directory);
 >        the  vfork()  call  differs  only in the treatment of the virtual
 >        address space, as described above.

Ahh yes, I forgot that the parent thread is stalled. Then the only
difference is that the devnull variable gets assigned to, but as that is
not accessed in the parent it shouldn't matter.


 > so the behavior of file descriptors seems the same as in fork.
 > The child basically does:
 >     setup input/output (pipes)
 >     execv()

 > The parent does:
 >     setup input/output (pipes)
 >     read output from child and store it

 > As the parent is blocked during the execution of the child, the child
 > will first fill the pipe with its data, then exit, and only then the
 > parent will read it. This is unlike the fork case where parent could
 > start reading data while the child is writing into the pipe.

The parent will actually get unblocked as soon as the child calls execv,
but yes.

 > The other introduction of fork in alsaloop/alsaloop.c is basically:
 > if (daemonize) {
 >     daemon();
 >     fork();
 >     if (parent) { exit() };
 > }

 > So the child is the only one doing actual work, there is no
 > communication between parent and child.
 > Also here, I believe the vfork change is acceptable...

But does the parent ever get to run so it can exit to the shell while
the child runs? I guess not.


 > What should we do with your comment on the HAVE_FORK check?
 > I'm not sure what upstream would think of either alternative...

As I said above, I really dislike having a seperate (largely untested)
codepath for !mmu if not absolutely needed.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 0 of 4] alsa-lib/alsa-utils autobuild fixes

[Thomas De Schampheleire]

On Wed, Feb 12, 2014 at 5:55 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi,
>
> This series fixes the alsa-lib / alsa-utils autobuild failures, most notably
> seen on Blackfin FLAT, but the alsa-utils problem was also seen on ARM.
>
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
>
> ---
>  package/alsa-lib/alsa-lib-avr32-bad-inline.patch                         |   0
>  package/alsa-lib/alsa-lib-no-mmu.patch                                   |   0
>  package/alsa-lib/alsa-lib-0003-dlmisc.patch                              |  59 +++++++++
>  package/alsa-lib/alsa-lib-0004-conditional-enabling-of-libdl-in-m4.patch |  35 +++++
>  package/alsa-utils/alsa-utils-0001-no-mmu.patch                          |  61 ++++++++++
>  package/alsa-utils/alsa-utils.mk                                         |   1 +
>  6 files changed, 156 insertions(+), 0 deletions(-)

Ping ?

[Buildroot] [PATCH 0 of 4] alsa-lib/alsa-utils autobuild fixes

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Wed, 12 Feb 2014 17:55:40 +0100, Thomas De Schampheleire wrote:

> This series fixes the alsa-lib / alsa-utils autobuild failures, most notably
> seen on Blackfin FLAT, but the alsa-utils problem was also seen on ARM.
> 
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Would you mind resending your series by taking into account Peter's
comment for PATCH 2, and then replace your PATCH 4 by a patch that
simply disallow alsa-utils on !MMU systems?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 0 of 4] alsa-lib/alsa-utils autobuild fixes

[Thomas De Schampheleire]

On Sat, Feb 22, 2014 at 7:23 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Wed, 12 Feb 2014 17:55:40 +0100, Thomas De Schampheleire wrote:
>
>> This series fixes the alsa-lib / alsa-utils autobuild failures, most notably
>> seen on Blackfin FLAT, but the alsa-utils problem was also seen on ARM.
>>
>> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
>
> Would you mind resending your series by taking into account Peter's
> comment for PATCH 2, and then replace your PATCH 4 by a patch that
> simply disallow alsa-utils on !MMU systems?
>

Yes, working on it...