Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH 2/3] xtensa: fix target gdb build and 64-bit host side gdb
From: Peter Korsgaard @ 2012-11-21 10:15 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <50ac8f62.a3c9440a.59e4.fffff6d9@mx.google.com>

>>>>> "Chris" == Chris Zankel <chris@zankel.net> writes:

 Chris> Fix build breakage, use the version of the ptrace header file in asm
 Chris> instead of sys. Also, fix GDB running on 64 bit hosts. GDB was using
 Chris> unsigned long for 32-bit registers, but unsigned long is 64 bit on
 Chris> 64-bit hosts.

Committed, thanks.

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* [Buildroot] [git commit] Remove unused barebox 2012.07 string
From: Peter Korsgaard @ 2012-11-21 10:17 UTC (permalink / raw)
  To: buildroot

commit: http://git.buildroot.net/buildroot/commit/?id=8f717d54ba37d289e9e15b2a302cd4d2fe3fb93c
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 boot/barebox/Config.in |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/boot/barebox/Config.in b/boot/barebox/Config.in
index 997f45b..95f330f 100644
--- a/boot/barebox/Config.in
+++ b/boot/barebox/Config.in
@@ -41,7 +41,6 @@ endif
 
 config BR2_TARGET_BAREBOX_VERSION
 	string
-	default "2012.07.0"	if BR2_TARGET_BAREBOX_2012_07
 	default "2012.08.0"	if BR2_TARGET_BAREBOX_2012_08
 	default "2012.09.0"	if BR2_TARGET_BAREBOX_2012_09
 	default "2012.10.0"	if BR2_TARGET_BAREBOX_2012_10

^ permalink raw reply related

* [Buildroot] [PATCH] Remove unused barebox 2012.07 string
From: Peter Korsgaard @ 2012-11-21 10:17 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1353492492-29514-1-git-send-email-maxime.ripard@free-electrons.com>

>>>>> "Maxime" == Maxime Ripard <maxime.ripard@free-electrons.com> writes:

 Maxime> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Committed, thanks.

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* [Buildroot] [PATCH] external-toolchain: add Sourcery CodeBench ARM 2012.09
From: Fabio Porcedda @ 2012-11-21 10:18 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <50AA8B82.6010609@mind.be>

On Mon, Nov 19, 2012 at 8:41 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 19/11/12 12:29, Fabio Porcedda wrote:
>>
>> I've added the "depends on BROKEN" because this toolchain
>> breaks linux kernel arm builds:
>> "arch/arm/lib/copy_template.S:247: Error: selected processor
>>   does not support ARM mode `ldralt r4,[r1],#4'"
>
>
>  Then why would we add support for that toolchain to buildroot?

You are right, that toolchain it's not useful to buildroot.
At least that email can be useful as an advice for who want to use
that toolchain with buildroot.

I've opened a new discussion about this bug on the Mentor's Forum:
http://communities.mentor.com/mgcx/message/36184

Regards
--
Fabio Porcedda
Software Developer - R&D Cagliari
Telit Communications S.p.A.

^ permalink raw reply

* [Buildroot] [PATCH v3] fs/common: Create initial console device
From: Markos Chandras @ 2012-11-21 10:19 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <509DBB40.1050100@mind.be>

On Sat, Nov 10, 2012 at 2:26 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 11/05/12 10:44, Markos Chandras wrote:
>>
>> From: Markos Chandras<markos.chandras@imgtec.com>
>>
>> A /dev/console node must be present in rootfs when the Linux kernel
>> boots otherwise the kernel will print the following warning:
>> "Warning: unable to open an initial console"
>>
>> This is because when we use an initramfs the /dev directory is not
>> populated at this point. This can cause problems when a program
>> (e.g ldso with early debugging enabled) opens a standard file
>> descriptor for read/write before these descriptors are actually
>> created by the init process later on.
>>
>> Signed-off-by: Markos Chandras<markos.chandras@imgtec.com>
>
>
> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>
>  Regards,
>  Arnout
>
Hi Arnout,

Thanks. Lets see if this will make it to the final release as this
warning is a bit annoying :)

-- 
Regards,
Markos

^ permalink raw reply

* [Buildroot] crosstools build fails when hard fpu is selected
From: Thierry Bultel @ 2012-11-21 10:23 UTC (permalink / raw)
  To: buildroot

Hello,

Using Buildroot-2012-08, I am building for arm-cortexa9-eabi,
crosstools+glibc, kernel base 2.6.38.8

I want to activate hardware floating point support, thus I have
unchecked the  "Use software floating point by default"

My final aim is to use Neon, but the defaut Hardware FPU is fine at this
time.

The build (from scratch) fails when at glibc:

[INFO ]  Installing C library headers & start files
[EXTRA]    Configuring C library
[CFG  ]    configure: loading cache
/bigdisk/shared/Buildroot/output.imx6hardfpu/build/build-toolchain/.build/arm-unknown-linux-gnueabi/build/build-libc-startfiles/config.cache
[CFG  ]    checking build system type... i686-build_pc-linux-gnu
[CFG  ]    checking host system type... arm-unknown-linux-gnueabi
[CFG  ]    checking for arm-unknown-linux-gnueabi-gcc...
arm-unknown-linux-gnueabi-gcc
[ERROR]    checking for suffix of object files... configure: error: in
`/bigdisk/shared/Buildroot/output.imx6hardfpu/build/build-toolchain/.build/arm-unknown-linux-gnueabi/build/build-libc-startfiles':
[ERROR]    configure: error: cannot compute suffix of object files:
cannot compile


