* [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] 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] [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] [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] 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] 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] 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] [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: 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 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] [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>
---
| 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%)
--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 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] [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] 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] [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] [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] 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] [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 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] xtensa: fix target gdb build and 64-bit host side gdb
From: Peter Korsgaard @ 2012-11-21 10:14 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=c28e15debff2078f4ef1b123e9a047a0cad2c18a
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Fix build breakage, use the version of the ptrace header file in asm
instead of sys. Also, fix GDB running on 64 bit hosts. GDB was using
unsigned long for 32-bit registers, but unsigned long is 64 bit on
64-bit hosts.
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
toolchain/gdb/7.4.1/xtensa-asm-ptrace-h.patch | 22 ++++++++++++++++++++++
toolchain/gdb/7.4.1/xtensa-gdb-regsize.patch | 19 +++++++++++++++++++
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/toolchain/gdb/7.4.1/xtensa-asm-ptrace-h.patch b/toolchain/gdb/7.4.1/xtensa-asm-ptrace-h.patch
new file mode 100644
index 0000000..3d1b07c
--- /dev/null
+++ b/toolchain/gdb/7.4.1/xtensa-asm-ptrace-h.patch
@@ -0,0 +1,22 @@
+--- gdb-7.4.1/gdb/xtensa-linux-nat.c.orig 2012-10-19 16:23:06.908165323 -0700
++++ gdb-7.4.1/gdb/xtensa-linux-nat.c 2012-10-19 16:35:30.792134876 -0700
+@@ -36,7 +36,7 @@
+ #include "gdb_wait.h"
+ #include <fcntl.h>
+ #include <sys/procfs.h>
+-#include <sys/ptrace.h>
++#include <asm/ptrace.h>
+
+ #include "gregset.h"
+ #include "xtensa-tdep.h"
+--- gdb-7.4.1/gdb/gdbserver/linux-xtensa-low.c.orig 2012-10-19 16:24:06.260162894 -0700
++++ gdb-7.4.1/gdb/gdbserver/linux-xtensa-low.c 2012-10-19 16:36:07.920133357 -0700
+@@ -23,7 +23,7 @@
+ /* Defined in auto-generated file reg-xtensa.c. */
+ void init_registers_xtensa (void);
+
+-#include <sys/ptrace.h>
++#include <asm/ptrace.h>
+ #include <xtensa-config.h>
+
+ #include "xtensa-xtregs.c"
diff --git a/toolchain/gdb/7.4.1/xtensa-gdb-regsize.patch b/toolchain/gdb/7.4.1/xtensa-gdb-regsize.patch
new file mode 100644
index 0000000..e10bb8f
--- /dev/null
+++ b/toolchain/gdb/7.4.1/xtensa-gdb-regsize.patch
@@ -0,0 +1,19 @@
+--- gdb-7.4.1/gdb/xtensa-tdep.h.orig 2012-10-30 11:40:23.546448594 -0700
++++ gdb-7.4.1/gdb/xtensa-tdep.h 2012-10-30 11:41:43.078445337 -0700
+@@ -17,6 +17,7 @@
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
++#include <stdint.h>
+
+ /* XTENSA_TDEP_VERSION can/should be changed along with XTENSA_CONFIG_VERSION
+ whenever the "tdep" structure changes in an incompatible way. */
+@@ -84,7 +85,7 @@
+ /* Xtensa ELF core file register set representation ('.reg' section).
+ Copied from target-side ELF header <xtensa/elf.h>. */
+
+-typedef unsigned long xtensa_elf_greg_t;
++typedef uint32_t xtensa_elf_greg_t;
+
+ typedef struct
+ {
^ permalink raw reply related
* [Buildroot] [PATCH 1/3] xtensa: use uppercase for configurations and modofied overlay structure
From: Peter Korsgaard @ 2012-11-21 10:11 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50ac8f31.4b53440a.7e28.05ed@mx.google.com>
>>>>> "Chris" == Chris Zankel <chris@zankel.net> writes:
Chris> Except for architecture and processor names, buildroot uses capitalized
Chris> configuration names, so change the macro names for xtensa to follow that
Chris> standard.
Chris> Change the overlay file to have a subdirectory for each component
Chris> (gdb, binutils, gcc, etc.) to make it more future-prove.
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit] xtensa: use uppercase for configurations and modified overlay structure
From: Peter Korsgaard @ 2012-11-21 10:08 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=fdd5bc948ed5fa3d14f9bfa09968f8216fb08ae1
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Except for architecture and processor names, buildroot uses capitalized
configuration names, so change the macro names for xtensa to follow that
standard.
Change the overlay file to have a subdirectory for each component
(gdb, binutils, gcc, etc.) to make it more future-prove.
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
arch/Config.in.xtensa | 26 +++++++++++++++-----------
package/binutils/binutils.mk | 6 +++---
toolchain/gcc/gcc-uclibc-4.x.mk | 6 +++---
toolchain/gdb/gdb.mk | 6 +++---
4 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/arch/Config.in.xtensa b/arch/Config.in.xtensa
index af66125..60c03f5 100644
--- a/arch/Config.in.xtensa
+++ b/arch/Config.in.xtensa
@@ -2,32 +2,36 @@ choice
prompt "Target Architecture Variant"
depends on BR2_xtensa
default BR2_xtensa_fsf
-config BR2_xtensa_custom
+config BR2_XTENSA_CUSTOM
bool "Custom Xtensa processor configuration"
config BR2_xtensa_fsf
bool "fsf - Default configuration"
endchoice
-config BR2_xtensa_custom_name
- string "Custom Xtensa processor configuration anme"
- depends on BR2_xtensa_custom
+config BR2_XTENSA_CUSTOM_NAME
+ string "Custom Xtensa processor configuration name"
+ depends on BR2_XTENSA_CUSTOM
default ""
help
Name given to a custom Xtensa processor configuration.
-config BR2_xtensa_core_name
+config BR2_XTENSA_CORE_NAME
string
- default BR2_xtensa_custom_name if BR2_xtensa_custom
+ default BR2_XTENSA_CUSTOM_NAME if BR2_XTENSA_CUSTOM
default "" if BR2_xtensa_fsf
-config BR2_xtensa_overlay_dir
+config BR2_XTENSA_OVERLAY_DIR
string "Overlay directory for custom configuration"
- depends on BR2_xtensa_custom
+ depends on BR2_XTENSA_CUSTOM
default ""
help
- Provide a directory path that contains the overlay files
- for the custom configuration. The path is based on the
- buildroot top directory.
+ Provide the directory path that contains the overlay file
+ for a custom processor configuration. The path is relative
+ to the top directory of buildroot.
+ These overlay files are tar packages with updated configuration
+ files for various toolchain packages and Xtensa processor
+ configurations. They are provided by the processor vendor or
+ directly from Tensilica.
config BR2_ARCH
default "xtensa" if BR2_xtensa
diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk
index 82f8fd2..92e0a74 100644
--- a/package/binutils/binutils.mk
+++ b/package/binutils/binutils.mk
@@ -68,11 +68,11 @@ define BINUTILS_INSTALL_TARGET_CMDS
endef
endif
-XTENSA_CORE_NAME = $(call qstrip, $(BR2_xtensa_core_name))
+XTENSA_CORE_NAME = $(call qstrip, $(BR2_XTENSA_CORE_NAME))
ifneq ($(XTENSA_CORE_NAME),)
define BINUTILS_XTENSA_PRE_PATCH
- tar xf $(BR2_xtensa_overlay_dir)/xtensa_$(XTENSA_CORE_NAME).tar \
- -C $(@D) bfd include ld
+ tar xf $(BR2_XTENSA_OVERLAY_DIR)/xtensa_$(XTENSA_CORE_NAME).tar \
+ -C $(@D) --strip-components=1 binutils
endef
HOST_BINUTILS_PRE_PATCH_HOOKS += BINUTILS_XTENSA_PRE_PATCH
endif
diff --git a/toolchain/gcc/gcc-uclibc-4.x.mk b/toolchain/gcc/gcc-uclibc-4.x.mk
index 1710070..7a0b4ca 100644
--- a/toolchain/gcc/gcc-uclibc-4.x.mk
+++ b/toolchain/gcc/gcc-uclibc-4.x.mk
@@ -251,9 +251,9 @@ $(GCC_DIR)/.unpacked: $(DL_DIR)/$(GCC_SOURCE)
rm -rf $(GCC_DIR)
$(GCC_CAT) $(DL_DIR)/$(GCC_SOURCE) | tar -C $(TOOLCHAIN_DIR) $(TAR_OPTIONS) -
$(call CONFIG_UPDATE,$(@D))
-ifneq ($(call qstrip, $(BR2_xtensa_core_name)),)
- tar xf $(BR2_xtensa_overlay_dir)/xtensa_$(call qstrip,\
- $(BR2_xtensa_core_name)).tar -C $(@D) include
+ifneq ($(call qstrip, $(BR2_XTENSA_CORE_NAME)),)
+ tar xf $(BR2_XTENSA_OVERLAY_DIR)/xtensa_$(call qstrip,\
+ $(BR2_XTENSA_CORE_NAME)).tar -C $(@D) --strip-components=1 gcc
endif
touch $@
diff --git a/toolchain/gdb/gdb.mk b/toolchain/gdb/gdb.mk
index dc305a6..c42c755 100644
--- a/toolchain/gdb/gdb.mk
+++ b/toolchain/gdb/gdb.mk
@@ -25,9 +25,9 @@ gdb-unpacked: $(GDB_DIR)/.unpacked
$(GDB_DIR)/.unpacked: $(DL_DIR)/$(GDB_SOURCE)
mkdir -p $(GDB_DIR)
$(GDB_CAT) $(DL_DIR)/$(GDB_SOURCE) | tar -C $(GDB_DIR) $(TAR_STRIP_COMPONENTS)=1 $(TAR_OPTIONS) -
-ifneq ($(call qstrip, $(BR2_xtensa_core_name)),)
- tar xf $(BR2_xtensa_overlay_dir)/xtensa_$(call qstrip, \
- $(BR2_xtensa_core_name)).tar -C $(@D) bfd include gdb
+ifneq ($(call qstrip, $(BR2_XTENSA_CORE_NAME)),)
+ tar xf $(BR2_XTENSA_OVERLAY_DIR)/xtensa_$(call qstrip, \
+ $(BR2_XTENSA_CORE_NAME)).tar -C $(@D) --strip-components=1 gdb
endif
ifneq ($(wildcard $(GDB_PATCH_DIR)),)
support/scripts/apply-patches.sh $(GDB_DIR) $(GDB_PATCH_DIR) \*.patch
^ permalink raw reply related
* [Buildroot] [PATCH] Remove unused barebox 2012.07 string
From: Maxime Ripard @ 2012-11-21 10:08 UTC (permalink / raw)
To: buildroot
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
boot/barebox/Config.in | 1 -
1 file changed, 1 deletion(-)
diff --git a/boot/barebox/Config.in b/boot/barebox/Config.in
index c9e7088..0273dd0 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
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] [PATCH] busybox: fix link with tirpc
From: Peter Korsgaard @ 2012-11-21 10:07 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353485736-10836-1-git-send-email-arnout@mind.be>
>>>>> "Arnout" == Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> writes:
Arnout> Busybox does partial linking of its modules before linking everything
Arnout> together into the binary. Those partial links are done without the
Arnout> standard libraries, but that also means -ltirpc can't be found. In
Arnout> addition, this probably fails horribly with static linking (untested).
Arnout> The problem is that the LDFLAGS are also used in the partial links.
Arnout> So instead, use CFLAGS_busybox, which is only used for the busybox
Arnout> link step. Also make sure that this is passed through the environment,
Arnout> not on the command line, so the busybox Makefile can still append to
Arnout> it.
Arnout> Fixes e.g.
Arnout> http://autobuild.buildroot.net/results/e8351e3ba86fdcdb2999548658271a6fde0526a9
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit] busybox: fix link with tirpc
From: Peter Korsgaard @ 2012-11-21 10:07 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=5e0f1e1fcfbaca2b33397b3076a55b23b0e02cd8
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Busybox does partial linking of its modules before linking everything
together into the binary. Those partial links are done without the
standard libraries, but that also means -ltirpc can't be found. In
addition, this probably fails horribly with static linking (untested).
The problem is that the LDFLAGS are also used in the partial links.
So instead, use CFLAGS_busybox, which is only used for the busybox
link step. Also make sure that this is passed through the environment,
not on the command line, so the busybox Makefile can still append to
it.
Fixes e.g.
http://autobuild.buildroot.net/results/e8351e3ba86fdcdb2999548658271a6fde0526a9
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/busybox/busybox.mk | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/package/busybox/busybox.mk b/package/busybox/busybox.mk
index 549e150..9154c08 100644
--- a/package/busybox/busybox.mk
+++ b/package/busybox/busybox.mk
@@ -27,12 +27,17 @@ BUSYBOX_LDFLAGS = \
ifeq ($(BR2_PACKAGE_LIBTIRPC),y)
BUSYBOX_DEPENDENCIES += libtirpc
BUSYBOX_CFLAGS += -I$(STAGING_DIR)/usr/include/tirpc/
-BUSYBOX_LDFLAGS += -ltirpc
+# Don't use LDFLAGS for -ltirpc, because LDFLAGS is used for
+# the non-final link of modules as well.
+BUSYBOX_CFLAGS_busybox += -ltirpc
endif
BUSYBOX_BUILD_CONFIG = $(BUSYBOX_DIR)/.config
# Allows the build system to tweak CFLAGS
-BUSYBOX_MAKE_ENV = $(TARGET_MAKE_ENV) CFLAGS="$(BUSYBOX_CFLAGS)"
+BUSYBOX_MAKE_ENV = \
+ $(TARGET_MAKE_ENV) \
+ CFLAGS="$(BUSYBOX_CFLAGS)" \
+ CFLAGS_busybox="$(BUSYBOX_CFLAGS_busybox)"
BUSYBOX_MAKE_OPTS = \
CC="$(TARGET_CC)" \
ARCH=$(KERNEL_ARCH) \
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox