* [Buildroot] gdbserver for xtensa compilation error fix
From: Vadim Malenboim @ 2012-11-22 12:42 UTC (permalink / raw)
To: buildroot
gdbserver compilation failed with :
rojects/xtensa-linux/JerryLinuxFP/buildroot/output/toolchain/gdb-7.3.1/gdb/gdbserver/linux-xtensa-low.c:137:5:
error: 'PTRACE_GETXTREGS' undeclared here (not in a function)
/projects/xtensa-linux/JerryLinuxFP/buildroot/output/toolchain/gdb-7.3.1/gdb/gdbserver/linux-xtensa-low.c:137:23:
error: 'PTRACE_SETXTREGS' undeclared here (not in a function)
make[1]: *** [linux-xtensa-low.o] Error 1
make[1]: *** Waiting for unfinished jobs....
fixed by modifying :
gdb/gdbserver/linux-xtensa-low.c line 26 :
from #include <sys/ptrace.h>
to #include <asm/ptrace.h>
--
* Vadim Malenboim.*
Low Level Software Engineer.
Cellular : +972(544)925862
E-Mail : vadim at tangotec.com
WEB : www.tangotec.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121122/0a46712e/attachment.html>
^ permalink raw reply
* [Buildroot] [PATCH v3 1/6] snowball-hdmiservice: new package
From: Grégory Hermant @ 2012-11-22 12:35 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50AC79F3.6000807@mind.be>
Arnout,
Le 21/11/2012 07:51, Arnout Vandecappelle a ?crit :
> On 15/11/12 09:25, Gregory Hermant wrote:
>>
>> Signed-off-by: Gregory Hermant<gregory.hermant@calao-systems.com>
> [snip]
>> +
>> +define SNOWBALL_HDMISERVICE_BUILD_CMDS
>> + $(MAKE) CC="$(TARGET_CC)" -C $(@D)
>> +endef
>
> I may have asked this before, but is there a reason to not pass buildroot's
> CFLAGS and LDFLAGS? We usually pass $(TARGET_CONFIGURE_OPTS) to sub-makes.
>
> [snip]
>
The build of the hdmiservice.so fails if i pass the buildroot's LDFLAGS.
> Regards,
> Arnout
>
BR,
gregory
^ permalink raw reply
* [Buildroot] [PATCH] barebox: use the symlink to copy the barebox binary to the images directory
From: Gregory Hermant @ 2012-11-22 12:35 UTC (permalink / raw)
To: buildroot
Barebox creates a symlink to the binary. This symlink points to
the barebox.bin or to the compressed zbarebox.bin binary.
Signed-off-by: Gregory Hermant <gregory.hermant@calao-systems.com>
---
boot/barebox/barebox.mk | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/boot/barebox/barebox.mk b/boot/barebox/barebox.mk
index a025d5f..6cc4976 100644
--- a/boot/barebox/barebox.mk
+++ b/boot/barebox/barebox.mk
@@ -72,7 +72,11 @@ define BAREBOX_BUILD_CMDS
endef
define BAREBOX_INSTALL_IMAGES_CMDS
- cp $(@D)/barebox.bin $(BINARIES_DIR)
+ if test -h $(@D)/barebox-flash-image ; then \
+ cp -L $(@D)/barebox-flash-image $(BINARIES_DIR)/barebox.bin ; \
+ else \
+ cp $(@D)/barebox.bin $(BINARIES_DIR);\
+ fi
endef
ifeq ($(BR2_TARGET_BAREBOX_BAREBOXENV),y)
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] crosstools build fails when hard fpu is selected
From: Thierry Bultel @ 2012-11-22 11:18 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121122095217.7408e82a@skate>
Le 22/11/2012 09:52, Thomas Petazzoni a ?crit :
> Dear Thierry Bultel,
>
> On Thu, 22 Nov 2012 09:46:24 +0100, Thierry Bultel wrote:
>
>> I thought that is was due to the fact that the "Use soft float by
>> default" option was not available when using an external toolchain (why
>> ?) but I have the same issue when crosstol-ng is built within buildroot
>> (and the option deselected of course)
>>
>> I am still investigating, but if you have a clue I would appreciate
>
>> /home/tbultel/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.6.3/../../../../arm-unknown-linux-gnueabi/bin/ld:
>> error: ../lib/libncurses.so.5.9 uses VFP register arguments,
>> ../obj_s/hardscroll.o does not
>
> From a quick look, it smells like not everybody has been built with the
> same CFLAGS or something like that. Like part of it has been built with
> hardfp, and some other with softfp. I would think "use VFP register
> arguments" means hardfp (floating point values are passed to functions
> through the floating-point registers). So libncurses.so.5.9 would be
> hardfp, and hardscroll.o would be softfp or soft-float and that cannot
> be linked together.
>
> Are you sure you disabled BR2_SOFT_FLOAT in Buildroot? Check the entire
> build log of ncurses to see which compiler flags are being passed.
>
Yes, I am definitively sure that BR2_SOFT_FLOAT is disabled in my .config
However I have BR2_PREFER_SOFT_FLOAT=y which is automatically set.
Looking at the build log, there are no '-mfpu=' flags at all when
invoking crosstool's gcc
I do not reproduce the issue with the CodeSourcery as external
toolchain, letting me think that my crosstool configuration is
wrong.
best regards
Thierry
> Best regards,
>
> Thomas
>
^ permalink raw reply
* [Buildroot] [PATCH 04/33] igh-ethercat: disable drivers build with kernel 3.6
From: Samuel Martin @ 2012-11-22 11:07 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121122111257.7cbf0562@skate>
2012/11/22 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Dear Samuel Martin,
>
> On Thu, 22 Nov 2012 01:17:54 +0100, Samuel Martin wrote:
>> Since hardware specific support is available for some given kernel
>> releases (mostly for kernel <=3.2), then disable them if kernel 3.6 is
>> enable. However, this still allows the generic driver build.
>>
>> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
>> ---
>> package/igh-ethercat/Config.in | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/package/igh-ethercat/Config.in b/package/igh-ethercat/Config.in
>> index 890bb12..4a0fd75 100644
>> --- a/package/igh-ethercat/Config.in
>> +++ b/package/igh-ethercat/Config.in
>> @@ -6,7 +6,12 @@ config BR2_PACKAGE_IGH_ETHERCAT
>>
>> http://www.etherlab.org/en/ethercat/index.php
>>
>> -if BR2_PACKAGE_IGH_ETHERCAT
>> +if BR2_PACKAGE_IGH_ETHERCAT && !BR2_LINUX_KERNEL_3_6
>> +
>> +comment "The following drivers are only available for some"
>> +comment "releases of the kernel (mostly 2.6.x)."
>> +comment "Further details about the kernel/hardware support at:"
>> +comment "http://www.etherlab.org/en/ethercat/hardware.php"
>
> I'm sorry but I don't quite understand neither the commit log nor the
> comment here. Could you explain a bit more? Is this fixing any sort of
> build problem?
You are right, it's not so clear... so lemme try to rephrase this:
igh-ethercat porvides some drivers for some specific kernel releases.
At configure time, we pass the kernel build directory.
igh-ethercat somehow finds the kernel version, then try to match it
among the available driver sources.
Here is what looks like the source tree:
z$ (cd output/build/igh-ethercat-1.5.1/ ; find devices/e1000e/ | sort
| head -n20)
devices/e1000e/
devices/e1000e/82571-2.6.32-ethercat.c
devices/e1000e/82571-2.6.32-orig.c
devices/e1000e/82571-2.6.33-ethercat.c
devices/e1000e/82571-2.6.33-orig.c
devices/e1000e/82571-2.6.34-ethercat.c
devices/e1000e/82571-2.6.34-orig.c
devices/e1000e/82571-2.6.35-ethercat.c
devices/e1000e/82571-2.6.35-orig.c
devices/e1000e/82571-2.6.37-ethercat.c
devices/e1000e/82571-2.6.37-orig.c
devices/e1000e/defines-2.6.32-ethercat.h
devices/e1000e/defines-2.6.32-orig.h
devices/e1000e/defines-2.6.33-ethercat.h
devices/e1000e/defines-2.6.33-orig.h
devices/e1000e/defines-2.6.34-ethercat.h
devices/e1000e/defines-2.6.34-orig.h
devices/e1000e/defines-2.6.35-ethercat.h
devices/e1000e/defines-2.6.35-orig.h
devices/e1000e/defines-2.6.37-ethercat.h
So whatever is your kernel release, it should match one of the
supported release listed at:
http://www.etherlab.org/en/ethercat/hardware.php
Otherwise, it fails :-/
Hope, it's clearer.
If you have any suggestion about how to rephrase both the help text
and/or the commit message,
please, share them.
Regards,
--
Sam
^ permalink raw reply
* [Buildroot] output/target isn't synced with the actual target
From: Thomas Petazzoni @ 2012-11-22 10:58 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAJH6qSeGCdkP7rZL7iVxRoHXu6n0R-26K+kTqxH3MB6zVyUO3A@mail.gmail.com>
Dear Vadim Malenboim,
On Thu, 22 Nov 2012 11:01:26 +0200, Vadim Malenboim wrote:
> I have libs in output/target/usr/lib but nothing on the actual target.
> In addition no all libs that are present in output/target/lib are actually
> present on the target.
Well, are you sure you did reflash/transfer the new root filesystem
image to your target?
If you want to check, enable the generation of a "tar" image in
Buildroot, and verify that all files are properly in the tarball.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] Fwd: can't resolve symbol 'wctob'
From: Gustavo Zacarias @ 2012-11-22 10:53 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAJH6qSde3UfP0=bQH0C=EDAGRFA3AVezNE=hUT6y41=b9vegtg@mail.gmail.com>
On 11/22/2012 07:48 AM, Vadim Malenboim wrote:
> I suspected that this is the issue, however I specially added it in the
> configuration.
> I'll do another build from scratch adding the WCHAR.
>
> Thank you.
Yes, changing toolchain options requires a complete rebuild.
Regards.
^ permalink raw reply
* [Buildroot] [PATCH 19/33] python2: bump to 2.7.3
From: Thomas Petazzoni @ 2012-11-22 10:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAHXCMML2DTvu9uGzDe9pb+qQXhAAfDAEOsouacV50_r-+8rPLg@mail.gmail.com>
Dear Samuel Martin,
On Thu, 22 Nov 2012 11:47:21 +0100, Samuel Martin wrote:
> 2012/11/22 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> > Dear Samuel Martin,
> >
> > On Thu, 22 Nov 2012 01:18:09 +0100, Samuel Martin wrote:
> >> Pyhton 2.7.3 includes several security fixes.
> >> See: http://www.python.org/download/releases/2.7.3/
> >>
> >> Also fixes the patch making sqlite optional.
> >>
> >> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> >> ---
> >> package/python/python-2.7-009-python-symlink.patch | 25 -----------------
> >
> > Any reason for removing this one?
> Yes, fixed upstream in the 2.7.3 release :-)
Awesome, something fixed upstream in Python \o/ :-)
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] Fwd: can't resolve symbol 'wctob'
From: Vadim Malenboim @ 2012-11-22 10:48 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50ADFE85.6010306@zacarias.com.ar>
I suspected that this is the issue, however I specially added it in the
configuration.
I'll do another build from scratch adding the WCHAR.
Thank you.
On Thu, Nov 22, 2012 at 12:29 PM, Gustavo Zacarias
<gustavo@zacarias.com.ar>wrote:
> You are missing WCHAR support.
>
--
* Vadim Malenboim.*
Low Level Software Engineer.
Cellular : +972(544)925862
E-Mail : vadim at tangotec.com
WEB : www.tangotec.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121122/bb84ca5e/attachment.html>
^ permalink raw reply
* [Buildroot] [PATCH 19/33] python2: bump to 2.7.3
From: Samuel Martin @ 2012-11-22 10:47 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121122111612.4bfdeee2@skate>
2012/11/22 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Dear Samuel Martin,
>
> On Thu, 22 Nov 2012 01:18:09 +0100, Samuel Martin wrote:
>> Pyhton 2.7.3 includes several security fixes.
>> See: http://www.python.org/download/releases/2.7.3/
>>
>> Also fixes the patch making sqlite optional.
>>
>> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
>> ---
>> package/python/python-2.7-009-python-symlink.patch | 25 -----------------
>
> Any reason for removing this one?
Yes, fixed upstream in the 2.7.3 release :-)
Oops, sorry I forgot to mention this in the commit message; I'll fix it.
Regards,
--
Sam
^ permalink raw reply
* [Buildroot] [PATCH 03/33] tcpdump: use 'pkg-config pcap' instead of pcap-config
From: Samuel Martin @ 2012-11-22 10:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121122111041.73d397ee@skate>
Hi Thomas,
2012/11/22 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Dear Samuel Martin,
>
> On Thu, 22 Nov 2012 01:17:53 +0100, Samuel Martin wrote:
>
>> +- AC_PATH_TOOL(PCAP_CONFIG, pcap-config)
>> ++ AC_PATH_TOOL(PCAP_CONFIG, pkg-config)
>
> This is not generally how pkg-config is used. In general, people use
> the PKG_CHECK_MODULES() autoconf macro.
>
> Has this been pushed upstream?
I've not tried to push this patch upstream yet.
> I guess you need to make it smarter
> like: start testing with pkg-config, then fallback to pcap-config, in
> order to make this suitable for upstream.
I agree.
The truth is I'm not so confident with autotools, so any enlightment is welcome.
Regards,
--
Sam
^ permalink raw reply
* [Buildroot] [PATCH] gstreamer: Added option to disable plugin registry.
From: Tim Sheridan @ 2012-11-22 10:43 UTC (permalink / raw)
To: buildroot
The plugin registry can take a while to be generated when GStreamer is
initialized. Turning it off can speed up GStreamer application launch times.
Default behavior is unchanged.
---
package/multimedia/gstreamer/Config.in | 9 +++++++++
package/multimedia/gstreamer/gstreamer.mk | 3 ++-
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/package/multimedia/gstreamer/Config.in b/package/multimedia/gstreamer/Config.in
index 4d279b8..e946b18 100644
--- a/package/multimedia/gstreamer/Config.in
+++ b/package/multimedia/gstreamer/Config.in
@@ -16,5 +16,14 @@ config BR2_PACKAGE_GSTREAMER_GST_DEBUG
in gstreamer. This has limited CPU overhead, but does
increase the rootfs size somewhat.
+config BR2_PACKAGE_GSTREAMER_PLUGIN_REGISTRY
+ bool "enable plugin registry"
+ default y
+ depends on BR2_PACKAGE_GSTREAMER
+ help
+ Enable support for the GStreamer plugin registry.
+ This may increase the launch-time for a GStreamer
+ application.
+
comment "gstreamer requires a toolchain with WCHAR support"
depends on !BR2_USE_WCHAR
diff --git a/package/multimedia/gstreamer/gstreamer.mk b/package/multimedia/gstreamer/gstreamer.mk
index a9841b1..b87f029 100644
--- a/package/multimedia/gstreamer/gstreamer.mk
+++ b/package/multimedia/gstreamer/gstreamer.mk
@@ -21,7 +21,8 @@ GSTREAMER_CONF_OPT = \
--disable-tests \
--disable-failing-tests \
--disable-loadsave \
- $(if $(BR2_PACKAGE_GSTREAMER_GST_DEBUG),,--disable-gst-debug)
+ $(if $(BR2_PACKAGE_GSTREAMER_GST_DEBUG),,--disable-gst-debug) \
+ $(if $(BR2_PACKAGE_GSTREAMER_PLUGIN_REGISTRY),,--disable-registry)
GSTREAMER_DEPENDENCIES = libglib2 host-pkgconf
--
1.7.1
^ permalink raw reply related
* [Buildroot] [PATCH 02/33] libpcap: add pcap.pc file
From: Samuel Martin @ 2012-11-22 10:39 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121122110905.4b984053@skate>
2012/11/22 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Dear Samuel Martin,
>
> On Thu, 22 Nov 2012 01:17:52 +0100, Samuel Martin wrote:
>>
>> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
>> ---
>> package/libpcap/libpcap.mk | 10 ++++++++++
>> package/libpcap/pcap.pc | 12 ++++++++++++
>> 2 files changed, 22 insertions(+)
>> create mode 100644 package/libpcap/pcap.pc
>
> I don't remember if I asked the question already or not, but anyway:
> has this pcap.pc been pushed upstream?
Not yet, I'll do it.
Regards,
--
Sam
^ permalink raw reply
* [Buildroot] Fwd: can't resolve symbol 'wctob'
From: Gustavo Zacarias @ 2012-11-22 10:29 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAJH6qSdrqbOQ_oV6TcitJ0=P5G_A950GvKAOWWfUtvwLAcvhMQ@mail.gmail.com>
On 11/22/2012 07:20 AM, Vadim Malenboim wrote:
> I have a uclibc based toolchain compiled with application.
> When I try to run it on target I receive - can't resolve symbol 'wctob'
>
> I understand that it is missing somewhere in the uclibc.
> Where do I need to add it ?
You are missing WCHAR support.
Regards.
^ permalink raw reply
* [Buildroot] Fwd: can't resolve symbol 'wctob'
From: Vadim Malenboim @ 2012-11-22 10:20 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAJH6qSd6eEdg1pUK9e4tOS=1rw0xhN397Q=rx-Rmehi8fPcpeg@mail.gmail.com>
I have a uclibc based toolchain compiled with application.
When I try to run it on target I receive - can't resolve symbol 'wctob'
I understand that it is missing somewhere in the uclibc.
Where do I need to add it ?
--
* Vadim Malenboim.*
Low Level Software Engineer.
Cellular : +972(544)925862
E-Mail : vadim at tangotec.com
WEB : www.tangotec.com
--
* Vadim Malenboim.*
Low Level Software Engineer.
Cellular : +972(544)925862
E-Mail : vadim at tangotec.com
WEB : www.tangotec.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121122/d88a1723/attachment.html>
^ permalink raw reply
* [Buildroot] [PATCH 19/33] python2: bump to 2.7.3
From: Thomas Petazzoni @ 2012-11-22 10:16 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353543503-8952-20-git-send-email-s.martin49@gmail.com>
Dear Samuel Martin,
On Thu, 22 Nov 2012 01:18:09 +0100, Samuel Martin wrote:
> Pyhton 2.7.3 includes several security fixes.
> See: http://www.python.org/download/releases/2.7.3/
>
> Also fixes the patch making sqlite optional.
>
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
> package/python/python-2.7-009-python-symlink.patch | 25 -----------------
Any reason for removing this one?
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH 04/33] igh-ethercat: disable drivers build with kernel 3.6
From: Thomas Petazzoni @ 2012-11-22 10:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353543503-8952-5-git-send-email-s.martin49@gmail.com>
Dear Samuel Martin,
On Thu, 22 Nov 2012 01:17:54 +0100, Samuel Martin wrote:
> Since hardware specific support is available for some given kernel
> releases (mostly for kernel <=3.2), then disable them if kernel 3.6 is
> enable. However, this still allows the generic driver build.
>
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
> package/igh-ethercat/Config.in | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/package/igh-ethercat/Config.in b/package/igh-ethercat/Config.in
> index 890bb12..4a0fd75 100644
> --- a/package/igh-ethercat/Config.in
> +++ b/package/igh-ethercat/Config.in
> @@ -6,7 +6,12 @@ config BR2_PACKAGE_IGH_ETHERCAT
>
> http://www.etherlab.org/en/ethercat/index.php
>
> -if BR2_PACKAGE_IGH_ETHERCAT
> +if BR2_PACKAGE_IGH_ETHERCAT && !BR2_LINUX_KERNEL_3_6
> +
> +comment "The following drivers are only available for some"
> +comment "releases of the kernel (mostly 2.6.x)."
> +comment "Further details about the kernel/hardware support at:"
> +comment "http://www.etherlab.org/en/ethercat/hardware.php"
I'm sorry but I don't quite understand neither the commit log nor the
comment here. Could you explain a bit more? Is this fixing any sort of
build problem?
Also !BR2_LINUX_KERNEL_3_6 works only if the user isn't using a custom
Git tree or something like that.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH 03/33] tcpdump: use 'pkg-config pcap' instead of pcap-config
From: Thomas Petazzoni @ 2012-11-22 10:10 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353543503-8952-4-git-send-email-s.martin49@gmail.com>
Dear Samuel Martin,
On Thu, 22 Nov 2012 01:17:53 +0100, Samuel Martin wrote:
> +- AC_PATH_TOOL(PCAP_CONFIG, pcap-config)
> ++ AC_PATH_TOOL(PCAP_CONFIG, pkg-config)
This is not generally how pkg-config is used. In general, people use
the PKG_CHECK_MODULES() autoconf macro.
Has this been pushed upstream? I guess you need to make it smarter
like: start testing with pkg-config, then fallback to pcap-config, in
order to make this suitable for upstream.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH 02/33] libpcap: add pcap.pc file
From: Thomas Petazzoni @ 2012-11-22 10:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353543503-8952-3-git-send-email-s.martin49@gmail.com>
Dear Samuel Martin,
On Thu, 22 Nov 2012 01:17:52 +0100, Samuel Martin wrote:
>
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
> package/libpcap/libpcap.mk | 10 ++++++++++
> package/libpcap/pcap.pc | 12 ++++++++++++
> 2 files changed, 22 insertions(+)
> create mode 100644 package/libpcap/pcap.pc
I don't remember if I asked the question already or not, but anyway:
has this pcap.pc been pushed upstream?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH 32/33] rrdtool: add license info
From: Samuel Martin @ 2012-11-22 10:07 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121122051744.GA10958@sapphire.tkos.co.il>
Hi Baruch, all,
2012/11/22 Baruch Siach <baruch@tkos.co.il>:
> Hi Samuel,
>
> On Thu, Nov 22, 2012 at 01:18:22AM +0100, Samuel Martin wrote:
>>
>> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
>> ---
>> package/rrdtool/rrdtool.mk | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/package/rrdtool/rrdtool.mk b/package/rrdtool/rrdtool.mk
>> index 8799a85..4392b50 100644
>> --- a/package/rrdtool/rrdtool.mk
>> +++ b/package/rrdtool/rrdtool.mk
>> @@ -6,6 +6,9 @@
>>
>> RRDTOOL_VERSION = 1.2.30
>> RRDTOOL_SITE = http://oss.oetiker.ch/rrdtool/pub
>> +RRDTOOL_LICENSE = GPLv2+ with FLOSS license exceptions as explained in COPYRIGHT
>> +RRDTOOL_LICENSE_FILES = COPYING
>
> Shouldn't COPYRIGHT also be listed with the license files?
The Copyright file just tells us "wrt the license, you can do that and
that, but not that with this software",
with some real use case.
Shall we consider as part of the license files?
Regards,
--
Sam
^ permalink raw reply
* [Buildroot] [PATCH] arptables: needs mmu
From: Gustavo Zacarias @ 2012-11-22 9:46 UTC (permalink / raw)
To: buildroot
arptables uses fork() and breaks on !mmu.
Fixes
http://autobuild.buildroot.net/results/fe18dd4a0b0d17404560abf3e4a332b58751f5cb/
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/arptables/Config.in | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/package/arptables/Config.in b/package/arptables/Config.in
index 510eedf..414fabb 100644
--- a/package/arptables/Config.in
+++ b/package/arptables/Config.in
@@ -1,5 +1,7 @@
config BR2_PACKAGE_ARPTABLES
bool "arptables"
+ # needs fork()
+ depends on BR2_USE_MMU
help
Tool to set up, maintain, and inspect the tables of ARP rules.
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] output/target isn't synced with the actual target
From: Vadim Malenboim @ 2012-11-22 9:01 UTC (permalink / raw)
To: buildroot
Hello,
I have libs in output/target/usr/lib but nothing on the actual target.
In addition no all libs that are present in output/target/lib are actually
present on the target.
On host :
-rwxr-xr-x 1 vadim tangotec 21224 Nov 22 09:45 ld-uClibc-0.9.34-git.so
lrwxrwxrwx 1 vadim tangotec 23 Nov 22 09:42 ld-uClibc.so.0 ->
ld-uClibc-0.9.34-git.so
-rwxr-xr-x 1 vadim tangotec 9456 Nov 22 09:45 libcrypt-0.9.34-git.so
lrwxrwxrwx 1 vadim tangotec 22 Nov 22 09:42 libcrypt.so.0 ->
libcrypt-0.9.34-git.so
lrwxrwxrwx 1 vadim tangotec 23 Nov 22 09:42 libc.so.0 ->
libuClibc-0.9.34-git.so
-rwxr-xr-x 1 vadim tangotec 8384 Nov 22 09:45 libdl-0.9.34-git.so
lrwxrwxrwx 1 vadim tangotec 19 Nov 22 09:42 libdl.so.0 ->
libdl-0.9.34-git.so
lrwxrwxrwx 1 vadim tangotec 13 Nov 22 09:44 libgcc_s.so -> libgcc_s.so.1
-rw-r--r-- 1 vadim tangotec 49764 Nov 22 09:44 libgcc_s.so.1
-rwxr-xr-x 1 vadim tangotec 65708 Nov 22 09:45 libm-0.9.34-git.so
lrwxrwxrwx 1 vadim tangotec 18 Nov 22 09:42 libm.so.0 ->
libm-0.9.34-git.so
-rwxr-xr-x 1 vadim tangotec 1332 Nov 22 09:45 libnsl-0.9.34-git.so
lrwxrwxrwx 1 vadim tangotec 20 Nov 22 09:42 libnsl.so.0 ->
libnsl-0.9.34-git.so
-rwxr-xr-x 1 vadim tangotec 62080 Nov 22 09:45 libpthread-0.9.34-git.so
lrwxrwxrwx 1 vadim tangotec 24 Nov 22 09:42 libpthread.so.0 ->
libpthread-0.9.34-git.so
-rwxr-xr-x 1 vadim tangotec 1340 Nov 22 09:45 libresolv-0.9.34-git.so
lrwxrwxrwx 1 vadim tangotec 23 Nov 22 09:42 libresolv.so.0 ->
libresolv-0.9.34-git.so
-rwxr-xr-x 1 vadim tangotec 8224 Nov 22 09:45 librt-0.9.34-git.so
lrwxrwxrwx 1 vadim tangotec 19 Nov 22 09:42 librt.so.0 ->
librt-0.9.34-git.so
-rwxr-xr-x 1 vadim tangotec 4380 Nov 22 09:45 libubacktrace-0.9.34-git.so
lrwxrwxrwx 1 vadim tangotec 27 Nov 22 09:42 libubacktrace.so.0 ->
libubacktrace-0.9.34-git.so
-rwxr-xr-x 1 vadim tangotec 329184 Nov 22 09:45 libuClibc-0.9.34-git.so
-rwxr-xr-x 1 vadim tangotec 4656 Nov 22 09:45 libutil-0.9.34-git.so
lrwxrwxrwx 1 vadim tangotec 21 Nov 22 09:42 libutil.so.0 ->
libutil-0.9.34-git.so
[vadim at xn02 buildroot]$ cp output/target/usr/lib/libstdc++.so.6
/tftpboot/vadim/
On target :
-rwxr-xr-x 1 root root 21224 Nov 22 2012
ld-uClibc-0.9.34-git.so
lrwxrwxrwx 1 root root 23 Nov 22 2012 ld-uClibc.so.0 ->
ld-uClibc-0.9.34-git.so
lrwxrwxrwx 1 root root 23 Nov 22 2012 libc.so.0 ->
libuClibc-0.9.34-git.so
-rwxr-xr-x 1 root root 9456 Nov 22 2012
libcrypt-0.9.34-git.so
lrwxrwxrwx 1 root root 22 Nov 22 2012 libcrypt.so.0 ->
libcrypt-0.9.34-git.so
-rwxr-xr-x 1 root root 8384 Nov 22 2012 libdl-0.9.34-git.so
lrwxrwxrwx 1 root root 19 Nov 22 2012 libdl.so.0 ->
libdl-0.9.34-git.so
lrwxrwxrwx 1 root root 13 Nov 22 2012 libgcc_s.so ->
libgcc_s.so.1
-rw-r--r-- 1 root root 49764 Nov 22 2012 libgcc_s.so.1
-rwxr-xr-x 1 root root 65708 Nov 22 2012 libm-0.9.34-git.so
lrwxrwxrwx 1 root root 18 Nov 22 2012 libm.so.0 ->
libm-0.9.34-git.so
-rwxr-xr-x 1 root root 1332 Nov 22 2012
libnsl-0.9.34-git.so
lrwxrwxrwx 1 root root 20 Nov 22 2012 libnsl.so.0 ->
libnsl-0.9.34-git.so
-rwxr-xr-x 1 root root 62080 Nov 22 2012
libpthread-0.9.34-git.so
lrwxrwxrwx 1 root root 24 Nov 22 2012 libpthread.so.0 ->
libpthread-0.9.34-git.so
-rwxr-xr-x 1 root root 1340 Nov 22 2012
libresolv-0.9.34-git.so
lrwxrwxrwx 1 root root 23 Nov 22 2012 libresolv.so.0 ->
libresolv-0.9.34-git.so
-rwxr-xr-x 1 root root 8224 Nov 22 2012 librt-0.9.34-git.so
lrwxrwxrwx 1 root root 19 Nov 22 2012 librt.so.0 ->
librt-0.9.34-git.so
-rwxr-xr-x 1 root root 293484 Nov 22 2012
libuClibc-0.9.34-git.so
-rwxr-xr-x 1 root root 4656 Nov 22 2012
libutil-0.9.34-git.so
lrwxrwxrwx 1 root root 21 Nov 22 2012 libutil.so.0 ->
libutil-0.9.34-git.so
# tftp -g -r /vadim/libstdc++.so.6 192.168.217.32
--
* Vadim Malenboim.*
Low Level Software Engineer.
Cellular : +972(544)925862
E-Mail : vadim at tangotec.com
WEB : www.tangotec.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121122/026ea662/attachment-0001.html>
^ permalink raw reply
* [Buildroot] crosstools build fails when hard fpu is selected
From: Thomas Petazzoni @ 2012-11-22 8:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50ADE660.6000802@wanadoo.fr>
Dear Thierry Bultel,
On Thu, 22 Nov 2012 09:46:24 +0100, Thierry Bultel wrote:
> I thought that is was due to the fact that the "Use soft float by
> default" option was not available when using an external toolchain (why
> ?) but I have the same issue when crosstol-ng is built within buildroot
> (and the option deselected of course)
>
> I am still investigating, but if you have a clue I would appreciate
> /home/tbultel/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.6.3/../../../../arm-unknown-linux-gnueabi/bin/ld:
> error: ../lib/libncurses.so.5.9 uses VFP register arguments,
> ../obj_s/hardscroll.o does not
From a quick look, it smells like not everybody has been built with the
same CFLAGS or something like that. Like part of it has been built with
hardfp, and some other with softfp. I would think "use VFP register
arguments" means hardfp (floating point values are passed to functions
through the floating-point registers). So libncurses.so.5.9 would be
hardfp, and hardscroll.o would be softfp or soft-float and that cannot
be linked together.
Are you sure you disabled BR2_SOFT_FLOAT in Buildroot? Check the entire
build log of ncurses to see which compiler flags are being passed.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] crosstools build fails when hard fpu is selected
From: Thierry Bultel @ 2012-11-22 8:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121121132549.7c180f2f@skate>
Thanks Thomas,
thanks to Yann's advice,
I have been able to generate an ARM gcc with Neon support,
and performed some performance testing on my target.
( the root filesystem is for now the one with soft float).
But this is an external crosstool-ng (1.17.0) build.
Thus I have attempted to configure Buildroot to use this
external toolchain.
The build fails at ncurses (see below)
I thought that is was due to the fact that the "Use soft float by
default" option was not available when using an external toolchain (why
?) but I have the same issue when crosstol-ng is built within buildroot
(and the option deselected of course)
I am still investigating, but if you have a clue I would appreciate
Thanks
Thierry
>>> ncurses 5.9 Building
/usr/bin/make -j1 -C
/shared/Buildroot/output.imx6hardfpu/build/ncurses-5.9
DESTDIR=/shared/Buildroot/output.imx6hardfpu/host/usr/arm-unknown-linux-gnueabi/sysroot
make[1]: entrant dans le r?pertoire ?
/bigdisk/shared/Buildroot/output.imx6hardfpu/build/ncurses-5.9 ?
cd man && /usr/bin/make -w --
DESTDIR=/shared/Buildroot/output.imx6hardfpu/host/usr/arm-unknown-linux-gnueabi/sysroot
DESTDIR="/shared/Buildroot/output.imx6hardfpu/host/usr/arm-unknown-linux-gnueabi/sysroot"
all
make[2]: entrant dans le r?pertoire ?
/bigdisk/shared/Buildroot/output.imx6hardfpu/build/ncurses-5.9/man ?
make[2]: Rien ? faire pour ? all ?.
make[2]: quittant le r?pertoire ?
/bigdisk/shared/Buildroot/output.imx6hardfpu/build/ncurses-5.9/man ?
cd include && /usr/bin/make -w --
DESTDIR=/shared/Buildroot/output.imx6hardfpu/host/usr/arm-unknown-linux-gnueabi/sysroot
DESTDIR="/shared/Buildroot/output.imx6hardfpu/host/usr/arm-unknown-linux-gnueabi/sysroot"
all
make[2]: entrant dans le r?pertoire ?
/bigdisk/shared/Buildroot/output.imx6hardfpu/build/ncurses-5.9/include ?
make[2]: Rien ? faire pour ? all ?.
make[2]: quittant le r?pertoire ?
/bigdisk/shared/Buildroot/output.imx6hardfpu/build/ncurses-5.9/include ?
cd ncurses && /usr/bin/make -w --
DESTDIR=/shared/Buildroot/output.imx6hardfpu/host/usr/arm-unknown-linux-gnueabi/sysroot
DESTDIR="/shared/Buildroot/output.imx6hardfpu/host/usr/arm-unknown-linux-gnueabi/sysroot"
all
make[2]: entrant dans le r?pertoire ?
/bigdisk/shared/Buildroot/output.imx6hardfpu/build/ncurses-5.9/ncurses ?
linking ../lib/libncurses.so.5.9
/shared/Buildroot/output.imx6hardfpu/host/usr/bin/ccache
/shared/Buildroot/output.imx6hardfpu/host/usr/bin/arm-unknown-linux-gnueabi-gcc
-pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 --param max-inline-insns-single=1200 -shared
-Wl,-soname,`basename ../lib/libncurses.so.5.9 .5.9`.5,-stats,-lc -o
../lib/libncurses.so.5.9 ../obj_s/hardscroll.o ../obj_s/hashmap.o
../obj_s/lib_addch.o ../obj_s/lib_addstr.o ../obj_s/lib_beep.o
../obj_s/lib_bkgd.o ../obj_s/lib_box.o ../obj_s/lib_chgat.o
../obj_s/lib_clear.o ../obj_s/lib_clearok.o ../obj_s/lib_clrbot.o
../obj_s/lib_clreol.o ../obj_s/lib_color.o ../obj_s/lib_colorset.o
../obj_s/lib_delch.o ../obj_s/lib_delwin.o ../obj_s/lib_echo.o
../obj_s/lib_endwin.o ../obj_s/lib_erase.o ../obj_s/lib_flash.o
../obj_s/lib_gen.o ../obj_s/lib_getch.o ../obj_s/lib_getstr.o
../obj_s/lib_hline.o ../obj_s/lib_immedok.o ../obj_s/lib_inchstr.o
../obj_s/lib_initscr.o ../obj_s/lib_insch.o ../obj_s/lib_insdel.o
../obj_s/lib_insnstr.o ../obj_s/lib_instr.o ../obj_s/lib_isendwin.o
../obj_s/lib_leaveok.o ../obj_s/lib_mouse.o ../obj_s/lib_move.o
../obj_s/lib_mvcur.o ../obj_s/lib_mvwin.o ../obj_s/lib_newterm.o
../obj_s/lib_newwin.o ../obj_s/lib_nl.o ../obj_s/lib_overlay.o
../obj_s/lib_pad.o ../obj_s/lib_printw.o ../obj_s/lib_redrawln.o
../obj_s/lib_refresh.o ../obj_s/lib_restart.o ../obj_s/lib_scanw.o
../obj_s/lib_screen.o ../obj_s/lib_scroll.o ../obj_s/lib_scrollok.o
../obj_s/lib_scrreg.o ../obj_s/lib_set_term.o ../obj_s/lib_slk.o
../obj_s/lib_slkatr_set.o ../obj_s/lib_slkatrof.o
../obj_s/lib_slkatron.o ../obj_s/lib_slkatrset.o ../obj_s/lib_slkattr.o
../obj_s/lib_slkclear.o ../obj_s/lib_slkcolor.o ../obj_s/lib_slkinit.o
../obj_s/lib_slklab.o ../obj_s/lib_slkrefr.o ../obj_s/lib_slkset.o
../obj_s/lib_slktouch.o ../obj_s/lib_touch.o ../obj_s/lib_tstp.o
../obj_s/lib_ungetch.o ../obj_s/lib_vidattr.o ../obj_s/lib_vline.o
../obj_s/lib_wattroff.o ../obj_s/lib_wattron.o ../obj_s/lib_winch.o
../obj_s/lib_window.o ../obj_s/nc_panel.o ../obj_s/safe_sprintf.o
../obj_s/tty_update.o ../obj_s/varargs.o ../obj_s/memmove.o
../obj_s/vsscanf.o ../obj_s/lib_freeall.o ../obj_s/expanded.o
../obj_s/legacy_coding.o ../obj_s/lib_dft_fgbg.o ../obj_s/lib_print.o
../obj_s/resizeterm.o ../obj_s/use_screen.o ../obj_s/use_window.o
../obj_s/wresize.o ../obj_s/access.o ../obj_s/add_tries.o
../obj_s/alloc_ttype.o ../obj_s/codes.o ../obj_s/comp_captab.o
../obj_s/comp_error.o ../obj_s/comp_hash.o ../obj_s/db_iterator.o
../obj_s/doalloc.o ../obj_s/entries.o ../obj_s/fallback.o
../obj_s/free_ttype.o ../obj_s/getenv_num.o ../obj_s/home_terminfo.o
../obj_s/init_keytry.o ../obj_s/lib_acs.o ../obj_s/lib_baudrate.o
../obj_s/lib_cur_term.o ../obj_s/lib_data.o ../obj_s/lib_has_cap.o
../obj_s/lib_kernel.o ../obj_s/lib_keyname.o ../obj_s/lib_longname.o
../obj_s/lib_napms.o ../obj_s/lib_options.o ../obj_s/lib_raw.o
../obj_s/lib_setup.o ../obj_s/lib_termcap.o ../obj_s/lib_termname.o
../obj_s/lib_tgoto.o ../obj_s/lib_ti.o ../obj_s/lib_tparm.o
../obj_s/lib_tputs.o ../obj_s/lib_trace.o ../obj_s/lib_ttyflags.o
../obj_s/lib_twait.o ../obj_s/name_match.o ../obj_s/names.o
../obj_s/read_entry.o ../obj_s/read_termcap.o ../obj_s/setbuf.o
../obj_s/strings.o ../obj_s/tries.o ../obj_s/trim_sgr0.o
../obj_s/unctrl.o ../obj_s/visbuf.o ../obj_s/define_key.o
../obj_s/hashed_db.o ../obj_s/key_defined.o ../obj_s/keybound.o
../obj_s/keyok.o ../obj_s/version.o -L../lib
/home/tbultel/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.6.3/../../../../arm-unknown-linux-gnueabi/bin/ld:
error: ../lib/libncurses.so.5.9 uses VFP register arguments,
../obj_s/hardscroll.o does not
Le 21/11/2012 13:25, Thomas Petazzoni a ?crit :
> Dear Thierry Bultel,
>
> On Wed, 21 Nov 2012 11:23:20 +0100, Thierry Bultel wrote:
>
>> GCC has not been generated with the harware FPU support.
>>
>> I have attempted several hacks into
>> toolchain/toolchain-crosstool-ng/crosstool-ng.config-glibc
>>
>> ... with no better success
>>
>> Any ideas ?
>
> Yes, raise this problem on the crosstool-ng mailing list. I know Yann
> is aware of this, and he will most likely have recommendations on how
> to fix this problem.
>
> Thanks,
>
> Thomas
>
^ permalink raw reply
* [Buildroot] [PATCH 1/2] kernel-headers: bump 3.{0, 2, 4, 6}.x stable versions
From: Peter Korsgaard @ 2012-11-22 7:56 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353494120-19414-1-git-send-email-gustavo@zacarias.com.ar>
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:
Gustavo> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Committed both, thanks,
--
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