* [Buildroot] [PATCH] netatalk: fix 64-bit build
From: Arnout Vandecappelle @ 2012-12-17 22:15 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1355780891-26657-1-git-send-email-arnout@mind.be>
On 17/12/12 22:48, Arnout Vandecappelle (Essensium/Mind) wrote:
> 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>
Actually, this probably has nothing to do with 64-bit, but rather with
host==target...
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] linux: Support multiple device tree build
From: Arnout Vandecappelle @ 2012-12-17 22:13 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1355742312-25258-1-git-send-email-maxime.ripard@free-electrons.com>
On 17/12/12 12:05, Maxime Ripard wrote:
> Signed-off-by: Maxime Ripard<maxime.ripard@free-electrons.com>
> ---
> linux/linux.mk | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/linux/linux.mk b/linux/linux.mk
> index c4bdf90..c7d0099 100644
> --- a/linux/linux.mk
> +++ b/linux/linux.mk
> @@ -187,10 +187,12 @@ endef
> ifeq ($(BR2_LINUX_KERNEL_DTS_SUPPORT),y)
> ifeq ($(BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT),)
> define LINUX_BUILD_DTB
> - $(TARGET_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(KERNEL_DTS_NAME).dtb
> + $(TARGET_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) \
> + $(foreach dtbfile, $(call qstrip, $(KERNEL_DTS_NAME)), $(dtbfile).dtb)
I would personally prefer
$(addsuffix .dtb,$(call qstrip,$(KERNEL_DTS_NAME)))
> endef
> define LINUX_INSTALL_DTB
> - cp $(KERNEL_ARCH_PATH)/boot/$(KERNEL_DTS_NAME).dtb $(BINARIES_DIR)/
> + $(foreach dtbfile, $(call qstrip, $(KERNEL_DTS_NAME)),
> + cp $(KERNEL_ARCH_PATH)/boot/$(dtbfile).dtb $(BINARIES_DIR)/)
Does this work? I would expect you need a $(sep) or ; between the cp
statements...
But since it's a cp (not an install), you can put the foreach inside
the cp.
Regards,
Arnout
> endef
> endif
> endif
--
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] netatalk : Fix BerkeleyDB library path
From: Maxime Hadjinlian @ 2012-12-17 22:13 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50CF9728.7050806@mind.be>
On Mon, Dec 17, 2012 at 11:05 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 17/12/12 23:00, Maxime Hadjinlian wrote:
>>
>> On Mon, Dec 17, 2012 at 9:35 PM, Arnout Vandecappelle<arnout@mind.be>
>> wrote:
>>>
>>> On 17/12/12 00:15, Maxime Hadjinlian wrote:
>
> [snip]
>
>>> BDB_LIB isn't even used by configure, so I don't think does patch does
>>> much :-)
>>
>> You're right, it should be BDB_LIBS at least.
>
>
> But BDB_LIBS is unconditionally set by configure.
>
>
>
>>> 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...
>>
>> If I'm reading this correctly (and I'm not sure I am), there is one
>> bug with ls if you native hosts is 32bits but also, if you look the
>> value of atalk_libname, it will value lib64 and since the lib are not
>> put there by BerkeleyDB, it will also fail. And so we must look for
>> them in lib, right ? (That was I tried to fixed in my numerous
>> attempt).
>
>
> Yes, but the configure script already does that: if it fails to find it in
> $atalk_libname and $atalk_libname != lib then it tries again in lib.
Okay, I see what I missed and I'm looking at your patch, I'll go to
bed less stupid.
>
> Regards,
> Arnout
Thanks
>
> [snip]
>
> --
> 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: Benoît Thébaudeau @ 2012-12-17 22:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50CF9647.3020506@mind.be>
On Monday, December 17, 2012 11:01:43 PM, Arnout Vandecappelle wrote:
> On 17/12/12 21:44, Peter Korsgaard wrote:
> > Is the gst-fsl-plugins stuff still needed now that the coda driver
> > is in
> > mainline?
>
> Mainline v3.7 only has support for mx27 and mx51.
Even for mx27 and mx51, are you sure that the mainline implementation for CODA
is compatible with Freescale's imx-lib? I highly doubt it.
Regards,
Beno?t
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Benoît Thébaudeau @ 2012-12-17 22:08 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50CF9377.3040100@mind.be>
On Monday, December 17, 2012 10:49:43 PM, Arnout Vandecappelle wrote:
> On 17/12/12 20:40, Beno?t Th?baudeau wrote:
> >> > 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.
>
> I guess the custom toolchain isn't uClibc-based? Because it looks
> like
> some of the binary packages depend on glibc.
It is indeed glibc-based.
Regards,
Beno?t
^ permalink raw reply
* [Buildroot] [PATCH] netatalk : Fix BerkeleyDB library path
From: Arnout Vandecappelle @ 2012-12-17 22:05 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAGduivzGSNwizLx8WbC+BN6J=dbmcDRjNyB7zc0stccS3X1BoQ@mail.gmail.com>
On 17/12/12 23:00, Maxime Hadjinlian wrote:
> On Mon, Dec 17, 2012 at 9:35 PM, Arnout Vandecappelle<arnout@mind.be> wrote:
>> On 17/12/12 00:15, Maxime Hadjinlian wrote:
[snip]
>> BDB_LIB isn't even used by configure, so I don't think does patch does
>> much :-)
> You're right, it should be BDB_LIBS at least.
But BDB_LIBS is unconditionally set by configure.
>> 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...
> If I'm reading this correctly (and I'm not sure I am), there is one
> bug with ls if you native hosts is 32bits but also, if you look the
> value of atalk_libname, it will value lib64 and since the lib are not
> put there by BerkeleyDB, it will also fail. And so we must look for
> them in lib, right ? (That was I tried to fixed in my numerous
> attempt).
Yes, but the configure script already does that: if it fails to find it
in $atalk_libname and $atalk_libname != lib then it tries again in lib.
Regards,
Arnout
[snip]
--
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 22:01 UTC (permalink / raw)
To: buildroot
In-Reply-To: <87mwxc76je.fsf@dell.be.48ers.dk>
On 17/12/12 21:44, Peter Korsgaard wrote:
>>>>>> "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.
But of course, maintaining it per package is even more effort...
>
> Is the gst-fsl-plugins stuff still needed now that the coda driver is in
> mainline?
Mainline v3.7 only has support for mx27 and mx51.
> 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.
OK, I'll try to post patches before the end of the week.
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] netatalk : Fix BerkeleyDB library path
From: Maxime Hadjinlian @ 2012-12-17 22:00 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50CF8203.1010601@mind.be>
On Mon, Dec 17, 2012 at 9:35 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> 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...
I looked for it but I don't have one, I have although my host system
is 64bits, there should some bits in there...
>
> BDB_LIB isn't even used by configure, so I don't think does patch does
> much :-)
You're right, it should be BDB_LIBS at least.
>
>
> 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...
If I'm reading this correctly (and I'm not sure I am), there is one
bug with ls if you native hosts is 32bits but also, if you look the
value of atalk_libname, it will value lib64 and since the lib are not
put there by BerkeleyDB, it will also fail. And so we must look for
them in lib, right ? (That was I tried to fixed in my numerous
attempt).
So is it possible that there is two bugs enclosed here ?
>
> 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
> :-)
Which is obviously not what we want here :).
>
> I'll try to cook a fix and send a patch.
I'm really curious to see something, because I don't think I could
have figured this one out myself (given the lack of experience in
cross compiling and also my host being 64bits, well I'm short on
excuses).
>
> Regards,
> Arnout
Thanks !
>
> --
> 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 21:49 UTC (permalink / raw)
To: buildroot
In-Reply-To: <58636407.1033142.1355773226690.JavaMail.root@advansee.com>
On 17/12/12 20:40, Beno?t Th?baudeau wrote:
>> > 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.
I guess the custom toolchain isn't uClibc-based? Because it looks like
some of the binary packages depend on glibc.
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] 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
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