The config.log shows:

configure:2477: arm-unknown-linux-gnueabi-gcc     -c  -U_FORTIFY_SOURCE
 -mlittle-endian -march=armv7-a   -mtune=cortex-a9 -mfpu=neon
-mhard-float  -O2   conftest.c >&5
conftest.c:1: sorry, unimplemented: -mfloat-abi=hard and VFP


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 ?

Thanks and cheers
Thierry

^ permalink raw reply

* [Buildroot] [git commit] fs/common: Create initial console device
From: Peter Korsgaard @ 2012-11-21 10:31 UTC (permalink / raw)
  To: buildroot

commit: http://git.buildroot.net/buildroot/commit/?id=e1ebae700ace80ded99e1a977e28375dc4f7255d
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

A /dev/console node must be present in rootfs when the Linux kernel
boots otherwise the kernel will print the following warning:
"Warning: unable to open an initial console"

This is because when we use an initramfs the /dev directory is not
populated at this point. This can cause problems when a program
(e.g ldso with early debugging enabled) opens a standard file
descriptor for read/write before these descriptors are actually
created by the init process later on.

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 fs/cpio/cpio.mk |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/fs/cpio/cpio.mk b/fs/cpio/cpio.mk
index aa20b41..5533322 100644
--- a/fs/cpio/cpio.mk
+++ b/fs/cpio/cpio.mk
@@ -21,6 +21,8 @@ define ROOTFS_CPIO_ADD_INIT
         fi
 endef
 
+PACKAGES_PERMISSIONS_TABLE += /dev/console c 622 0 0 5 1 - - -$(sep)
+
 endif # BR2_ROOTFS_DEVICE_CREATION_STATIC
 
 ROOTFS_CPIO_PRE_GEN_HOOKS += ROOTFS_CPIO_ADD_INIT

^ permalink raw reply related

* [Buildroot] [PATCH v3] fs/common: Create initial console device
From: Peter Korsgaard @ 2012-11-21 10:32 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <CAG2jQ8gOXf=uREZt1D0Vwy7RwzBvjGeyqXtbqL=fiiykbXG5Ow@mail.gmail.com>

>>>>> "Markos" == Markos Chandras <markos.chandras@gmail.com> writes:

 >> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
 >> Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
 >> 
 >> Regards,
 >> Arnout
 >> 
 Markos> Hi Arnout,

 Markos> Thanks. Lets see if this will make it to the final release as this
 Markos> warning is a bit annoying :)

Committed, thanks.

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* [Buildroot] [PATCH 1/2] kernel-headers: bump 3.{0, 2, 4, 6}.x stable versions
From: Gustavo Zacarias @ 2012-11-21 10:35 UTC (permalink / raw)
  To: buildroot

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 toolchain/kernel-headers/Config.in                 |    8 ++++----
 ...all-fix-__packed-in-exported-kernel-head.patch} |    0
 2 files changed, 4 insertions(+), 4 deletions(-)
 rename toolchain/kernel-headers/{linux-3.0.51-headers_install-fix-__packed-in-exported-kernel-head.patch => linux-3.0.52-headers_install-fix-__packed-in-exported-kernel-head.patch} (100%)

diff --git a/toolchain/kernel-headers/Config.in b/toolchain/kernel-headers/Config.in
index e195def..d24e7f9 100644
--- a/toolchain/kernel-headers/Config.in
+++ b/toolchain/kernel-headers/Config.in
@@ -67,12 +67,12 @@ config BR2_DEFAULT_KERNEL_HEADERS
 	default "2.6.37.6"	if BR2_KERNEL_HEADERS_2_6_37
 	default "2.6.38.8"	if BR2_KERNEL_HEADERS_2_6_38
 	default "2.6.39.4"	if BR2_KERNEL_HEADERS_2_6_39
