* [Buildroot] [PATCH] netatalk: fix 64-bit build
From: Arnout Vandecappelle @ 2012-12-17 21:48 UTC (permalink / raw)
To: buildroot
From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
The configure script sets LD_LIBRARY_PATH to the staging directory,
which makes the `ls` that is called in one of the tests fail. Fix by
not setting LD_LIBRARY_PATH when cross-compiling.
The patch has been sent upstream.
Also remove the BDB_LIB variable: it isn't used.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
...setting-of-LD_LIBRARY_FLAGS-shlibpath_var.patch | 48 ++++++++++++++++++++
package/netatalk/netatalk.mk | 4 +-
2 files changed, 51 insertions(+), 1 deletion(-)
create mode 100644 package/netatalk/netatalk-0001-Fix-setting-of-LD_LIBRARY_FLAGS-shlibpath_var.patch
diff --git a/package/netatalk/netatalk-0001-Fix-setting-of-LD_LIBRARY_FLAGS-shlibpath_var.patch b/package/netatalk/netatalk-0001-Fix-setting-of-LD_LIBRARY_FLAGS-shlibpath_var.patch
new file mode 100644
index 0000000..01d5776
--- /dev/null
+++ b/package/netatalk/netatalk-0001-Fix-setting-of-LD_LIBRARY_FLAGS-shlibpath_var.patch
@@ -0,0 +1,48 @@
+From 60d100713b5289948e9cdf5b0646ff3cdd2c206b Mon Sep 17 00:00:00 2001
+From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
+Date: Mon, 17 Dec 2012 22:32:44 +0100
+Subject: [PATCH] Fix setting of LD_LIBRARY_FLAGS ($shlibpath_var).
+
+LD_LIBRARY_PATH should not be set when cross-compiling, because it
+adds the cross-libraries to the build's LD-path.
+
+Also the restoring of LD_LIBRARY_PATH was done incorrectly: it would
+set LD_LIBRARY_PATH=LD_LIBRARY_PATH.
+
+Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
+---
+ macros/db3-check.m4 | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/macros/db3-check.m4 b/macros/db3-check.m4
+index 902220b..d5a5446 100644
+--- a/macros/db3-check.m4
++++ b/macros/db3-check.m4
+@@ -94,7 +94,7 @@ if test "x$bdb_required" = "xyes"; then
+ savedldflags="$LDFLAGS"
+ savedcppflags="$CPPFLAGS"
+ savedlibs="$LIBS"
+- saved_shlibpath_var=$shlibpath_var
++ eval saved_shlibpath_var=\$$shlibpath_var
+
+ dnl required BDB version: 4.6, because of cursor API change
+ DB_MAJOR_REQ=4
+@@ -148,7 +148,7 @@ if test "x$bdb_required" = "xyes"; then
+ dnl -- LD_LIBRARY_PATH on many platforms. This will be fairly
+ dnl -- portable hopefully. Reference:
+ dnl -- http://lists.gnu.org/archive/html/autoconf/2009-03/msg00040.html
+- eval export $shlibpath_var=$bdblibdir
++ test "$cross_compiling" = yes || eval export $shlibpath_var=$bdblibdir
+ NETATALK_BDB_TRY_LINK
+ eval export $shlibpath_var=$saved_shlibpath_var
+
+@@ -171,7 +171,7 @@ if test "x$bdb_required" = "xyes"; then
+ CPPFLAGS="-I${bdbdir}/include${subdir} $CPPFLAGS"
+ LDFLAGS="-L$bdblibdir $LDFLAGS"
+
+- eval export $shlibpath_var=$bdblibdir
++ test "$cross_compiling" = yes || eval export $shlibpath_var=$bdblibdir
+ NETATALK_BDB_TRY_LINK
+ eval export $shlibpath_var=$saved_shlibpath_var
+
+--
diff --git a/package/netatalk/netatalk.mk b/package/netatalk/netatalk.mk
index 46355ce..243d3f7 100644
--- a/package/netatalk/netatalk.mk
+++ b/package/netatalk/netatalk.mk
@@ -7,8 +7,10 @@ NETATALK_VERSION = 3.0
NETATALK_SITE = http://downloads.sourceforge.net/project/netatalk/netatalk/$(NETATALK_VERSION)
NETATALK_SOURCE = netatalk-$(NETATALK_VERSION).tar.bz2
+NETATALK_AUTORECONF = YES
+
NETATALK_DEPENDENCIES = host-pkgconf openssl berkeleydb libgcrypt libgpg-error
-NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99" BDB_LIB=$(STAGING_DIR)/usr/lib
+NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99"
NETATALK_CONF_OPT += --with-cnid-cdb-backend \
--with-bdb=$(STAGING_DIR)/usr \
--disable-zeroconf \
--
1.7.10.4
^ permalink raw reply related
* [Buildroot] [PATCH] allow wpa_supplicant to run on the dbus using the 'new' api
From: Gary Coulbourne @ 2012-12-17 20:54 UTC (permalink / raw)
To: buildroot
When wpa_supplicant is built, it compiles to use the old names on the dbus,
as well as with the wrong executable name in the dbus activation service.
This patch builds on a patch submitted in Sept by Sven Neumann.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121217/e901d3a2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-allow-wpa_supplicant-to-run-on-the-dbus-using-the-ne.patch
Type: application/octet-stream
Size: 3047 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121217/e901d3a2/attachment.obj>
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Peter Korsgaard @ 2012-12-17 20:44 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50CF5987.90805@mind.be>
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
Arnout> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
>> +if BR2_PACKAGE_IMX_LIB
>> +choice
>> + prompt "i.MX platform"
>> +
>> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK
>> + bool "imx25-3stack"
>> +
>> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS
>> + bool "imx27ads"
>> +
>> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK
>> + bool "imx37-3stack"
>> +
>> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50
>> + bool "imx50"
>> +
>> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51
>> + bool "imx51"
>> +
>> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53
>> + bool "imx53"
>> +
>> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q
>> + bool "imx6q"
>> +
>> +endchoice
Arnout> Here's a second issue that I'd like to get some feedback on:
Arnout> gst-fsl-plugins also uses a PLATFORM definition, but the list of
Arnout> platforms is slightly different:
Arnout> MX28/MX233/MX25/MX27/MX31/MX35/MX37/MX51/MX53/MX50/MX5X/MX6
Arnout> Ideally the 'platform' should be defined only once, but where? Or
Arnout> should I add all the platforms to gst-fsl-plugins with a select of the
Arnout> appropriate imx-lib platform?
We once talked about adding a SoC selection to buildroot, but decided it
would be too much effort to maintain.
Is the gst-fsl-plugins stuff still needed now that the coda driver is in
mainline?
Arnout> I can only test the mx6q because that's the only one for which
Arnout> I have a board... Build-testing doesn't make a difference
Arnout> because all platforms use the same API.
I have access to mx28 / mx51 / mx53 / mx6q boards and could do some
testing during christmas.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Peter Korsgaard @ 2012-12-17 20:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50CF5761.7030902@mind.be>
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
>> Another possibility is to bundle the needed kernel headers with the
>> package, similar to how E.G. mtd-utils does it.
Arnout> Unfortunately, Freescale probably has a much lower standard about ABI
Arnout> compatibility than kernel.org. Also it's relatively likely that a
Arnout> buildroot user will use a different Freescale kernel than the one
Arnout> assumed by buildroot. So you may end up with userspace assuming
Arnout> different struct layouts than the kernel...
Yeah, closed source mess :/
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [PATCH] sg3-utils new package.
From: Marek Belisko @ 2012-12-17 20:35 UTC (permalink / raw)
To: buildroot
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
---
package/Config.in | 1 +
package/sg3_utils/Config.in | 7 +++++++
package/sg3_utils/sg3_utils.mk | 10 ++++++++++
3 files changed, 18 insertions(+)
create mode 100644 package/sg3_utils/Config.in
create mode 100644 package/sg3_utils/sg3_utils.mk
diff --git a/package/Config.in b/package/Config.in
index d6af55d..269b3ff 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -253,6 +253,7 @@ source "package/rng-tools/Config.in"
source "package/sane-backends/Config.in"
source "package/sdparm/Config.in"
source "package/setserial/Config.in"
+source "package/sg3_utils/Config.in"
source "package/smartmontools/Config.in"
source "package/snowball-hdmiservice/Config.in"
source "package/sredird/Config.in"
diff --git a/package/sg3_utils/Config.in b/package/sg3_utils/Config.in
new file mode 100644
index 0000000..1d2ab2a
--- /dev/null
+++ b/package/sg3_utils/Config.in
@@ -0,0 +1,7 @@
+config BR2_PACKAGE_SG3_UTILS
+ bool "sg3_utils"
+ help
+ sg3_utils is a package of utilities that send SCSI commands to the
+ given <scsi_device> via a SCSI pass through.
+
+ http://sg.danny.cz/sg/
diff --git a/package/sg3_utils/sg3_utils.mk b/package/sg3_utils/sg3_utils.mk
new file mode 100644
index 0000000..2eba3d3
--- /dev/null
+++ b/package/sg3_utils/sg3_utils.mk
@@ -0,0 +1,10 @@
+#############################################################
+#
+# sg3_utils
+#
+#############################################################
+SG3_UTILS_VERSION = 1.34
+SG3_UTILS_SITE = http://sg.danny.cz/sg/p/
+SG3_UTILS_INSTALL_STAGING = YES
+
+$(eval $(autotools-package))
--
1.7.10.4
^ permalink raw reply related
* [Buildroot] [PATCH] netatalk : Fix BerkeleyDB library path
From: Arnout Vandecappelle @ 2012-12-17 20:35 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAGduivyvZNaaC8jdLzt1yVju3DS0Vu0fdaQYdHzK6LoRE==nYw@mail.gmail.com>
On 17/12/12 00:15, Maxime Hadjinlian wrote:
> On Sun, Dec 16, 2012 at 11:17 PM, Peter Korsgaard<jacmet@uclibc.org> wrote:
>>>>>>> "Maxime" == Maxime Hadjinlian<maxime.hadjinlian@gmail.com> writes:
>>
>> Maxime> This fix is needed for the 64bits build because Netatalk will assume the library
>> Maxime> are stored in [..]/lib64/ instead of [..]/lib/
>>
>> Hmm, we still seem to have issues on the autobuilders:
>>
>> http://autobuild.buildroot.net/results/cf5c3ce94c229204bfa0f19b1009c13a9bcc1dfc/build-end.log
>>
>> Maxime> +++ b/package/netatalk/netatalk.mk
>> Maxime> @@ -8,7 +8,7 @@ NETATALK_SITE = http://downloads.sourceforge.net/project/netatalk/netatalk/$(NET
>> Maxime> NETATALK_SOURCE = netatalk-$(NETATALK_VERSION).tar.bz2
>>
>> Maxime> NETATALK_DEPENDENCIES = host-pkgconf openssl berkeleydb libgcrypt libgpg-error
>> Maxime> -NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99"
>> Maxime> +NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99" BDB_LIB=$(STAGING_LIB)/usr/lib
>>
>>
>> I guess you meant STAGING_DIR instead here, will fix.
> This is strange because I tested with a 64 bits build and I had'nt the
> problem anymore.. And I don't remember rewriting the patch before
> sending it here. But then again, you're totally right, this does'nt
> make sense. I'm really wondering how it could have worked for me :/
I guess it was an accident then :-)
configure checks for libdb by doing: ls $bdblibdir/lib$lib.*
and bdblibdir="${bdbdir}/${atalk_libname}" and atalk_libname="lib64" for
most 64-bit architectures.
So you happened to have an existing /usr/lib/lib64/libdb* on your build
machine...
BDB_LIB isn't even used by configure, so I don't think does patch does
much :-)
The problem I encounter in my build is that configure uses `ls ...` to
find the library, and my /bin/ls is linked against libacl.so.1. It seems
LD_LIBRARY_PATH is overridden because ls fails with:
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /home/arnout/src/buildroot/output-ext-toolchain-x86_64/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libacl.so.1
And indeed, configure sets:
eval export $shlibpath_var=$bdblibdir
This is OK for native builds, but not for cross-builds...
Looking a bit further into macros/db3-check.m4, it looks even worse:
after that configure step, there is an
eval export $shlibpath_var=$saved_shlibpath_var
which expands to
export LD_LIBRARY_PATH=LD_LIBRARY_PATH
:-)
I'll try to cook a fix and send a patch.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH 1/1] Added FAAD, WavPack and gdk_pixbuf to gst-plugins.
From: Bogdan Radulescu @ 2012-12-17 20:08 UTC (permalink / raw)
To: buildroot
Signed-off-by: Bogdan Radulescu <bogdan@nimblex.net>
---
?package/multimedia/gst-plugins-bad/Config.in??????????? | 17 ++++++++++-------
?package/multimedia/gst-plugins-bad/gst-plugins-bad.mk?? |? 7 +++++++
?package/multimedia/gst-plugins-good/Config.in?????????? |? 7 +++++++
?package/multimedia/gst-plugins-good/gst-plugins-good.mk | 14 ++++++++++++++
?4 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/package/multimedia/gst-plugins-bad/Config.in b/package/multimedia/gst-plugins-bad/Config.in
index d87aec4..cd368fb 100644
--- a/package/multimedia/gst-plugins-bad/Config.in
+++ b/package/multimedia/gst-plugins-bad/Config.in
@@ -82,12 +82,12 @@ config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_FESTIVAL
?config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_FIELDANALYSIS
???? bool "fieldanalysis"
?
-config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_FREEZE
-??? bool "freeze"
-
?config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_FREEVERB
???? bool "freeverb"
?
+config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_FREEZE
+??? bool "freeze"
+
?config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_FREI0R
???? bool "frei0r"
?
@@ -211,12 +211,12 @@ config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_SMOOTH
?config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_SPEED
???? bool "speed"
?
-config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_SUBENC
-??? bool "subenc"
-
?config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_STEREO
???? bool "stereo"
?
+config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_SUBENC
+??? bool "subenc"
+
?config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_TTA
???? bool "tta"
?
@@ -241,7 +241,7 @@ config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_VMNC
?config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_Y4M
???? bool "y4m"
?
-comment "plugins with external dependencies (there may be more available)"
+comment "plugins with external dependencies (not all from gstreamer are here)"
?
?config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_APEXSINK
???? bool "apexsink"
@@ -270,6 +270,9 @@ config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_DVB
?config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_FBDEV
???? bool "fbdev"
?
+config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_FAAD
+??? bool "faad"
+
?config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_LIBMMS
???? bool "libmms"
???? select BR2_PACKAGE_LIBMMS
diff --git a/package/multimedia/gst-plugins-bad/gst-plugins-bad.mk b/package/multimedia/gst-plugins-bad/gst-plugins-bad.mk
index 714c987..183de7b 100644
--- a/package/multimedia/gst-plugins-bad/gst-plugins-bad.mk
+++ b/package/multimedia/gst-plugins-bad/gst-plugins-bad.mk
@@ -508,6 +508,13 @@ else
?GST_PLUGINS_BAD_CONF_OPT += --disable-dvb
?endif
?
+ifeq ($(BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_FAAD),y)
+GST_PLUGINS_BAD_CONF_OPT += --enable-faad
+GST_PLUGINS_BAD_DEPENDENCIES += faad2
+else
+GST_PLUGINS_BAD_CONF_OPT += --disable-faad
+endif
+
?ifeq ($(BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_FBDEV),y)
?GST_PLUGINS_BAD_CONF_OPT += --enable-fbdev
?else
diff --git a/package/multimedia/gst-plugins-good/Config.in b/package/multimedia/gst-plugins-good/Config.in
index 33ecb5c..8c43ac8 100644
--- a/package/multimedia/gst-plugins-good/Config.in
+++ b/package/multimedia/gst-plugins-good/Config.in
@@ -161,6 +161,9 @@ config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_VIDEOMIXER
?config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_WAVENC
???? bool "wavenc"
?
+config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_WAVPACK
+??? bool "wavpack (*.wv audio)"
+
?config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_WAVPARSE
???? bool "wavparse (*.wav audio)"
???? default y
@@ -186,6 +189,10 @@ config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_FLAC
???? bool "flac (libFLAC)"
???? select BR2_PACKAGE_FLAC
?
+config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_GDKPIXBUF
+??? bool "gdkpixbuf"
+??? select BR2_PACKAGE_GDK_PIXBUF
+
?config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_OSS
???? bool "ossaudio (OSS audio)"
?
diff --git a/package/multimedia/gst-plugins-good/gst-plugins-good.mk b/package/multimedia/gst-plugins-good/gst-plugins-good.mk
index 18b4299..5e93a49 100644
--- a/package/multimedia/gst-plugins-good/gst-plugins-good.mk
+++ b/package/multimedia/gst-plugins-good/gst-plugins-good.mk
@@ -308,6 +308,13 @@ else
?GST_PLUGINS_GOOD_CONF_OPT += --disable-wavenc
?endif
?
+ifeq ($(BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_WAVPACK),y)
+GST_PLUGINS_GOOD_CONF_OPT += --enable-wavpack
+GST_PLUGINS_GOOD_DEPENDENCIES += wavpack
+else
+GST_PLUGINS_GOOD_CONF_OPT += --disable-wavpack
+endif
+
?ifeq ($(BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_WAVPARSE),y)
?GST_PLUGINS_GOOD_CONF_OPT += --enable-wavparse
?else
@@ -347,6 +354,13 @@ else
?GST_PLUGINS_GOOD_CONF_OPT += --disable-flac
?endif
?
+ifeq ($(BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_GDKPIXBUF),y)
+GST_PLUGINS_GOOD_CONF_OPT += --enable-gdk_pixbuf
+GST_PLUGINS_GOOD_DEPENDENCIES += gdk-pixbuf
+else
+GST_PLUGINS_GOOD_CONF_OPT += --disable-gdk_pixbuf
+endif
+
?ifeq ($(BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_OSS),y)
?GST_PLUGINS_GOOD_CONF_OPT += --enable-oss
?else
--
1.7.12.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gst-plugins.diff
Type: application/octet-stream
Size: 5046 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121217/d69ae7f5/attachment-0001.obj>
^ permalink raw reply related
* [Buildroot] [PATCH] libglib2: fix g_print()
From: Benoît Thébaudeau @ 2012-12-17 20:05 UTC (permalink / raw)
To: buildroot
If GLib is cross-compiled, the default printf settings that it selects are wrong
for glibc. This leads to issues with the g_print() functions, e.g. "Aborted"
errors returned by gst-inspect.
This patch fixes this issue by setting printf configuration options compatible
with glibc. These options should also be compatible with uClibc.
This solution has been suggested for LTIB by Rogerio Nunes:
https://community.freescale.com/thread/302734
Signed-off-by: Beno?t Th?baudeau <benoit.thebaudeau@advansee.com>
---
package/libglib2/libglib2.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/package/libglib2/libglib2.mk b/package/libglib2/libglib2.mk
index 4427431..c3e510b 100644
--- a/package/libglib2/libglib2.mk
+++ b/package/libglib2/libglib2.mk
@@ -40,7 +40,8 @@ LIBGLIB2_CONF_ENV = \
ac_cv_func_working_mktime=yes jm_cv_func_working_re_compile_pattern=yes \
ac_use_included_regex=no gl_cv_c_restrict=no \
ac_cv_path_GLIB_GENMARSHAL=$(HOST_DIR)/usr/bin/glib-genmarshal ac_cv_prog_F77=no \
- ac_cv_func_posix_getgrgid_r=no \
+ ac_cv_func_posix_getgrgid_r=no glib_cv_long_long_format=ll \
+ ac_cv_func_printf_unix98=yes ac_cv_func_vsnprintf_c99=yes \
gt_cv_c_wchar_t=$(if $(BR2_USE_WCHAR),yes,no)
# old uClibc versions don't provide qsort_r
--
1.7.10.4
^ permalink raw reply related
* [Buildroot] [PATCH 1/1] Added new package ncdu
From: Bogdan Radulescu @ 2012-12-17 20:04 UTC (permalink / raw)
To: buildroot
Signed-off-by: Bogdan Radulescu <bogdan@nimblex.net>
---
?package/Config.in????? |? 1 +
?package/ncdu/Config.in |? 7 +++++++
?package/ncdu/ncdu.mk?? | 13 +++++++++++++
?3 files changed, 21 insertions(+)
?create mode 100644 package/ncdu/Config.in
?create mode 100644 package/ncdu/ncdu.mk
diff --git a/package/Config.in b/package/Config.in
index 171db8f..2d12cdc 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -732,6 +732,7 @@ if BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
?source "package/module-init-tools/Config.in"
?endif
?source "package/monit/Config.in"
+source "package/ncdu/Config.in"
?if BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
?source "package/procps/Config.in"
?source "package/psmisc/Config.in"
diff --git a/package/ncdu/Config.in b/package/ncdu/Config.in
new file mode 100644
index 0000000..d8b4db4
--- /dev/null
+++ b/package/ncdu/Config.in
@@ -0,0 +1,7 @@
+config BR2_PACKAGE_NCDU
+?????? bool "ncdu"
+?????? select BR2_PACKAGE_NCURSES
+?????? help
+???????? ncdu is a disk usage analyzer with an ncurses interface
+
+???????? http://dev.yorhel.nl/ncdu
diff --git a/package/ncdu/ncdu.mk b/package/ncdu/ncdu.mk
new file mode 100644
index 0000000..26f3b5e
--- /dev/null
+++ b/package/ncdu/ncdu.mk
@@ -0,0 +1,13 @@
+#############################################################
+#
+# ncdu
+#
+#############################################################
+NCDU_VERSION=1.9
+NCDU_SITE=http://dev.yorhel.nl/download/
+NCDU_INSTALL_STAGING_OPT = instroot=$(STAGING_DIR) install
+NCDU_INSTALL_TARGET_OPT = instroot=$(TARGET_DIR) install
+
+NCDU_DEPENDENCIES = ncurses
+
+$(eval $(autotools-package))
--
1.7.12.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ncdu.diff
Type: application/octet-stream
Size: 1812 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121217/42140369/attachment.obj>
^ permalink raw reply related
* [Buildroot] [PATCH] imx-lib: new package
From: Benoît Thébaudeau @ 2012-12-17 19:40 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50CF55F7.9090906@mind.be>
Dear Arnout Vandecappelle,
On Monday, December 17, 2012 6:27:19 PM, Arnout Vandecappelle wrote:
> On 17/12/12 16:57, Beno?t Th?baudeau wrote:
> > Dear Arnout Vandecappelle,
> >
> > On Monday, December 17, 2012 4:50:37 PM, Arnout Vandecappelle
> > wrote:
> >> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
> >>> +IMX_LIB_INCLUDE = \
> >>> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
> >>> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
> >>> + -I$(LINUX_DIR)/include
> >>
> >> Actually, I wonder if this is the right thing to do... This is
> >> a
> >> userspace library that requires a platform-specific linux/xxx.h.
> >> For
> >> an
> >> external toolchain, these headers don't exist in
> >> $(STAGING_DIR)/usr/include/linux
> >>
> >> Directly using $(LINUX_DIR)/include means that the headers are
> >> not
> >> patched for userspace. For those platform-specific headers that's
> >> probably not a problem, but it's not good for e.g. linux/types.h.
> >>
> >> An easy workaround is to use -idirafter instead of -I.
> >> However,
> >> perhaps it's an even better idea to do 'make headers_install' as
> >> part
> >> of
> >> the normal linux build process, so that packages depending on
> >> those
> >> headers can use the patched version. But then again, is it a good
> >> idea to
> >> replace the toolchain's kernel headers with a new set of kernel
> >> headers?
> >>
> >> Any advice is welcome!
> >
> > FYI, I've successfully built the 11.09.01 version under BuildRoot
> > without the
> > "-I$(LINUX_DIR)/include", and the issue that you mention is only
> > for this
> > folder. I had to make a patch to make the headers install work, but
> > that should
> > not be related. Can you try with your package?
>
> ipu/mxc_ipu_hl_lib.h needs linux/mxcfb.h which only exists in the
> imx
> kernels.
I see. I did not have this issue because I have built a custom toolchain based
on Freescale's kernel, so including these headers. This would not be very
practical to impose the use of a custom toolchain here.
Best regards,
Beno?t
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Arnout Vandecappelle @ 2012-12-17 17:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1355752131-31966-1-git-send-email-arnout@mind.be>
On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
> +if BR2_PACKAGE_IMX_LIB
> +choice
> + prompt "i.MX platform"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK
> + bool "imx25-3stack"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS
> + bool "imx27ads"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK
> + bool "imx37-3stack"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50
> + bool "imx50"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51
> + bool "imx51"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53
> + bool "imx53"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q
> + bool "imx6q"
> +
> +endchoice
Here's a second issue that I'd like to get some feedback on:
gst-fsl-plugins also uses a PLATFORM definition, but the list of
platforms is slightly different:
MX28/MX233/MX25/MX27/MX31/MX35/MX37/MX51/MX53/MX50/MX5X/MX6
Ideally the 'platform' should be defined only once, but where? Or
should I add all the platforms to gst-fsl-plugins with a select of the
appropriate imx-lib platform?
What to do with the platforms that are different? In some cases, I can
make a guess of course (e.g. MX27 -> IMX27ADS)
I can only test the mx6q because that's the only one for which I have a
board... Build-testing doesn't make a difference because all platforms
use the same API.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Arnout Vandecappelle @ 2012-12-17 17:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <871ueo8y7k.fsf@dell.be.48ers.dk>
On 17/12/12 17:01, Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle<arnout@mind.be> writes:
>
> Arnout> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
> >> +IMX_LIB_INCLUDE = \
> >> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
> >> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
> >> + -I$(LINUX_DIR)/include
>
> Arnout> Actually, I wonder if this is the right thing to do... This is a
> Arnout> userspace library that requires a platform-specific linux/xxx.h. For
> Arnout> an external toolchain, these headers don't exist in
> Arnout> $(STAGING_DIR)/usr/include/linux
>
> Arnout> Directly using $(LINUX_DIR)/include means that the headers are not
> Arnout> patched for userspace. For those platform-specific headers that's
> Arnout> probably not a problem, but it's not good for e.g. linux/types.h.
>
> Arnout> An easy workaround is to use -idirafter instead of -I. However,
> Arnout> perhaps it's an even better idea to do 'make headers_install' as part
> Arnout> of the normal linux build process, so that packages depending on those
> Arnout> headers can use the patched version. But then again, is it a good idea
> Arnout> to replace the toolchain's kernel headers with a new set of kernel
> Arnout> headers?
>
> Another possibility is to bundle the needed kernel headers with the
> package, similar to how E.G. mtd-utils does it.
Unfortunately, Freescale probably has a much lower standard about ABI
compatibility than kernel.org. Also it's relatively likely that a
buildroot user will use a different Freescale kernel than the one assumed
by buildroot. So you may end up with userspace assuming different struct
layouts than the kernel...
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Arnout Vandecappelle @ 2012-12-17 17:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <2112128925.1003709.1355759859440.JavaMail.root@advansee.com>
On 17/12/12 16:57, Beno?t Th?baudeau wrote:
> Dear Arnout Vandecappelle,
>
> On Monday, December 17, 2012 4:50:37 PM, Arnout Vandecappelle wrote:
>> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
>>> +IMX_LIB_INCLUDE = \
>>> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
>>> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
>>> + -I$(LINUX_DIR)/include
>>
>> Actually, I wonder if this is the right thing to do... This is a
>> userspace library that requires a platform-specific linux/xxx.h. For
>> an
>> external toolchain, these headers don't exist in
>> $(STAGING_DIR)/usr/include/linux
>>
>> Directly using $(LINUX_DIR)/include means that the headers are not
>> patched for userspace. For those platform-specific headers that's
>> probably not a problem, but it's not good for e.g. linux/types.h.
>>
>> An easy workaround is to use -idirafter instead of -I. However,
>> perhaps it's an even better idea to do 'make headers_install' as part
>> of
>> the normal linux build process, so that packages depending on those
>> headers can use the patched version. But then again, is it a good
>> idea to
>> replace the toolchain's kernel headers with a new set of kernel
>> headers?
>>
>> Any advice is welcome!
>
> FYI, I've successfully built the 11.09.01 version under BuildRoot without the
> "-I$(LINUX_DIR)/include", and the issue that you mention is only for this
> folder. I had to make a patch to make the headers install work, but that should
> not be related. Can you try with your package?
ipu/mxc_ipu_hl_lib.h needs linux/mxcfb.h which only exists in the imx
kernels.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH] [RFC] new target: live filesystem
From: Richard Genoud @ 2012-12-17 16:35 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAHXCMMKXJ8Crr770fXoYz=+SbNcU0VCNXkMcvXsKJKRmd0xsWg@mail.gmail.com>
2012/12/17 Samuel Martin <s.martin49@gmail.com>:
> Hi Richard,
> There are plenty of good reasons to not use output/target as root for
> a chroot or a NFS root, as explained here:
> http://buildroot.org/downloads/manual/manual.html#faq-why-not-use-target-as-chroot
>
> And here, you'll find the right way to do this (so far):
> http://buildroot.org/downloads/manual/manual.html#_nfs_boot
>
Yes, I know...
It's just more convenient (fast) for me like that:
When I recompile a small software (with make mysoft-reconfigure), I'd
like it to be fast, and de-tar-ing the whole RFS takes some time.
But, it's true that it's not the right way to do it.
(I also always forgot to sudo when I want to copy something to the
nfsroot, so, like that, the tree is mine and there's no cp problem)
Thanks for the links though !
Regards,
Richard.
^ permalink raw reply
* [Buildroot] [PATCH] [RFC] new target: live filesystem
From: Samuel Martin @ 2012-12-17 16:08 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CACQ1gAj-H5P3SaX=fhzxpW=aPwp+kJuZw2CQ9AYgmnSKZKpp7g@mail.gmail.com>
Hi Richard,
2012/12/17 Richard Genoud <richard.genoud@gmail.com>:
> 2012/12/17 Jeremy Rosen <jeremy.rosen@openwide.fr>:
>> Hello everybody
>>
>> there is a little bit more work to do on this patch (mainly updating a few more places in the documentation) but i'd like to have a go/no-go before I do that...
>
> I was looking for that kind of feature, I hope it will be accepted.
> For now, I use the output/target tree and those parameters in the
> /etc/exports file:
> *(rw,all_squash,no_subtree_check,anonuid=my_uid,anongid=my_gid)
>
> But that means that all the FS is owned by my user.
There are plenty of good reasons to not use output/target as root for
a chroot or a NFS root, as explained here:
http://buildroot.org/downloads/manual/manual.html#faq-why-not-use-target-as-chroot
And here, you'll find the right way to do this (so far):
http://buildroot.org/downloads/manual/manual.html#_nfs_boot
Regards,
--
Sam
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Peter Korsgaard @ 2012-12-17 16:01 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50CF3F4D.1030100@mind.be>
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
Arnout> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
>> +IMX_LIB_INCLUDE = \
>> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
>> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
>> + -I$(LINUX_DIR)/include
Arnout> Actually, I wonder if this is the right thing to do... This is a
Arnout> userspace library that requires a platform-specific linux/xxx.h. For
Arnout> an external toolchain, these headers don't exist in
Arnout> $(STAGING_DIR)/usr/include/linux
Arnout> Directly using $(LINUX_DIR)/include means that the headers are not
Arnout> patched for userspace. For those platform-specific headers that's
Arnout> probably not a problem, but it's not good for e.g. linux/types.h.
Arnout> An easy workaround is to use -idirafter instead of -I. However,
Arnout> perhaps it's an even better idea to do 'make headers_install' as part
Arnout> of the normal linux build process, so that packages depending on those
Arnout> headers can use the patched version. But then again, is it a good idea
Arnout> to replace the toolchain's kernel headers with a new set of kernel
Arnout> headers?
Another possibility is to bundle the needed kernel headers with the
package, similar to how E.G. mtd-utils does it.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Benoît Thébaudeau @ 2012-12-17 15:57 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50CF3F4D.1030100@mind.be>
Dear Arnout Vandecappelle,
On Monday, December 17, 2012 4:50:37 PM, Arnout Vandecappelle wrote:
> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
> > +IMX_LIB_INCLUDE = \
> > + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
> > + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
> > + -I$(LINUX_DIR)/include
>
> Actually, I wonder if this is the right thing to do... This is a
> userspace library that requires a platform-specific linux/xxx.h. For
> an
> external toolchain, these headers don't exist in
> $(STAGING_DIR)/usr/include/linux
>
> Directly using $(LINUX_DIR)/include means that the headers are not
> patched for userspace. For those platform-specific headers that's
> probably not a problem, but it's not good for e.g. linux/types.h.
>
> An easy workaround is to use -idirafter instead of -I. However,
> perhaps it's an even better idea to do 'make headers_install' as part
> of
> the normal linux build process, so that packages depending on those
> headers can use the patched version. But then again, is it a good
> idea to
> replace the toolchain's kernel headers with a new set of kernel
> headers?
>
> Any advice is welcome!
FYI, I've successfully built the 11.09.01 version under BuildRoot without the
"-I$(LINUX_DIR)/include", and the issue that you mention is only for this
folder. I had to make a patch to make the headers install work, but that should
not be related. Can you try with your package?
Best regards,
Beno?t
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Benoît Thébaudeau @ 2012-12-17 15:50 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1355752131-31966-1-git-send-email-arnout@mind.be>
Dear Arnout Vandecappelle,
On Monday, December 17, 2012 2:48:50 PM, Arnout Vandecappelle wrote:
> From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
>
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
> I'm not sure if I'll get the packages that use this library in an
> upstreamable state - but at least this one is.
>
> ---
> package/Config.in | 1 +
> package/imx-lib/Config.in | 53
> ++++++++++++++++++++++++++++++++++++++++++++
> package/imx-lib/imx-lib.mk | 41 ++++++++++++++++++++++++++++++++++
> 3 files changed, 95 insertions(+)
> create mode 100644 package/imx-lib/Config.in
> create mode 100644 package/imx-lib/imx-lib.mk
>
> diff --git a/package/Config.in b/package/Config.in
> index d6af55d..5151346 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -420,6 +420,7 @@ endmenu
>
> menu "Hardware handling"
> source "package/ccid/Config.in"
> +source "package/imx-lib/Config.in"
> source "package/lcdapi/Config.in"
> source "package/libaio/Config.in"
> source "package/libraw1394/Config.in"
> diff --git a/package/imx-lib/Config.in b/package/imx-lib/Config.in
> new file mode 100644
> index 0000000..0ed452a
> --- /dev/null
> +++ b/package/imx-lib/Config.in
> @@ -0,0 +1,53 @@
> +comment "imx-lib needs an imx-specific kernel to be built"
> + depends on !BR2_LINUX_KERNEL
> +
> +config BR2_PACKAGE_IMX_LIB
> + bool "imx-lib"
> + depends on BR2_LINUX_KERNEL
> + depends on BR2_arm
> + help
> + Library of userspace helpers specific for the Freescale i.MX
> + platform. It wraps the kernel interfaces for some i.MX platform
> + specific drivers. It requires a kernel that includes the i.MX
> + specific headers to be built.
> +
> + This library is provided by Freescale as-is and doesn't have
> + an upstream.
> +
> +if BR2_PACKAGE_IMX_LIB
> +choice
> + prompt "i.MX platform"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK
> + bool "imx25-3stack"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS
> + bool "imx27ads"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK
> + bool "imx37-3stack"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50
> + bool "imx50"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51
> + bool "imx51"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53
> + bool "imx53"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q
> + bool "imx6q"
> +
> +endchoice
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM
> + string
> + default "IMX25_3STACK" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK
> + default "IMX27ADS" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS
> + default "IMX37_3STACK" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK
> + default "IMX50" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50
> + default "IMX51" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51
> + default "IMX53" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53
> + default "IMX6Q" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q
> +endif
> diff --git a/package/imx-lib/imx-lib.mk b/package/imx-lib/imx-lib.mk
> new file mode 100644
> index 0000000..29f5ae1
> --- /dev/null
> +++ b/package/imx-lib/imx-lib.mk
> @@ -0,0 +1,41 @@
> +#############################################################
> +#
> +# imx-lib
> +#
> +#############################################################
> +
> +IMX_LIB_VERSION = 12.09.01
> +# No official download site from freescale, just this mirror
> +IMX_LIB_SITE =
> http://download.ossystems.com.br/bsp/freescale/source
> +IMX_LIB_LICENSE = LGPLv2.1+
> +# No license file included
> +
> +IMX_LIB_INSTALL_STAGING = YES
> +
> +# imx-lib needs access to imx-specific kernel headers
> +IMX_LIB_DEPENDENCIES += linux
> +IMX_LIB_INCLUDE = \
> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
> + -I$(LINUX_DIR)/include
> +
> +IMX_LIB_MAKE_ENV = \
> + $(TARGET_MAKE_ENV) \
> + $(TARGET_CONFIGURE_OPTS) \
> + CROSS_COMPILE="$(CCACHE) $(TARGET_CROSS)" \
> + PLATFORM=$(BR2_PACKAGE_IMX_LIB_PLATFORM) \
> + INCLUDE="$(IMX_LIB_INCLUDE)"
> +
> +define IMX_LIB_BUILD_CMDS
> + $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D)
> +endef
> +
> +define IMX_LIB_INSTALL_STAGING_CMDS
> + $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) DEST_DIR=$(STAGING_DIR)
> install
> +endef
> +
> +define IMX_LIB_INSTALL_TARGET_CMDS
> + $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) DEST_DIR=$(TARGET_DIR)
> install
> +endef
> +
> +$(eval $(generic-package))
This looks good. There is however a missing runtime dependency on firmware-imx.
Best regards,
Beno?t
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Arnout Vandecappelle @ 2012-12-17 15:50 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1355752131-31966-1-git-send-email-arnout@mind.be>
On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
> +IMX_LIB_INCLUDE = \
> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
> + -I$(LINUX_DIR)/include
Actually, I wonder if this is the right thing to do... This is a
userspace library that requires a platform-specific linux/xxx.h. For an
external toolchain, these headers don't exist in
$(STAGING_DIR)/usr/include/linux
Directly using $(LINUX_DIR)/include means that the headers are not
patched for userspace. For those platform-specific headers that's
probably not a problem, but it's not good for e.g. linux/types.h.
An easy workaround is to use -idirafter instead of -I. However,
perhaps it's an even better idea to do 'make headers_install' as part of
the normal linux build process, so that packages depending on those
headers can use the patched version. But then again, is it a good idea to
replace the toolchain's kernel headers with a new set of kernel headers?
Any advice is welcome!
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH] add support for Freescale .sb format to uboot
From: Attila Kinali @ 2012-12-17 13:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <87pq2o8ad0.fsf@dell.be.48ers.dk>
On Wed, 05 Dec 2012 13:20:11 -0800
Peter Korsgaard <jacmet@uclibc.org> wrote:
> >>>>> "Attila" == Attila Kinali <attila@kinali.ch> writes:
>
> >> Not really. I don't have any imx hw here. Are you able to test it?
>
> Attila> I have an i.mx23 EVK at work. So i guess i could test it.
>
> Great, thanks.
Sorry, i didnt have time to test it yet.
And unfortunately it doesn't look like i will have time for it
until the end of the week. How it is between christmas and new year,
i cannot tell. But i try to fit it in somehow.
Thanks for your patience and sorry for the delay
Attila Kinali
--
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Arnout Vandecappelle @ 2012-12-17 13:48 UTC (permalink / raw)
To: buildroot
From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
I'm not sure if I'll get the packages that use this library in an
upstreamable state - but at least this one is.
---
package/Config.in | 1 +
package/imx-lib/Config.in | 53 ++++++++++++++++++++++++++++++++++++++++++++
package/imx-lib/imx-lib.mk | 41 ++++++++++++++++++++++++++++++++++
3 files changed, 95 insertions(+)
create mode 100644 package/imx-lib/Config.in
create mode 100644 package/imx-lib/imx-lib.mk
diff --git a/package/Config.in b/package/Config.in
index d6af55d..5151346 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -420,6 +420,7 @@ endmenu
menu "Hardware handling"
source "package/ccid/Config.in"
+source "package/imx-lib/Config.in"
source "package/lcdapi/Config.in"
source "package/libaio/Config.in"
source "package/libraw1394/Config.in"
diff --git a/package/imx-lib/Config.in b/package/imx-lib/Config.in
new file mode 100644
index 0000000..0ed452a
--- /dev/null
+++ b/package/imx-lib/Config.in
@@ -0,0 +1,53 @@
+comment "imx-lib needs an imx-specific kernel to be built"
+ depends on !BR2_LINUX_KERNEL
+
+config BR2_PACKAGE_IMX_LIB
+ bool "imx-lib"
+ depends on BR2_LINUX_KERNEL
+ depends on BR2_arm
+ help
+ Library of userspace helpers specific for the Freescale i.MX
+ platform. It wraps the kernel interfaces for some i.MX platform
+ specific drivers. It requires a kernel that includes the i.MX
+ specific headers to be built.
+
+ This library is provided by Freescale as-is and doesn't have
+ an upstream.
+
+if BR2_PACKAGE_IMX_LIB
+choice
+ prompt "i.MX platform"
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK
+ bool "imx25-3stack"
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS
+ bool "imx27ads"
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK
+ bool "imx37-3stack"
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50
+ bool "imx50"
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51
+ bool "imx51"
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53
+ bool "imx53"
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q
+ bool "imx6q"
+
+endchoice
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM
+ string
+ default "IMX25_3STACK" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK
+ default "IMX27ADS" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS
+ default "IMX37_3STACK" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK
+ default "IMX50" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50
+ default "IMX51" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51
+ default "IMX53" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53
+ default "IMX6Q" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q
+endif
diff --git a/package/imx-lib/imx-lib.mk b/package/imx-lib/imx-lib.mk
new file mode 100644
index 0000000..29f5ae1
--- /dev/null
+++ b/package/imx-lib/imx-lib.mk
@@ -0,0 +1,41 @@
+#############################################################
+#
+# imx-lib
+#
+#############################################################
+
+IMX_LIB_VERSION = 12.09.01
+# No official download site from freescale, just this mirror
+IMX_LIB_SITE = http://download.ossystems.com.br/bsp/freescale/source
+IMX_LIB_LICENSE = LGPLv2.1+
+# No license file included
+
+IMX_LIB_INSTALL_STAGING = YES
+
+# imx-lib needs access to imx-specific kernel headers
+IMX_LIB_DEPENDENCIES += linux
+IMX_LIB_INCLUDE = \
+ -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
+ -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
+ -I$(LINUX_DIR)/include
+
+IMX_LIB_MAKE_ENV = \
+ $(TARGET_MAKE_ENV) \
+ $(TARGET_CONFIGURE_OPTS) \
+ CROSS_COMPILE="$(CCACHE) $(TARGET_CROSS)" \
+ PLATFORM=$(BR2_PACKAGE_IMX_LIB_PLATFORM) \
+ INCLUDE="$(IMX_LIB_INCLUDE)"
+
+define IMX_LIB_BUILD_CMDS
+ $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D)
+endef
+
+define IMX_LIB_INSTALL_STAGING_CMDS
+ $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) DEST_DIR=$(STAGING_DIR) install
+endef
+
+define IMX_LIB_INSTALL_TARGET_CMDS
+ $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) DEST_DIR=$(TARGET_DIR) install
+endef
+
+$(eval $(generic-package))
--
1.7.10.4
^ permalink raw reply related
* [Buildroot] Results of an all-package build
From: Arnout Vandecappelle @ 2012-12-17 13:39 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50CEDCB3.2070705@mind.be>
On 17/12/12 09:49, Arnout Vandecappelle wrote:
> On 16/12/12 01:07, Peter Korsgaard wrote:
>>>>>>> >>>>>> "Arnout" == Arnout Vandecappelle<arnout@mind.be> writes:
>> >
>> > Hi,
>> >
>> > Arnout> As part of the test of the disable-doc patch I just sent, I
>> > Arnout> built something approaching an allyespackageconfig for x86_64
>> > Arnout> with a Sourcery-2012.09 toolchain. Interesting to look at the
>> > Arnout> results.
>> >
>> > Arnout> - The following fail to build:
>> >
>> > Arnout> * classpath
>> > Arnout> * diffutils
>> > Arnout> * gpsd
>> > Arnout> * ipsec-tools
>> > Arnout> * linux-pam
>> > Arnout> * ltp-testsuite
>> > Arnout> * matchbox-desktop
>> > Arnout> * metacity
>> > Arnout> * webkit
Webkit is fixed now.
>> > Arnout> * neard
>> > Arnout> * netatalk
Not fixed by lib64 patch...
>> > Arnout> * network-manager
>> > Arnout> * pcmanfm
>> > Arnout> * pv
>> > Arnout> * sconeserver-http-sconesite-image
Not fixed by using pkg-config...
>> > Arnout> * xdriver_xf86-video-geode
>> > Arnout> * xdriver_xf86-input-synaptics
>> > Arnout> * valgrind (because glibc 2.16 is not supported, needs valgrind bump)
>> > Arnout> * xstroke
>> > Arnout> * grub
>> > Arnout> * uboot (wrong ARCH parameter)
> I'll try to re-run current HEAD (which has fixed quite a few packages
> already) with make -k and put it on a pastebin.
The results of a make -k of just these packages (except for grub and
uboot) is on http://tny.cz/8f1cf19f .
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH] inadyn: Needs MMU
From: Maxime Ripard @ 2012-12-17 13:12 UTC (permalink / raw)
To: buildroot
Fixes
http://autobuild.buildroot.org/results/11d681a7f2c1d55a3d70573e9145aa231f6d4298/build-end.log
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
package/inadyn/Config.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/inadyn/Config.in b/package/inadyn/Config.in
index 623da41..a2dfa74 100644
--- a/package/inadyn/Config.in
+++ b/package/inadyn/Config.in
@@ -1,5 +1,6 @@
config BR2_PACKAGE_INADYN
bool "inadyn"
+ depends on BR2_USE_MMU # Uses fork()
help
INADYN is a free DynDNS client. It gives the possibility
to have your own fixed hostname registered on the internet,
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] [PATCH] [RFC] new target: live filesystem
From: Richard Genoud @ 2012-12-17 12:41 UTC (permalink / raw)
To: buildroot
In-Reply-To: <805796c3-1a48-4485-8d1b-5c1c5d2cbfb4@zimbra2.corp.accelance.fr>
2012/12/17 Jeremy Rosen <jeremy.rosen@openwide.fr>:
> Hello everybody
>
> there is a little bit more work to do on this patch (mainly updating a few more places in the documentation) but i'd like to have a go/no-go before I do that...
I was looking for that kind of feature, I hope it will be accepted.
For now, I use the output/target tree and those parameters in the
/etc/exports file:
*(rw,all_squash,no_subtree_check,anonuid=my_uid,anongid=my_gid)
But that means that all the FS is owned by my user.
Regards,
Richard.
^ permalink raw reply
* [Buildroot] [PATCH] package/liburcu: Requires threads support
From: Maxime Ripard @ 2012-12-17 11:32 UTC (permalink / raw)
To: buildroot
Fixes
http://autobuild.buildroot.org/results/eeb6a81588a12e5b572a4e5d27e001b3ae5eac49/build-end.log
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
package/liburcu/Config.in | 5 +++++
package/lttng-libust/Config.in | 6 ++++--
package/lttng-tools/Config.in | 7 ++++++-
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/package/liburcu/Config.in b/package/liburcu/Config.in
index 69878b1..f21541f 100644
--- a/package/liburcu/Config.in
+++ b/package/liburcu/Config.in
@@ -1,6 +1,7 @@
config BR2_PACKAGE_LIBURCU
bool "liburcu"
depends on BR2_arm || BR2_armeb || BR2_i386 || BR2_powerpc || BR2_x86_64
+ depends on BR2_TOOLCHAIN_HAS_THREADS
help
Userspace implementation of the Read-Copy-Update (RCU)
synchronization mechanism. This library is mainly used by
@@ -8,3 +9,7 @@ config BR2_PACKAGE_LIBURCU
purposes as well.
http://lttng.org/urcu
+
+comment "liburcu needs threads support in toolchain"
+ depends on !BR2_TOOLCHAIN_HAS_THREADS
+
diff --git a/package/lttng-libust/Config.in b/package/lttng-libust/Config.in
index ab12963..45e0ede 100644
--- a/package/lttng-libust/Config.in
+++ b/package/lttng-libust/Config.in
@@ -6,8 +6,9 @@ config BR2_PACKAGE_LTTNG_LIBUST
# util-linux needs wchar and largefile
depends on BR2_USE_WCHAR
depends on BR2_LARGEFILE
- # liburcu only works on some architectures
+ # liburcu only works on some architectures and requires threads support
depends on BR2_arm || BR2_armeb || BR2_i386 || BR2_powerpc || BR2_x86_64
+ depends on BR2_TOOLCHAIN_HAS_THREADS
help
Userspace tracing library for the Lttng tracing
infrastructure. It allows userspace programs to create
@@ -16,5 +17,6 @@ config BR2_PACKAGE_LTTNG_LIBUST
http://lttng.org
-comment "lttng-libust needs WCHAR and LARGEFILE support"
+comment "lttng-libust needs WCHAR, LARGEFILE and threads support"
depends on !(BR2_USE_WCHAR || BR2_LARGEFILE)
+ depends on !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/lttng-tools/Config.in b/package/lttng-tools/Config.in
index b854757..3d95eeb 100644
--- a/package/lttng-tools/Config.in
+++ b/package/lttng-tools/Config.in
@@ -3,8 +3,9 @@ config BR2_PACKAGE_LTTNG_TOOLS
depends on BR2_PACKAGE_LTTNG_MODULES
select BR2_PACKAGE_LIBURCU
select BR2_PACKAGE_POPT
- # liburcu only works on some architectures
+ # liburcu only works on some architectures and requires thread support
depends on BR2_arm || BR2_armeb || BR2_i386 || BR2_powerpc || BR2_x86_64
+ depends on BR2_TOOLCHAIN_HAS_THREADS
help
Userspace utilities for the LTTng 2.0 tracing
infrastructure.
@@ -22,3 +23,7 @@ config BR2_PACKAGE_LTTNG_TOOLS
lttng-libust.
http://lttng.org
+
+comment "lttng-tools needs threads support"
+ depends on !BR2_TOOLCHAIN_HAS_THREADS
+
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox