alsa-lib/alsa-utils autobuild fixes
PATCH 1/1 alsa-lib/alsa-utils autobuild fixes
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.
--- 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(-)
PATCH 1/1 alsa-lib: add sequence number to existing patches
---
package/alsa-lib/alsa-lib-0001-avr32-bad-inline.patch renamed from package/alsa-lib/alsa-lib-avr32-bad-inline.patch +0 -0
package/alsa-lib/alsa-lib-0002-no-mmu.patch renamed from package/alsa-lib/alsa-lib-no-mmu.patch +0 -0
PATCH 1/1 alsa-lib: add a fake dlfcn.h header if dynamic load is not supported
In reply to Thomas De SchampheleireThe 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
--- package/alsa-lib/alsa-lib-0003-dlmisc.patch | 59 ++++++++++++++++++++++++ 1 files changed, 59 insertions(+), 0 deletions(-)
package/alsa-lib/alsa-lib-0003-dlmisc.patch new file +59 -0
@@ -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
PATCH 1/1 alsa-lib: add a fake dlfcn.h header if dynamic load is not supported
Quoted 26 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> writes:
The FLAT GNU toolchain doesn't include the
dlfcn.hheader file. Provide a fake header filedlmisc.hwith enough declarations to make alsa-lib happy.Fixes
http://autobuild.buildroot.org/results/706/7069e1f43cbed745d65f7dd9904a3fff034530ac/build-end.logSigned-off-by Sonic Zhang <[email protected]>[Thomas: change sequence number from 003 to 0003, update commit message ]Signed-off-by Thomas De Schampheleire <[email protected]>--- package/alsa-lib/alsa-lib-0003-dlmisc.patch | 59 ++++++++++++++++++++++++ 1 files changed, 59 insertions(+), 0 deletions(-)package/alsa-lib/alsa-lib-0003-dlmisc.patch new file +4
-0@@ -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. +
package/alsa-lib/alsa-lib-0003-dlmisc.patch line 14
Quoted 10 lines
package/alsa-lib/alsa-lib-0003-dlmisc.patch new file +10
-0+--- 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?
Quoted 49 lines
package/alsa-lib/alsa-lib-0003-dlmisc.patch new file +45
-0++#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
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 alsa-lib: add a fake dlfcn.h header if dynamic load is not supported
Hi Peter,
Thanks for reviewing...
Quoted 30 lines · Peter Korsgaard
Quoted 30 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> writes:
The FLAT GNU toolchain doesn't include the
dlfcn.hheader file. Provide a fake header filedlmisc.hwith enough declarations to make alsa-lib happy.Fixes
http://autobuild.buildroot.org/results/706/7069e1f43cbed745d65f7dd9904a3fff034530ac/build-end.logSigned-off-by Sonic Zhang <[email protected]>[Thomas: change sequence number from 003 to 0003, update commit message ]Signed-off-by Thomas De Schampheleire <[email protected]>--- package/alsa-lib/alsa-lib-0003-dlmisc.patch | 59 ++++++++++++++++++++++++ 1 files changed, 59 insertions(+), 0 deletions(-)package/alsa-lib/alsa-lib-0003-dlmisc.patch new file +8
-0@@ -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>
Quoted 8 lines
package/alsa-lib/alsa-lib-0003-dlmisc.patch line 14
Quoted 6 lines
package/alsa-lib/alsa-lib-0003-dlmisc.patch new file +6
-0+ #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.
Quoted 3 lines
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...
Quoted 3 lines
Are those two defines the only part of
dlfcn.hused? If so, how about protection the pieces of code using them with #ifdefHAVE_LIBDLinstead?
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
PATCH 1/1 alsa-lib: add a fake dlfcn.h header if dynamic load is not supported
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> writes:
Hi,
Quoted 6 lines
Quoted 2 lines
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 :/
Quoted 11 lines
I can try to resubmit it after the above change and see what happens...
Quoted 3 lines
Are those two defines the only part of
dlfcn.hused? If so, how about protection the pieces of code using them with #ifdefHAVE_LIBDLinstead?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_dlopenis 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?
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 alsa-lib: add a fake dlfcn.h header if dynamic load is not supported
Quoted 31 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> writes:
Hi,
Quoted 6 lines
Quoted 2 lines
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.htmlOk :/
Quoted 11 lines
I can try to resubmit it after the above change and see what happens...
Quoted 3 lines
Are those two defines the only part of
dlfcn.hused? If so, how about protection the pieces of code using them with #ifdefHAVE_LIBDLinstead?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_dlopenis a wrapper:Ok, why don't we then just stick:
#ifndef
RTLD_NOW
#defineRTLD_NOW0
#endif
Quoted 5 lines
#ifndef
RTLD_GLOBAL
#defineRTLD_GLOBAL0
#endifTo the header where
snd_dlopenis defined?
That could be done, but we still need something like:
#ifdef HAVE_LIBDL
#include <dlfcn.h>
#endif
right?
Best regards,
Thomas
PATCH 1/1 alsa-lib: add a fake dlfcn.h header if dynamic load is not supported
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> writes:
Hi,
Quoted 12 lines
Quoted 12 lines
Quoted 1 line
where
snd_dlopenis a wrapper:Ok, why don't we then just stick:
#ifndef
RTLD_NOW
#defineRTLD_NOW0
#endif#ifndef
RTLD_GLOBAL
#defineRTLD_GLOBAL0
#endif
Quoted 6 lines
Quoted 1 line
To the header where
snd_dlopenis defined?That could be done, but we still need something like:
#ifdefHAVE_LIBDL
#include <dlfcn.h>
#endif
Ehh yes, but atleast we don't need to introduce a new file.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 alsa-lib: add patch to remove hardcoded -ldl
In reply to Thomas De SchampheleireThe 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
--- package/alsa-lib/alsa-lib-0004-conditional-enabling-of-libdl-in-m4.patch | 35 ++++++++++ 1 files changed, 35 insertions(+), 0 deletions(-)
package/alsa-lib/alsa-lib-0004-conditional-enabling-of-libdl-in-m4.patch new file +35 -0
@@ -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 <[email protected]> + +--- + +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) +
PATCH 1/1 alsa-utils: fix build on no-mmu targets
In reply to Thomas De Schampheleirealsa-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
--- package/alsa-utils/alsa-utils-0001-no-mmu.patch | 61 ++++++++++++++++++++ package/alsa-utils/alsa-utils.mk | 1 + 2 files changed, 62 insertions(+), 0 deletions(-)
package/alsa-utils/alsa-utils-0001-no-mmu.patch new file +61 -0
@@ -0,0 +1,61 @@ +Signed-off-by: Aaron Wu <[email protected]> + +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
package/alsa-utils/alsa-utils.mk +1 -0
@@ -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)
PATCH 1/1 alsa-utils: fix build on no-mmu targets
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> 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/9f8e572c9f1c677155cc7d1828371bcf572ff878Signed-off-by Thomas De Schampheleire <[email protected]>
What is the upstream status of this?
Quoted 21 lines
--- package/alsa-utils/alsa-utils-0001-no-mmu.patch | 61 ++++++++++++++++++++ package/alsa-utils/alsa-utils.mk | 1 + 2 files changed, 62 insertions(+), 0 deletions(-)package/alsa-utils/alsa-utils-0001-no-mmu.patch new file +11
-0@@ -0,0 +1,61 @@ +Signed-off-by: Aaron Wu <[email protected]> + +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
package/alsa-utils/alsa-utils-0001-no-mmu.patch line 21
Quoted 10 lines
package/alsa-utils/alsa-utils-0001-no-mmu.patch new file +10
-0++++ 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.
package/alsa-utils/alsa-utils-0001-no-mmu.patch line 24
Quoted 3 lines
package/alsa-utils/alsa-utils-0001-no-mmu.patch new file +3
-0+ 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?
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 alsa-utils: fix build on no-mmu targets
Hi Peter,
Quoted 11 lines · Peter Korsgaard
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> 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/9f8e572c9f1c677155cc7d1828371bcf572ff878Signed-off-by Thomas De Schampheleire <[email protected]>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
Quoted 28 lines
Quoted 28 lines
--- package/alsa-utils/alsa-utils-0001-no-mmu.patch | 61 ++++++++++++++++++++ package/alsa-utils/alsa-utils.mk | 1 + 2 files changed, 62 insertions(+), 0 deletions(-)package/alsa-utils/alsa-utils-0001-no-mmu.patch new file +17
-0@@ -0,0 +1,61 @@ +Signed-off-by: Aaron Wu <[email protected]> + +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
Quoted 8 lines
package/alsa-utils/alsa-utils-0001-no-mmu.patch line 21
Quoted 4 lines
package/alsa-utils/alsa-utils-0001-no-mmu.patch new file +4
-0+ pid = fork(); ++ #else ++ pid = vfork(); ++ #endifI 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 commitsc2abc61d028b9e9cc602108ce1ad03942092bed2 andd4b074554faa9451630cde47eb8378a8b0803252.
But it's far from pretty code, true.
Quoted 8 lines
package/alsa-utils/alsa-utils-0001-no-mmu.patch line 24
Quoted 5 lines
package/alsa-utils/alsa-utils-0001-no-mmu.patch new file +3
-0+ 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
PATCH 1/1 alsa-utils: fix build on no-mmu targets
Dear Thomas De Schampheleire,
Quoted 44 lines · Thomas De Schampheleire
Quoted 2 lines
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); thevfork()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 itAs 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 'manalsactl_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.
Quoted 3 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 alsa-utils: fix build on no-mmu targets
In reply to Thomas De SchampheleireQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> writes:
Hi,
Quoted 10 lines
Hi Peter,
Quoted 8 lines · Peter Korsgaard
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> 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
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Thomas De Schampheleire <[email protected]>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
:/
Quoted 8 lines
Quoted 3 lines
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
c2abc61d028b9e9cc602108ce1ad03942092bed2andd4b074554faa9451630cde47eb8378a8b0803252.
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.
Quoted 17 lines
Quoted 6 lines
package/alsa-utils/alsa-utils-0001-no-mmu.patch line 24
Quoted 3 lines
package/alsa-utils/alsa-utils-0001-no-mmu.patch new file +3
-0+ 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).
Quoted 5 lines
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); thevfork()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.
Quoted 5 lines
so the behavior of file descriptors seems the same as in fork. The child basically does:
setup input/output (pipes)
execv()
Quoted 8 lines
The parent does:
setup input/output (pipes)
read output from child and store itAs 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.
Quoted 10 lines
The other introduction of fork in
alsaloop/alsaloop.cis 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.
Quoted 2 lines
What should we do with your comment on the
HAVE_FORKcheck? 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.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 alsa-lib/alsa-utils autobuild fixes
In reply to Thomas De SchampheleireQuoted 7 lines · 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 <[email protected]>
Quoted 8 lines
--- 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 ?
PATCH 1/1 alsa-lib/alsa-utils autobuild fixes
In reply to Thomas De SchampheleireDear Thomas De Schampheleire,
Quoted 4 lines · Thomas De Schampheleire
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 <[email protected]>
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 alsa-lib/alsa-utils autobuild fixes
Quoted 4 lines · Thomas Petazzoni
Dear Thomas De Schampheleire,
On Wed, 12 Feb 2014 17:55:40 +0100, Thomas De Schampheleire wrote:
Quoted 9 lines
Quoted 4 lines
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 <[email protected]>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...