-	default "3.0.51"	if BR2_KERNEL_HEADERS_3_0
+	default "3.0.52"	if BR2_KERNEL_HEADERS_3_0
 	default "3.1.10"	if BR2_KERNEL_HEADERS_3_1
-	default "3.2.33"	if BR2_KERNEL_HEADERS_3_2
+	default "3.2.34"	if BR2_KERNEL_HEADERS_3_2
 	default "3.3.8"		if BR2_KERNEL_HEADERS_3_3
-	default "3.4.18"	if BR2_KERNEL_HEADERS_3_4
+	default "3.4.19"	if BR2_KERNEL_HEADERS_3_4
 	default "3.5.7"		if BR2_KERNEL_HEADERS_3_5
-	default "3.6.6"		if BR2_KERNEL_HEADERS_3_6
+	default "3.6.7"		if BR2_KERNEL_HEADERS_3_6
 	default "2.6"		if BR2_KERNEL_HEADERS_SNAP
 	default $BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION
diff --git a/toolchain/kernel-headers/linux-3.0.51-headers_install-fix-__packed-in-exported-kernel-head.patch b/toolchain/kernel-headers/linux-3.0.52-headers_install-fix-__packed-in-exported-kernel-head.patch
similarity index 100%
rename from toolchain/kernel-headers/linux-3.0.51-headers_install-fix-__packed-in-exported-kernel-head.patch
rename to toolchain/kernel-headers/linux-3.0.52-headers_install-fix-__packed-in-exported-kernel-head.patch
-- 
1.7.8.6

^ permalink raw reply related

* [Buildroot] [PATCH 2/2] linux: bump 3.6.x stable version
From: Gustavo Zacarias @ 2012-11-21 10:35 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1353494120-19414-1-git-send-email-gustavo@zacarias.com.ar>

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 linux/Config.in |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/linux/Config.in b/linux/Config.in
index 29a2110..e24273c 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -21,7 +21,7 @@ choice
 	prompt "Kernel version"
 
 config BR2_LINUX_KERNEL_3_6
-	bool "3.6.6"
+	bool "3.6.7"
 
 config BR2_LINUX_KERNEL_SAME_AS_HEADERS
 	bool "Same as toolchain kernel headers"
@@ -76,7 +76,7 @@ config BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION
 
 config BR2_LINUX_KERNEL_VERSION
 	string
-	default "3.6.6" if BR2_LINUX_KERNEL_3_6
+	default "3.6.7" if BR2_LINUX_KERNEL_3_6
 	default BR2_DEFAULT_KERNEL_HEADERS if BR2_LINUX_KERNEL_SAME_AS_HEADERS
 	default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE if BR2_LINUX_KERNEL_CUSTOM_VERSION
 	default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL
-- 
1.7.8.6

^ permalink raw reply related

* [Buildroot] QtWebKit problem
From: Zoran Djordjevic @ 2012-11-21 10:42 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20121121105302.04d751ae@skate>

But before I start overall recompiling, which is (as you know) lengthy
process, is there maybe some dependencies, that I should check 
before (related to QtWebKit) ?
?
Regards? 

________________________________
 From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Zoran Djordjevic <djdjdjole@yahoo.com> 
Cc: "buildroot at busybox.net" <buildroot@busybox.net> 
Sent: Wednesday, November 21, 2012 10:53 AM
Subject: Re: [Buildroot] QtWebKit problem
  
Dear Zoran Djordjevic,

On Wed, 21 Nov 2012 01:41:40 -0800 (PST), Zoran Djordjevic wrote:
> I've built linux with Qt support, and later decided to add
> QtWebKit. I checked it, and rebuild (previously deleting
> stamp.build and stamp.install in ../output/build/qt-4.7.4)
> After building I didn't get QtWebKit in .../sysroot/usr/include.
> Where I go wrong ?

Don't do magic with stamp files, do:

??? make qt-reconfigure

Or preferably, a 'make clean all' cycle.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121121/ab049bb4/attachment.html>

^ permalink raw reply

* [Buildroot] [PATCH] libevent: Add Gentoo patch for C libraries without the sysctl syscall
From: Markos Chandras @ 2012-11-21 10:56 UTC (permalink / raw)
  To: buildroot

From: Markos Chandras <markos.chandras@imgtec.com>

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
---
 package/libevent/libevent-sysctl.patch |   46 ++++++++++++++++++++++++++++++++
 package/libevent/libevent.mk           |    1 +
 2 files changed, 47 insertions(+), 0 deletions(-)
 create mode 100644 package/libevent/libevent-sysctl.patch

