* [Buildroot] [PATCH v3 1/6] snowball-hdmiservice: new package
From: Grégory Hermant @ 2012-11-22 17:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50AE2FE3.8020801@mind.be>
Le 22/11/2012 15:00, Arnout Vandecappelle a ?crit :
> It should be passed in the environment, not in the make argument list.
> Otherwise it will override the definition in the Makefile itself.
>
> A good Makefile appends to LDFLAGS passed in from the environment, but this
> is not always the case... Anyway the worst that can happen is that the LDFLAGS
> are just ignored.
You mean that way:
SNOWBALL_HDMISERVICE_MAKE_ENV = CC="$(TARGET_CC)" CCFLAGS="$(TARGET_CCFLAGS)" LDFLAGS="$(TARGET_LDFLAGS)"
$(SNOWBALL_HDMISERVICE_MAKE_ENV) $(MAKE) -C $(@D)
BR,
gregory
^ permalink raw reply
* [Buildroot] pygtk and friends
From: Steve Morris @ 2012-11-22 17:06 UTC (permalink / raw)
To: buildroot
Hi All,
I'd like to use pygtk in a buildroot based project.
After some searching, the only references I found were patches ifrom
2007 to add pycairo, pygobject and pygtk. I'm sure I can use this a as
basis for adding to a current build, but I'm surprised I didn't find any
more recent references.
Is anybody already doing this, or perhaps there are unseen difficulties
which will become apparent later on?
Any pointers would be appreciated.
Thanks,
Steve
^ permalink raw reply
* [Buildroot] [autobuild.buildroot.net] Build results for 2012-11-21
From: Markos Chandras @ 2012-11-22 15:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121122073420.55E8652C105@lolut.humanoidz.org>
On Thu, Nov 22, 2012 at 7:34 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Hello,
>
>
> Status : NOK
> Failure reason : webkit-1.2.7
> Architecture : arm
> Submitted by : Thomas Petazzoni (Free Electrons build server)
> Submitted at : 2012-11-21 21:08:57
> Git commit ID : http://git.buildroot.net/buildroot/commit/?id=e1ebae700ace80ded99e1a977e28375dc4f7255d
> End of log : http://autobuild.buildroot.net/results/747fb6239b37cc958a5b35e5d6f843b016fab344/build-end.log
> Complete log : http://autobuild.buildroot.net/results/747fb6239b37cc958a5b35e5d6f843b016fab344/build.log.bz2
> Configuration : http://autobuild.buildroot.net/results/747fb6239b37cc958a5b35e5d6f843b016fab344/config
> Defconfig : http://autobuild.buildroot.net/results/747fb6239b37cc958a5b35e5d6f843b016fab344/defconfig
>
I had a brief look on this problem. This seems to be caused by
bison-2.6 like the upstream bug suggests[1]. Back-porting the patch[2]
to 1.2.7 is not trivial so I guess the easiest (and maybe safest)
thing to do is to bump this package to the latest release.
[1]https://bugs.webkit.org/show_bug.cgi?id=92264
[2]http://trac.webkit.org/changeset/124099
--
Regards,
Markos
^ permalink raw reply
* [Buildroot] [PATCH v3 1/6] snowball-hdmiservice: new package
From: Arnout Vandecappelle @ 2012-11-22 14:00 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50AE1C2D.8010905@calao-systems.com>
On 22/11/12 13:35, Gr?gory Hermant wrote:
> 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.
It should be passed in the environment, not in the make argument list.
Otherwise it will override the definition in the Makefile itself.
A good Makefile appends to LDFLAGS passed in from the environment, but this
is not always the case... Anyway the worst that can happen is that the LDFLAGS
are just ignored.
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 v2] gstreamer: Added option to disable plugin
From: Tim Sheridan @ 2012-11-22 13:53 UTC (permalink / raw)
To: buildroot
The plugin registry can take a while to be generated when GStreamer is initialized. Turning it off speeds up GStreamer application launch times. Default behaviour is unchanged.
Signed-off-by: Tim Sheridan <tim.sheridan@imgtec.com>
---
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] gstreamer: Added option to disable plugin registry.
From: Thomas Petazzoni @ 2012-11-22 13:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <98E3058E5505294895CA69F176CAD66272CE5E@LEMAIL01.le.imgtec.org>
Dear Tim Sheridan,
On Thu, 22 Nov 2012 13:19:05 +0000, Tim Sheridan wrote:
> Whoops, I forgot to include the sign-off for the patch. The amended patch is included below:
Please resend the patch properly, this one cannot be applied.
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] gstreamer: Added option to disable plugin registry.
From: Tim Sheridan @ 2012-11-22 13:19 UTC (permalink / raw)
To: buildroot
Whoops, I forgot to include the sign-off for the patch. The amended patch is included below:
---------SNIP---------
The plugin registry can take a while to be generated when GStreamer is
initialized. Turning it off speeds up GStreamer application launch times.
Default behavior unchanged.
Signed-off-by: Tim Sheridan <tim.sheridan@imgtec.com>
---
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] gdbserver for xtensa compilation error fix
From: Thomas Petazzoni @ 2012-11-22 12:56 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAJH6qScXgb_N9dUizhoXjzZ2eYp50poNHhrk2SQK=OCPoGBXXg@mail.gmail.com>
Dear Vadim Malenboim,
On Thu, 22 Nov 2012 14:42:32 +0200, Vadim Malenboim wrote:
> 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>
Thanks. This is already fix in Git by:
http://git.buildroot.net/buildroot/commit/?id=c28e15debff2078f4ef1b123e9a047a0cad2c18a
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] 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
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