diff --git a/package/libevent/libevent-sysctl.patch b/package/libevent/libevent-sysctl.patch
new file mode 100644
index 0000000..8c72377
--- /dev/null
+++ b/package/libevent/libevent-sysctl.patch
@@ -0,0 +1,46 @@
+Add Gentoo fix for C libraries that lack the sysctl system call
+http://sources2.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libevent/files/libevent-2.0.16-sysctl.patch?revision=1.1
+This patch has already been commited upstream
+
+Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
+
+From 358c745e5432f7648b6f8b3188f32b5551cbf9d6 Mon Sep 17 00:00:00 2001
+From: Mike Frysinger <vapier@gentoo.org>
+Date: Thu, 8 Dec 2011 11:39:48 -0500
+Subject: [PATCH] check for sysctl before we use it
+
+Not all C libraries under Linux support the sysctl() func.
+---
+ arc4random.c |    2 +-
+ configure.in |    2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arc4random.c b/arc4random.c
+index 4833169..ef10fa8 100644
+--- a/arc4random.c
++++ b/arc4random.c
+@@ -166,7 +166,7 @@ arc4_seed_win32(void)
+ }
+ #endif
+ 
+-#if defined(_EVENT_HAVE_SYS_SYSCTL_H)
++#if defined(_EVENT_HAVE_SYS_SYSCTL_H) && defined(_EVENT_HAVE_SYSCTL)
+ #if _EVENT_HAVE_DECL_CTL_KERN && _EVENT_HAVE_DECL_KERN_RANDOM && _EVENT_HAVE_DECL_RANDOM_UUID
+ #define TRY_SEED_SYSCTL_LINUX
+ static int
+diff --git a/configure.in b/configure.in
+index da08cf4..4e24444 100644
+--- a/configure.in
++++ b/configure.in
+@@ -267,7 +267,7 @@ AC_HEADER_TIME
+ 
+ dnl Checks for library functions.
+ AC_CHECK_FUNCS([gettimeofday vasprintf fcntl clock_gettime strtok_r strsep])
+-AC_CHECK_FUNCS([getnameinfo strlcpy inet_ntop inet_pton signal sigaction strtoll inet_aton pipe eventfd sendfile mmap splice arc4random arc4random_buf issetugid geteuid getegid getprotobynumber setenv unsetenv putenv])
++AC_CHECK_FUNCS([getnameinfo strlcpy inet_ntop inet_pton signal sigaction strtoll inet_aton pipe eventfd sendfile mmap splice arc4random arc4random_buf issetugid geteuid getegid getprotobynumber setenv unsetenv putenv sysctl])
+ 
+ AC_CACHE_CHECK(
+     [for getaddrinfo],
+-- 
+1.7.6.1
+
diff --git a/package/libevent/libevent.mk b/package/libevent/libevent.mk
index 5ce511f..3f2dfb0 100644
--- a/package/libevent/libevent.mk
+++ b/package/libevent/libevent.mk
@@ -6,6 +6,7 @@
 LIBEVENT_VERSION = 2.0.14
 LIBEVENT_SOURCE = libevent-$(LIBEVENT_VERSION)-stable.tar.gz
 LIBEVENT_SITE = https://github.com/downloads/libevent/libevent
+LIBEVENT_AUTORECONF = YES
 LIBEVENT_INSTALL_STAGING = YES
 
 define LIBEVENT_REMOVE_PYSCRIPT
-- 
1.7.1

^ permalink raw reply related

* [Buildroot] QtWebKit problem
From: Thomas Petazzoni @ 2012-11-21 12:24 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1353494563.12720.YahooMailNeo@web164605.mail.gq1.yahoo.com>

Dear Zoran Djordjevic,

On Wed, 21 Nov 2012 02:42:43 -0800 (PST), Zoran Djordjevic wrote:

> But before I start overall recompiling, which is (as you know) lengthy
> process, is there maybe some dependencies, that I should check 
> before (related to QtWebKit) ?

Well, unless there is a bug (which is of course always possible),
Buildroot normally knows all the dependencies that are needed for a
given package. It's one of the main reason for Buildroot to exist in
the first place...

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: Thomas Petazzoni @ 2012-11-21 12:25 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <50ACAB98.90607@wanadoo.fr>

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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply

* [Buildroot] Xtensa in the autobuilders, first build failures
From: Thomas Petazzoni @ 2012-11-21 12:30 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <50AC21D6.2080405@zankel.net>

Dear Chris Zankel,

On Tue, 20 Nov 2012 16:35:34 -0800, Chris Zankel wrote:

> > Ah, sorry, my bad. Don't hesitate to send a follow-up patch that
> > fixes the remaining problems.
> No worries, I think my email system wasn't working, so maybe you
> didn't even get them.

Yeah, after seeing your patch, I don't think I had seen those changes
before, but I may well have overlooked them.

> > Adding support for one architecture in libffi is not very simple,
> > so if you don't need it for your own projects, I don't think you'll
> > have the energy to work on this. 
> You are right, it looks like some work, and it would be lower
> priority. I'll just disable it for Xtensa for now.

Right, but as I replied, it's not that easy :)

> >>> Besides those issues, I'm just reminding you that we are still
> >>> very interested in having a Qemu Xtensa configuration to be able
> >>> to run the Xtensa systems we generate with Buildroot.
> >> I'm juggling between kernel, uClibc, and buildroot, so, please
> >> allow me some more time.
> > Sure, no problem!
> How do you actually build qemu inside buildroot, or is this not
> supported?

We have a host-qemu package, but it only builds the user-mode
emulation, and is not visible in menuconfig. For now, I think you can
just use the latest version of Qemu and compile it on your own. Unless
you have some time and want to extend the existing host-qemu package,
of course.

> I couldn't find any config option to enable it.
> Also note that the current kernel version (3.6) doesn't have all
> required patches, we are 'forward-focusing' at the moment, so things
> will be easier in the future.

That's a good strategy indeed. I don't mind if the Xtensa Qemu
defconfig currently points to a special Git tree for the kernel
sources, or if we have a few kernel patches in board/qemu/xtensa/, for
example.

Just let us what kernel version + patches, or kernel Git tree and we'll
figure out together how to make that fit into Buildroot.

> >> Regarding patches, should I send them to you and cc buildroot, or
> >> only to the mailing list? What's the best path to get them looked
> >> at and integrated into the tree?
> > Just send them to the list. You can Cc: me as well if you want, but
> > I'm basically reading everything that goes on the Buildroot list,
> > so I should catch them even if you don't Cc: me.
> Thanks. I'll keep them coming :-)

Seen them, the first two got applied, the last one about libffi is more
problematic.

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] [PATCH] libpcap: fix static build
From: Thomas Petazzoni @ 2012-11-21 13:11 UTC (permalink / raw)
  To: buildroot

The libpcap package contained some interesting attempts to support a
static-only build, but it was not working:

 http://autobuild.buildroot.org/results/01038d3b970092d894d2bae80679247e65722785/build-end.log

In fact the configure.in of libpcap has provision to support
--enable-shared/--disable-shared, but the generated configure script
in the libpcap package has not been regenerated with the configure.in
changes.

So basically, enabling LIBPCAP_AUTORECONF=YES ensures that the
configure script gets generated, which brings us a working
--enable-shared / --disable-shared.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/libpcap/libpcap.mk |    6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/package/libpcap/libpcap.mk b/package/libpcap/libpcap.mk
index 7a1d32f..468b064 100644
--- a/package/libpcap/libpcap.mk
+++ b/package/libpcap/libpcap.mk
@@ -9,12 +9,8 @@ LIBPCAP_SITE = http://www.tcpdump.org/release
 LIBPCAP_LICENSE = BSD-3c
 LIBPCAP_LICENSE_FILES = LICENSE
 LIBPCAP_INSTALL_STAGING = YES
+LIBPCAP_AUTORECONF = YES
 
-# doesn't have an install-strip
-LIBPCAP_INSTALL_TARGET_OPT= DESTDIR="$(TARGET_DIR)" \
-	$(if $(BR2_PREFER_STATIC_LIB),install,install-shared)
-LIBPCAP_INSTALL_STAGING_OPT= DESTDIR="$(STAGING_DIR)" install \
-	$(if $(BR2_PREFER_STATIC_LIB),,install-shared)
 LIBPCAP_DEPENDENCIES = zlib \
 	$(if $(BR2_PACKAGE_LIBUSB),libusb)
 LIBPCAP_CONF_ENV = ac_cv_linux_vers=2 \
-- 
1.7.9.5

^ permalink raw reply related

* [Buildroot] [PATCH] libpcap: fix static build
From: Baruch Siach @ 2012-11-21 14:12 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1353503491-4732-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hi Thomas,

On Wed, Nov 21, 2012 at 02:11:31PM +0100, Thomas Petazzoni wrote:
> The libpcap package contained some interesting attempts to support a
> static-only build, but it was not working:
> 
>  http://autobuild.buildroot.org/results/01038d3b970092d894d2bae80679247e65722785/build-end.log
> 
> In fact the configure.in of libpcap has provision to support
> --enable-shared/--disable-shared, but the generated configure script
> in the libpcap package has not been regenerated with the configure.in
> changes.
> 
> So basically, enabling LIBPCAP_AUTORECONF=YES ensures that the
> configure script gets generated, which brings us a working
> --enable-shared / --disable-shared.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  package/libpcap/libpcap.mk |    6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/package/libpcap/libpcap.mk b/package/libpcap/libpcap.mk
> index 7a1d32f..468b064 100644
> --- a/package/libpcap/libpcap.mk
> +++ b/package/libpcap/libpcap.mk
> @@ -9,12 +9,8 @@ LIBPCAP_SITE = http://www.tcpdump.org/release
>  LIBPCAP_LICENSE = BSD-3c
>  LIBPCAP_LICENSE_FILES = LICENSE
>  LIBPCAP_INSTALL_STAGING = YES
> +LIBPCAP_AUTORECONF = YES

Please add a comment here to explain the need for autoreconf.

baruch

> -# doesn't have an install-strip
> -LIBPCAP_INSTALL_TARGET_OPT= DESTDIR="$(TARGET_DIR)" \
> -	$(if $(BR2_PREFER_STATIC_LIB),install,install-shared)
> -LIBPCAP_INSTALL_STAGING_OPT= DESTDIR="$(STAGING_DIR)" install \
> -	$(if $(BR2_PREFER_STATIC_LIB),,install-shared)
>  LIBPCAP_DEPENDENCIES = zlib \
>  	$(if $(BR2_PACKAGE_LIBUSB),libusb)
>  LIBPCAP_CONF_ENV = ac_cv_linux_vers=2 \

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

^ permalink raw reply

* [Buildroot] crosstools in buildroot build fails when hard fpu is selected
From: Yann E. MORIN @ 2012-11-21 17:33 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <50ACEDD1.4010707@wanadoo.fr>

Thierry, All,

On Wednesday 21 November 2012 Thierry Bultel wrote:
> Using Buildroot-2012-08, I am building for arm-cortexa9-eabi,
> crosstools+glibc, kernel base 2.6.38.8

'crosstool-NG', not 'crosstools' ;-)

> I want to activate hardware floating point support, thus I have
> unchecked the  "Use software floating point by default"
> 
> My final aim is to use Neon, but the defaut Hardware FPU is fine at this
> time.
> 
> The build (from scratch) fails when at glibc:
[--SNIP--]
> The config.log shows:
> 
> configure:2477: arm-unknown-linux-gnueabi-gcc     -c  -U_FORTIFY_SOURCE
>  -mlittle-endian -march=armv7-a   -mtune=cortex-a9 -mfpu=neon
> -mhard-float  -O2   conftest.c >&5
> conftest.c:1: sorry, unimplemented: -mfloat-abi=hard and VFP
> 
> GCC has not been generated with the harware FPU support.

No, gcc has indeed be configured with hard-float. It's just that gcc does
*not* support emitting VFP instructions for the hard-float ABI. See:
  gcc-X.Y.Z/gcc/config/arm/arm.c
  1850        if (arm_float_abi == ARM_FLOAT_ABI_HARD && TARGET_VFP)
  1851          sorry ("-mfloat-abi=hard and VFP");

So, no matter what, it is not possible, with stock gcc, to use the VFP.

However, it is possible to use neon. There is a sample in crosstool-NG
that builds a NEON-enabled toolchain. You can look at how it is configured
and replicate that in your setup:
  ct-ng list-samples
  ct-ng arm-cortex_a15-linux-gnueabi    <- this sample enables neon
  ct-ng menuconfig

Then, to reproduce those options with buildroot:
    make ctng-menuconfig

Also, you could use 'softfp' instead of 'hard'. The name is (IMHO) a
msi-nomer, as this ABI does emit hardware floating point instructions,
but uses the software ABI (the way floats are represented). Look at
the help entries for 'soft', 'hard' and 'softfp' for more info.

Note: Unfortunately, the ct-ng integration in buildroot does not allow
building a 'softfp' toolchain; it's either 'soft' or 'hard', because BR
does not differentiate between 'hard' and 'softfp'.

> I have attempted several hacks into
> toolchain/toolchain-crosstool-ng/crosstool-ng.config-glibc
> ... with no better success

The problem is *not* in glibc, so you can't fix anything by hacking the
glibc build script.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply

* [Buildroot] Solving the mesa3d build issue
From: Arnout Vandecappelle @ 2012-11-21 18:34 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20121117150357.2aa86a1c@skate>

On 17/11/12 15:03, Thomas Petazzoni wrote:
> Hello,
>
> The mesa3d build is currently broken because it generates during its
> build process a bunch of C files from a XML description of the OpenGL
> APIs. This generation process is done through Python scripts that
> require the libxml2 Python bindings to be installed.
>
> Unfortunately, those libxml2 Python bindings are part of the libxml2
> source code itself, so we would have to enable host-python as a
> dependency of host-libxml2 in order to get those Python bindings built
> and installed. This means that all other users of host-libxml2 would
> pay the price of building host-python even if they don't need it, which
> is quite annoying.
>
> We have several solutions to address this problem:
>
>   (1) The solution proposed by Will Wagner/Noel Vellemans at
>       http://lists.busybox.net/pipermail/buildroot/2012-November/061594.html
>       and
>       http://lists.busybox.net/pipermail/buildroot/2012-November/061595.html.
>
>       This solution consists in adding a BR2_PACKAGE_HOST_LIBXML2_PYTHON
>       hidden configuration symbol, that mesa3d selects. It sells the
>       host-libxml2 package that it should build the Python binding, and
>       therefore depend on host-python.
>
>       It is quite nice in the sense that it is simple and only builds
>       host-python as a dependency of host-libxml2 when needed. However,
>       it adds something entirely non-standard: a hidden kconfig option
>       that tunes the compilation of a host package. Do we want to do
>       this?
>
[snip (2) and (3)]

  A fourth solution would be to create a new host-only package libxml2-python
that builds libxml2 with python bindings.  It would just reuse the libxml2
package with a slightly different CONF_OPT.

  The differences with the currently committed solution (1) are:

- No need for a HOST-config symbol.

- host-libxml2 will be built twice, once without and once with python bindings.

  There may even be a workaround for the second step, but at the moment I assume
it will be built twice.

  What do you think?

  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] [git commit] lcdproc: fix autobuilder failures
From: Simon Dawson @ 2012-11-21 20:26 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20121121103357.53bef338@skate>

Hi Markus, Thomas.

On 21 November 2012 09:33, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Markos Chandras,
>
> On Wed, 21 Nov 2012 09:23:11 +0000, Markos Chandras wrote:
>
>> I don't think is fixed. I am still getting this problem in master
>> branch and the autobuilder reports similar problems too.
>>
>> http://autobuild.buildroot.net/results/d7f51f07096a68ed5d513466ab3c1719a696cb19/build-end.log
>
> Indeed there is still a problem.
>
> Simon, do you have the time to look into this?

Unfortunately, I'm probably not going to get a chance to look at this
for a week or so. It's building correctly for me --- indeed, I don't
even see the problematic host include/library paths in the compiler
commands --- but clearly there is something wrong. I'll investigate as
soon as I can.

Simon.

^ permalink raw reply

* [Buildroot] Qt accessibility support
From: Zoran Djordjevic @ 2012-11-21 20:32 UTC (permalink / raw)
  To: buildroot

Is it possible to choose somwhere in Buildroot menues, 
exclusion/inclusion of accessibility support for Qt ? 
As much as I understand it is matter that should be defined
at?Qt build time (am I right ?). 
Question doesn't relate only to accessibility, but for other
(if any) options too.
?
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121121/66f4b1af/attachment-0001.html>

^ permalink raw reply

* [Buildroot] Qt accessibility support
From: Thomas Petazzoni @ 2012-11-21 21:11 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1353529923.81343.YahooMailNeo@web164605.mail.gq1.yahoo.com>

Dear Zoran Djordjevic,

On Wed, 21 Nov 2012 12:32:03 -0800 (PST), Zoran Djordjevic wrote:

> Is it possible to choose somwhere in Buildroot menues, 
> exclusion/inclusion of accessibility support for Qt ? 
> As much as I understand it is matter that should be defined
> at?Qt build time (am I right ?). 
> Question doesn't relate only to accessibility, but for other
> (if any) options too.

Look at package/qt/Config.* and package/qt/qt.mk to see how we handle
options for Qt. Should be easy to extend to other options if needed.

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] Qt accessibility support
From: Zoran Djordjevic @ 2012-11-21 21:47 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20121121221105.2fbcfde7@skate>

I didn't noticed it, or better - I didn't know for it. Attached is my 
(probably default) qt.mk file. So does it mean that because of 
"-no-accessibility" line, I had Qt compiled without accessibility 
support ? If so, I suppose, I only have to exclude that line, to 
win accessibility support. OK ?
No matter, I must confess,?you offered?an?elegant solution. 
?
Regards


________________________________
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Zoran Djordjevic <djdjdjole@yahoo.com> 
Cc: "buildroot at busybox.net" <buildroot@busybox.net> 
Sent: Wednesday, November 21, 2012 10:11 PM
Subject: Re: [Buildroot] Qt accessibility support

Dear Zoran Djordjevic,

On Wed, 21 Nov 2012 12:32:03 -0800 (PST), Zoran Djordjevic wrote:

> Is it possible to choose somwhere in Buildroot menues, 
> exclusion/inclusion of accessibility support for Qt ? 
> As much as I understand it is matter that should be defined
> at?Qt build time (am I right ?). 
> Question doesn't relate only to accessibility, but for other
> (if any) options too.

Look at package/qt/Config.* and package/qt/qt.mk to see how we handle
options for Qt. Should be easy to extend to other options if needed.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121121/1e811207/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qt.mk
Type: application/octet-stream
Size: 17290 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121121/1e811207/attachment-0001.obj>

^ permalink raw reply

* [Buildroot] [git commit] kernel-headers: bump 3.{0, 2, 4, 6}.x stable versions
From: Peter Korsgaard @ 2012-11-21 23:08 UTC (permalink / raw)
  To: buildroot

commit: http://git.buildroot.net/buildroot/commit/?id=1c7f8c45f2f6f0b2a1214ad59f6540df0e6eb4be
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 toolchain/kernel-headers/Config.in                 |    8 ++++----
 ...all-fix-__packed-in-exported-kernel-head.patch} |    0
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/toolchain/kernel-headers/Config.in b/toolchain/kernel-headers/Config.in
index e195def..d24e7f9 100644
--- a/toolchain/kernel-headers/Config.in
+++ b/toolchain/kernel-headers/Config.in
@@ -67,12 +67,12 @@ config BR2_DEFAULT_KERNEL_HEADERS
 	default "2.6.37.6"	if BR2_KERNEL_HEADERS_2_6_37
 	default "2.6.38.8"	if BR2_KERNEL_HEADERS_2_6_38
 	default "2.6.39.4"	if BR2_KERNEL_HEADERS_2_6_39
-	default "3.0.51"	if BR2_KERNEL_HEADERS_3_0
+	default "3.0.52"	if BR2_KERNEL_HEADERS_3_0
 	default "3.1.10"	if BR2_KERNEL_HEADERS_3_1
-	default "3.2.33"	if BR2_KERNEL_HEADERS_3_2
+	default "3.2.34"	if BR2_KERNEL_HEADERS_3_2
 	default "3.3.8"		if BR2_KERNEL_HEADERS_3_3
-	default "3.4.18"	if BR2_KERNEL_HEADERS_3_4
+	default "3.4.19"	if BR2_KERNEL_HEADERS_3_4
 	default "3.5.7"		if BR2_KERNEL_HEADERS_3_5
-	default "3.6.6"		if BR2_KERNEL_HEADERS_3_6
+	default "3.6.7"		if BR2_KERNEL_HEADERS_3_6
 	default "2.6"		if BR2_KERNEL_HEADERS_SNAP
 	default $BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION
diff --git a/toolchain/kernel-headers/linux-3.0.51-headers_install-fix-__packed-in-exported-kernel-head.patch b/toolchain/kernel-headers/linux-3.0.52-headers_install-fix-__packed-in-exported-kernel-head.patch
similarity index 100%
rename from toolchain/kernel-headers/linux-3.0.51-headers_install-fix-__packed-in-exported-kernel-head.patch
rename to toolchain/kernel-headers/linux-3.0.52-headers_install-fix-__packed-in-exported-kernel-head.patch

^ permalink raw reply related

* [Buildroot] [git commit] linux: bump 3.6.x stable version
From: Peter Korsgaard @ 2012-11-21 23:08 UTC (permalink / raw)
  To: buildroot

commit: http://git.buildroot.net/buildroot/commit/?id=36d36f0de19bd5f23453dc1391f83843f9042849
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 linux/Config.in |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/linux/Config.in b/linux/Config.in
index 29a2110..e24273c 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -21,7 +21,7 @@ choice
 	prompt "Kernel version"
 
 config BR2_LINUX_KERNEL_3_6
-	bool "3.6.6"
+	bool "3.6.7"
 
 config BR2_LINUX_KERNEL_SAME_AS_HEADERS
 	bool "Same as toolchain kernel headers"
@@ -76,7 +76,7 @@ config BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION
 
 config BR2_LINUX_KERNEL_VERSION
 	string
-	default "3.6.6" if BR2_LINUX_KERNEL_3_6
+	default "3.6.7" if BR2_LINUX_KERNEL_3_6
 	default BR2_DEFAULT_KERNEL_HEADERS if BR2_LINUX_KERNEL_SAME_AS_HEADERS
 	default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE if BR2_LINUX_KERNEL_CUSTOM_VERSION
 	default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox