* [Buildroot] [PATCH] package/ntp: fix aarch64/mips build, -fPIC required
From: Thomas Petazzoni @ 2017-05-17 19:48 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20170513214917.3305-1-romain.naour@gmail.com>
Hello,
On Sat, 13 May 2017 23:49:17 +0200, Romain Naour wrote:
> +# ntp build unconditionnaly some static libraries (libntpq.a, libntp.a etc...)
> +# The build system fail to create ntpsnmpd while linking these libraries when
> +# built without -fPIC.
> +NTP_CONF_ENV += \
> + CFLAGS="-fPIC $(TARGET_CFLAGS)"
Thanks for this analysis. However, I was a bit surprised by your patch,
because I saw many -fPIC all over the place in the ntp build log, even
without your patch.
So I dug a little bit deeper, and found this Gentoo patch
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=494143c3b4921a5c8b8596d58f2c8b98296bf688,
which simply re-adds the proper flags to just the ntpq module. And this
does indeed solve the issue.
So I've instead committed a patch that adds the Gentoo patch. Thanks
anyway for your initial analysis, it was very useful to understand what
was going on.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [git commit] ntp: add patch to fix -fPIC issue
From: Thomas Petazzoni @ 2017-05-17 19:46 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=7fde83cdf0da338937dae13144eea2923e5c2730
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
This commit adds a patch that fixes the build on AArch64 and MIPS of the
ntp package, which was caused by some parts of ntp being built without
-fPIC.
Fixes:
[aarch64] http://autobuild.buildroot.net/results/866b1d28595efd8b6becf83d0a64b596538d58b0
[mips] http://autobuild.buildroot.net/results/c2a945855172970736a8ffea9c564f029a023344
Thanks to Romain Naour for the initial analysis.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/ntp/0003-ntpq-fpic.patch | 23 +++++++++++++++++++++++
package/ntp/ntp.mk | 1 +
2 files changed, 24 insertions(+)
diff --git a/package/ntp/0003-ntpq-fpic.patch b/package/ntp/0003-ntpq-fpic.patch
new file mode 100644
index 0000000..6e05a67
--- /dev/null
+++ b/package/ntp/0003-ntpq-fpic.patch
@@ -0,0 +1,23 @@
+ntpq/Makefile.am: add NTP_HARD_CFLAGS
+
+Pass NTP_HARD_CFLAGS when building ntpq, like in all other ntp
+modules, to make sure -fPIC is passed.
+
+Originally taken from
+https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=494143c3b4921a5c8b8596d58f2c8b98296bf688.
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+Index: b/ntpq/Makefile.am
+===================================================================
+--- a/ntpq/Makefile.am
++++ b/ntpq/Makefile.am
+@@ -23,7 +23,7 @@
+ ntpq_LDADD += $(LDADD_NTP)
+ noinst_HEADERS= ntpq.h
+ noinst_LIBRARIES= libntpq.a
+-libntpq_a_CFLAGS= -DNO_MAIN_ALLOWED -DBUILD_AS_LIB
++libntpq_a_CFLAGS= $(NTP_HARD_CFLAGS) -DNO_MAIN_ALLOWED -DBUILD_AS_LIB
+ CLEANFILES=
+ DISTCLEANFILES= .version version.c config.log $(man_MANS)
+ ETAGS_ARGS= Makefile.am
diff --git a/package/ntp/ntp.mk b/package/ntp/ntp.mk
index cd6cb16..26f5862 100644
--- a/package/ntp/ntp.mk
+++ b/package/ntp/ntp.mk
@@ -21,6 +21,7 @@ NTP_CONF_OPTS = \
--with-crypto
# 0002-ntp-syscalls-fallback.patch
+# 0003-ntpq-fpic.patch
NTP_AUTORECONF = YES
ifeq ($(BR2_TOOLCHAIN_HAS_SSP),y)
^ permalink raw reply related
* [Buildroot] RPi B+ update
From: Peter Korsgaard @ 2017-05-17 19:29 UTC (permalink / raw)
To: buildroot
In-Reply-To: <24ea86ee-9b48-816f-3e7a-6d5a985ea339@gmail.com>
>>>>> "Marco" == Marco Trapanese <marcotrapanese@gmail.com> writes:
Hi,
> Well, some good news.
> Using the latest versions of buildroot (2017.05-rc1-00062-g4b4fc27)
> and kernel (4.9.21) I built an "empty" environment (without any
> additional package but the rpi-firmware). Copying both zImage and the
> fw files into the boot partition of the existing sd-card, leads to
> boot-up again!
Great!
> The problem now is related to the kernel drivers (wifi, rtc, cdc,
> etc...) that I manually selected using make linux-menuconfig and that
> were available (in the old rootfs) under /lib/modules/3.12.26. I'm
> afraid the new kernel doesn't know where to find them - and perhaps it
> cannot use them anyway because they are related to a different
> version.
Yes, reusing the old kernel drivers with a new kernel is not going to
work.
> It seems I need to update the whole system...
Unless the system boots with new fw and the old zImage. Did you try that
combination?
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [PATCH 1/1] libqmi: move canonicalize_file_name()
From: Thomas Petazzoni @ 2017-05-17 19:25 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1494815160-53868-1-git-send-email-matthew.weber@rockwellcollins.com>
Hello,
On Sun, 14 May 2017 21:26:00 -0500, Matt Weber wrote:
> Previously was defined in qmi-util.h to fix musl
> compatibility. It was missed that this is a shared
> header which causes other dependent package builds
> to fail, so the static definition was moved into the
> implementation where it was used.
>
> Upstream bug report has been updated and this resolves
> the following autobuilder related failures.
>
> http://autobuild.buildroot.net/results/fe9b6b1b1399a4e8aafc6a326c81ec97c2480025
> http://autobuild.buildroot.net/results/40eef797b4d8d53fc6e10f2048316d63549caf6d
>
> test-pkg testing was performed against 10 random toolchains
>
> ++ Config snippet ++
> BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
> BR2_PACKAGE_MODEM_MANAGER_LIBQMI=y
> BR2_PACKAGE_MODEM_MANAGER=y
> BR2_PACKAGE_LIBQMI=y
>
> ++ Tested Toolchains ++ (Verified I hit all libc varients)
> br-arm-cortex-a9-musl
> br-arm-full-static
> br-m68k-68040-full (uclibc)
> br-mips32r6-el-hf-glibc
> br-mips64-n64-full
> br-mips64r6-el-hf-glibc
> br-mipsel-o32-full
> br-sparc64-glibc
> linaro-arm
> sourcery-arm
>
> Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
> ---
> .../0001-musl-compat-canonicalize_file_name.patch | 37 +++++++++++-----------
> 1 file changed, 18 insertions(+), 19 deletions(-)
Applied to master, thanks.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [git commit] libqmi: move canonicalize_file_name()
From: Thomas Petazzoni @ 2017-05-17 19:24 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=2677210f545c3f3e8c52c973e08c3a460c521e5b
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Previously was defined in qmi-util.h to fix musl
compatibility. It was missed that this is a shared
header which causes other dependent package builds
to fail, so the static definition was moved into the
implementation where it was used.
Upstream bug report has been updated and this resolves
the following autobuilder related failures.
http://autobuild.buildroot.net/results/fe9b6b1b1399a4e8aafc6a326c81ec97c2480025
http://autobuild.buildroot.net/results/40eef797b4d8d53fc6e10f2048316d63549caf6d
test-pkg testing was performed against 10 random toolchains
++ Config snippet ++
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_PACKAGE_MODEM_MANAGER_LIBQMI=y
BR2_PACKAGE_MODEM_MANAGER=y
BR2_PACKAGE_LIBQMI=y
++ Tested Toolchains ++ (Verified I hit all libc variants)
br-arm-cortex-a9-musl
br-arm-full-static
br-m68k-68040-full (uclibc)
br-mips32r6-el-hf-glibc
br-mips64-n64-full
br-mips64r6-el-hf-glibc
br-mipsel-o32-full
br-sparc64-glibc
linaro-arm
sourcery-arm
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
.../0001-musl-compat-canonicalize_file_name.patch | 37 +++++++++++-----------
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/package/libqmi/0001-musl-compat-canonicalize_file_name.patch b/package/libqmi/0001-musl-compat-canonicalize_file_name.patch
index fd606d8..3ae1c2e 100644
--- a/package/libqmi/0001-musl-compat-canonicalize_file_name.patch
+++ b/package/libqmi/0001-musl-compat-canonicalize_file_name.patch
@@ -1,22 +1,24 @@
-From 85863c9e051fe59add4e47dbfcb37072234f0110 Mon Sep 17 00:00:00 2001
+From 8f6181b6f8dd82aa1ab1288cc7f2fd05d4a2519f Mon Sep 17 00:00:00 2001
From: Matt Weber <matthew.weber@rockwellcollins.com>
Date: Mon, 1 May 2017 19:55:07 -0500
Subject: [PATCH] musl compat canonicalize_file_name()
-Adds an inline equivalent of canonicalize_file_name
+Adds an equivalent of canonicalize_file_name
using realpath().
Bug report (origin of this patch):
https://bugs.freedesktop.org/show_bug.cgi?id=99944
+Bug report has been updated with suggestion to not use inline.
+
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
configure.ac | 2 ++
- src/libqmi-glib/qmi-utils.h | 18 ++++++++++++++++++
- 2 files changed, 20 insertions(+)
+ src/libqmi-glib/qmi-utils.c | 15 +++++++++++++++
+ 2 files changed, 17 insertions(+)
diff --git a/configure.ac b/configure.ac
-index 162d5ae..9cb82fd 100644
+index c56fa3e..d835db4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -80,6 +80,8 @@ AC_SUBST(GLIB_LIBS)
@@ -28,19 +30,16 @@ index 162d5ae..9cb82fd 100644
dnl qmi-firmware-update is optional, enabled by default
AC_ARG_ENABLE([firmware-update],
AS_HELP_STRING([--enable-firmware-update],
-diff --git a/src/libqmi-glib/qmi-utils.h b/src/libqmi-glib/qmi-utils.h
-index 4fd5199..4869da5 100644
---- a/src/libqmi-glib/qmi-utils.h
-+++ b/src/libqmi-glib/qmi-utils.h
-@@ -29,6 +29,24 @@
- #error "Only <libqmi-glib.h> can be included directly."
- #endif
+diff --git a/src/libqmi-glib/qmi-utils.c b/src/libqmi-glib/qmi-utils.c
+index 29e5f22..26aff9e 100644
+--- a/src/libqmi-glib/qmi-utils.c
++++ b/src/libqmi-glib/qmi-utils.c
+@@ -34,6 +34,21 @@
+ #include "qmi-utils.h"
+ #include "qmi-error-types.h"
+#ifndef HAVE_CANONICALIZE_FILE_NAME
+#include <limits.h>
-+#include <string.h>
-+#include <stdlib.h>
-+#include <stdio.h>
+static char * canonicalize_file_name(const char *path)
+{
+ char buf[PATH_MAX] = { };
@@ -54,9 +53,9 @@ index 4fd5199..4869da5 100644
+}
+#endif
+
- #include <glib.h>
-
- G_BEGIN_DECLS
+ /**
+ * SECTION:qmi-utils
+ * @title: Common utilities
--
-2.7.4
+1.9.1
^ permalink raw reply related
* [Buildroot] Analysis of build results for 2017-05-16
From: Thomas Petazzoni @ 2017-05-17 19:20 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20170517062751.2CBF020789@mail.free-electrons.com>
Hello,
On Wed, 17 May 2017 08:27:51 +0200 (CEST), Thomas Petazzoni wrote:
> successes : 251
> failures : 10
This is getting better, and better, and better. We're down to 3.83% of
failures for yesterday. Today will be a little bit worse, with
currently 4.19% failures. But we're really below 5% of failures, which
is very good.
> x86_64 | cmake-3.7.2 | NOK | http://autobuild.buildroot.net/results/e89a29fb06991d8da9b946e284741c56397ac4bc |
/home/test/autobuild/run/instance-2/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/bdver3/usr/lib64/libgcrypt.so.20: undefined reference to `gpg_err_set_errno at GPG_ERROR_1.0'
Weird, because this looks like a static linking issue, but this is not
a statically linked configuration.
It appeared three times, but only with this toolchain (Sourcery CodeBench):
http://autobuild.buildroot.net/?reason=cmake-3.7.2
> x86_64 | cppcms-1.0.5 | NOK | http://autobuild.buildroot.net/results/a7eb1ede552ae14f409cfd7bd877bcf25ca69a74 | ORPH
It's the same issue as the cmake issue above:
/home/test/autobuild/run/instance-3/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_err_set_errno at GPG_ERROR_1.0'
/home/test/autobuild/run/instance-3/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpgrt_lock_init at GPG_ERROR_1.0'
/home/test/autobuild/run/instance-3/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpgrt_lock_destroy at GPG_ERROR_1.0'
> sh4 | libepoxy-1.4.1 | NOK | http://autobuild.buildroot.net/results/38701cee74110de90cd72f720b3ee8bd69666325 |
The EGL issue, I will send a patch.
> x86_64 | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/5ee26b9676acc1a360bb86aa13a0c992727309a2 |
-fPIC issue it seems. It's weird because they only seem to appear with
musl toolchains.
> x86_64 | modem-manager-1.6.4 | NOK | http://autobuild.buildroot.net/results/8a551a29263d5daa12e1036a4e3804214fd4066a |
Would be fixed by https://patchwork.ozlabs.org/patch/762195/. I'll
apply.
> mips64el | ntp-4.2.8p10 | NOK | http://autobuild.buildroot.net/results/25efd86193d0b0fea2a4b2d84fb7f19baa140eb5 | ORPH
Another -fPIC issue. We have a patch proposed at
https://patchwork.ozlabs.org/patch/762084/, I'll try it out.
> x86_64 | oracle-mysql-5.1.73 | NOK | http://autobuild.buildroot.net/results/61074b69b81cd5c17a7f74dc1f7b31f3fc35fd8a | ORPH
protocol.cc:27:40: error: narrowing conversion of ''\37777777776'' from 'char' to 'uchar {aka unsigned char}' inside { } [-Wnarrowing]
static uchar eof_buff[1]= { (char) 254 }; /* Marker for end of fields */
I searched the oracle-mysql Git history, and I believe I might have a
fix for this.
> sparc | protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/4329cda610082053d0a8fd7796a690ddaa21de04 | ORPH
> sparc | protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/d1640867dee1b0fe8341698b1d4d02c5edff90a1 | ORPH
Fixed by https://git.buildroot.org/buildroot/commit/?id=ef9ffa3426edc895dc180d45b48bf305522b3450.
> arm | rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/d90fc2ccf61518f3c3198ef566976096f75c2776 |
Fixed by https://git.buildroot.org/buildroot/commit/?id=beb6524225f12549a216183abc07745f8d36e764
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [Buildroot] RPi B+ update
From: Waldemar Brodkorb @ 2017-05-17 17:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <24ea86ee-9b48-816f-3e7a-6d5a985ea339@gmail.com>
Hi,
what happens if you keep your old kernel and dtb and just update the firmware (start.elf, fixup.dat and the other file)?
I think new firmware can handle dt and non-dt kernel. You might need to add the trailer magic to the old kernel with mkknlimg.
best regards
Waldemar
> Am 17.05.2017 um 17:28 schrieb Marco Trapanese <marcotrapanese@gmail.com>:
>
> Il 17/05/2017 08:05, Marco Trapanese ha scritto:
>> I'm trying to do what you suggested. By the way the br version was 2014.11-git-00057-g86b4d75-dirty.
>> Updating firmware and device tree should not be a pain.
>>
>> I'm afraid about the kernel because I had to use a custom repository version (353043394c99ed37a4075da228af64468fdf6c06) and I changed some settings to fit my application.
>
>
> Well, some good news.
> Using the latest versions of buildroot (2017.05-rc1-00062-g4b4fc27) and kernel (4.9.21) I built an "empty" environment (without any additional package but the rpi-firmware). Copying both zImage and the fw files into the boot partition of the existing sd-card, leads to boot-up again!
>
> The problem now is related to the kernel drivers (wifi, rtc, cdc, etc...) that I manually selected using make linux-menuconfig and that were available (in the old rootfs) under /lib/modules/3.12.26. I'm afraid the new kernel doesn't know where to find them - and perhaps it cannot use them anyway because they are related to a different version.
>
> It seems I need to update the whole system...
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply
* [Buildroot] Hop tout set svn credentials when using svn to download tarballs
From: samMHN @ 2017-05-17 15:45 UTC (permalink / raw)
To: buildroot
In-Reply-To: <87a86ejq1i.fsf@dell.be.48ers.dk>
Hi Peter,
Thank your for you feedback,
I solved the issue I had with the SVN credential.
In fact what I noticed is that as my svn server url start with something
like http://XXXX/svn/XXXX the wget command is used by buildroot instead of
svn to download the tarballs. by adding the --user toto --password xxxx I
was able to be correctly authentified by my svn server.
Thank you again.
Samir MOUHOUNE
--
View this message in context: http://buildroot-busybox.2317881.n4.nabble.com/Hop-tout-set-svn-credentials-when-using-svn-to-download-tarballs-tp164671p165163.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
^ permalink raw reply
* [Buildroot] ti-sgx-km package status
From: Harron, Tim @ 2017-05-17 15:32 UTC (permalink / raw)
To: buildroot
Hi Lothar,
I was told you were working on a fix for a problem with the ti-sgx-km in TI kernels > 4.1 (per https://bugs.busybox.net/show_bug.cgi?id=9781).
Would you please let me know the status of this effort? Are the patches in a usable state?
Thanks!
-Tim
________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170517/93882b51/attachment.html>
^ permalink raw reply
* [Buildroot] RPi B+ update
From: Marco Trapanese @ 2017-05-17 15:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <224ff827-03b8-16d6-34fd-8be05cea607d@gmail.com>
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170517/46ddbecf/attachment.html>
^ permalink raw reply
* [Buildroot] [PATCH 1/1] lego: ev3: use mainline kernel
From: David Lechner @ 2017-05-17 15:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <878tlw8qsd.fsf@dell.be.48ers.dk>
On 05/16/2017 03:56 PM, Peter Korsgaard wrote:
>>>>>> "David" == David Lechner <david@lechnology.com> writes:
>
> > It is finally possible to boot LEGO MINDSTORMS EV3 from the mainline
> > Linux kernel. This patch updates the defconfg to use the mainline kernel
> > instead of the custom ev3dev kernel.
>
> Great, thanks!
>
> > .../patches/linux/0001-adc-device-tree-node.patch | 56 ++++++++++++++
> > .../linux/0002-sound-device-tree-node.patch | 85 ++++++++++++++++++++++
>
> I see these patches are already in mainline post-4.11, so that's great.
>
>> +++ b/board/lego/ev3/genimage.cfg
> > @@ -19,7 +19,7 @@ image flash.bin {
> > size = 320K
> > }
> > partition uimage {
> > - image = "uImage"
> > + image = "uImage.da850-lego-ev3"
> > size = 3M
> > offset = 0x50000
> > }
>
> I guess this change isn't strictly needed because of the symlink, but
> OK.
The symlink is something that I meant to ask about but forgot. I made
the symlink so that the file name in the FAT partition is correct when
creating an SD card image. I was wondering if there might be a better
way to rename the file using the genimage tool.
>
>> diff --git a/configs/lego_ev3_defconfig b/configs/lego_ev3_defconfig
> > index 543a227..0996b8c 100644
> > --- a/configs/lego_ev3_defconfig
> > +++ b/configs/lego_ev3_defconfig
> > @@ -2,22 +2,26 @@
> > BR2_arm=y
> > BR2_arm926t=y
>
> > +# Build options
> > +BR2_GLOBAL_PATCH_DIR="board/lego/ev3/patches"
> > +
> > # system
> > BR2_TARGET_GENERIC_GETTY=y
> > BR2_TARGET_GENERIC_GETTY_PORT="ttyS1"
> > BR2_ROOTFS_POST_IMAGE_SCRIPT="board/lego/ev3/post-image.sh"
> > -# Linux headers same as kernel, a 4.4 series
> > -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_4=y
>
> This shouldn't be dropped (after changing to 4.11) as the defconfig
> would otherwise break whenever 4.12 gets added.
>
> Committed to next with that fixed, thanks.
>
> I see you are still using a relatively old u-boot and ext3. Any reason
> to not use 2017.05 and ext4?
>
No reason. I will send another patch to update.
^ permalink raw reply
* [Buildroot] [Bug 9871] fbgrab 1.3 won't build with BR2_REPRODUCIBLE set
From: bugzilla at busybox.net @ 2017-05-17 14:55 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-9871-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=9871
Peter Korsgaard <jacmet@uclibc.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #1 from Peter Korsgaard <jacmet@uclibc.org> ---
fbgrab upstream isn't very active, so it is unlikely that we can get the fix
integrated in the near future. I've submitted a simpler patch that simply
doesn't compress the (unused) man page instead:
https://patchwork.ozlabs.org/patch/763602/
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* [Buildroot] [PATCH] fbgrab: explicitly build fbgrab target to workaround gzip issue
From: Peter Korsgaard @ 2017-05-17 14:52 UTC (permalink / raw)
To: buildroot
Fixes #9871
gzip reads default command line options from the environment variable GZIP.
The fbgrab Makefile internally also uses a GZIP make variable to know what
command to use to compress the manpage. Unfortunaly make will export the
value of this make variable to the environment if GZIP is already present in
the enviroment, confusing gzip (as 'gzip' isn't a valid command line argument).
This can either be triggered by users having GZIP set in their environment
(E.G. for custom options), or by enabling BR2_REPRODUCIBLE, where we use
this feature to force the -n option (to not store name/timestamp) to gzip.
We don't really need to compress the manpage as it isn't installed anyway,
so work around the issue by only building the fbgrab application.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
package/fbgrab/fbgrab.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/fbgrab/fbgrab.mk b/package/fbgrab/fbgrab.mk
index 15e0a95c9..d81a5ee2a 100644
--- a/package/fbgrab/fbgrab.mk
+++ b/package/fbgrab/fbgrab.mk
@@ -11,7 +11,7 @@ FBGRAB_LICENSE = GPL-2.0
FBGRAB_LICENSE_FILES = COPYING
define FBGRAB_BUILD_CMDS
- $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D)
+ $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D) fbgrab
endef
define FBGRAB_INSTALL_TARGET_CMDS
--
2.11.0
^ permalink raw reply related
* [Buildroot] [PATCH 1/1] libqmi: move canonicalize_file_name()
From: Matthew Weber @ 2017-05-17 14:05 UTC (permalink / raw)
To: buildroot
In-Reply-To: <821fc908-4c16-0153-8d64-adef6e959439@imgtec.com>
All,
On Mon, May 15, 2017 at 4:59 AM, Vicente Olivert Riera
<Vincent.Riera@imgtec.com> wrote:
>
> Hello Matt,
>
> On 15/05/17 03:26, Matt Weber wrote:
> > Previously was defined in qmi-util.h to fix musl
> > compatibility. It was missed that this is a shared
> > header which causes other dependent package builds
> > to fail, so the static definition was moved into the
> > implementation where it was used.
> >
> > Upstream bug report has been updated and this resolves
> > the following autobuilder related failures.
> >
> > http://autobuild.buildroot.net/results/fe9b6b1b1399a4e8aafc6a326c81ec97c2480025
> > http://autobuild.buildroot.net/results/40eef797b4d8d53fc6e10f2048316d63549caf6d
> >
> > test-pkg testing was performed against 10 random toolchains
> >
> > ++ Config snippet ++
> > BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
> > BR2_PACKAGE_MODEM_MANAGER_LIBQMI=y
> > BR2_PACKAGE_MODEM_MANAGER=y
> > BR2_PACKAGE_LIBQMI=y
> >
> > ++ Tested Toolchains ++ (Verified I hit all libc varients)
> > br-arm-cortex-a9-musl
> > br-arm-full-static
> > br-m68k-68040-full (uclibc)
> > br-mips32r6-el-hf-glibc
> > br-mips64-n64-full
> > br-mips64r6-el-hf-glibc
> > br-mipsel-o32-full
> > br-sparc64-glibc
> > linaro-arm
> > sourcery-arm
> >
> > Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
> Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>
> Tested with the following defconfig which was failing before this patch:
>
> BR2_mipsel=y
> BR2_mips_32r2=y
> # BR2_MIPS_SOFT_FLOAT is not set
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
> BR2_PACKAGE_MODEM_MANAGER=y
> BR2_PACKAGE_MODEM_MANAGER_LIBQMI=y
> # BR2_TARGET_ROOTFS_TAR is not set
>
> Regards,
>
> Vincent
>
<snip>
Bump, noticed modem manager failed again yesterday.
Matt
^ permalink raw reply
* [Buildroot] [PATCH next] tcpreplay: bump version to 4.2.6
From: Vicente Olivert Riera @ 2017-05-17 13:42 UTC (permalink / raw)
To: buildroot
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
package/tcpreplay/tcpreplay.hash | 2 +-
package/tcpreplay/tcpreplay.mk | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/tcpreplay/tcpreplay.hash b/package/tcpreplay/tcpreplay.hash
index c90896494..b033d3c3f 100644
--- a/package/tcpreplay/tcpreplay.hash
+++ b/package/tcpreplay/tcpreplay.hash
@@ -1,2 +1,2 @@
# Locally calculated after checking pgp signature
-sha256 941026be34e1db5101d3d22ebddd6fff76179a1ee81e273338f533ba4eca89d7 tcpreplay-4.2.5.tar.gz
+sha256 043756c532dab93e2be33a517ef46b1341f7239278a1045ae670041dd8a4531d tcpreplay-4.2.6.tar.gz
diff --git a/package/tcpreplay/tcpreplay.mk b/package/tcpreplay/tcpreplay.mk
index d303c60eb..adccde0eb 100644
--- a/package/tcpreplay/tcpreplay.mk
+++ b/package/tcpreplay/tcpreplay.mk
@@ -4,7 +4,7 @@
#
################################################################################
-TCPREPLAY_VERSION = 4.2.5
+TCPREPLAY_VERSION = 4.2.6
TCPREPLAY_SITE = https://github.com/appneta/tcpreplay/releases/download/v$(TCPREPLAY_VERSION)
TCPREPLAY_LICENSE = GPL-3.0
TCPREPLAY_LICENSE_FILES = docs/LICENSE
--
2.13.0
^ permalink raw reply related
* [Buildroot] [PATCH next] gnupg2: bump version to 2.1.21
From: Vicente Olivert Riera @ 2017-05-17 13:34 UTC (permalink / raw)
To: buildroot
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
Note to maintainer: you may want to add it to master instead as it
contains mainly bug fixes. See release notes.
https://lists.gnupg.org/pipermail/gnupg-announce/2017q2/000405.html
---
package/gnupg2/gnupg2.hash | 6 +++---
package/gnupg2/gnupg2.mk | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/package/gnupg2/gnupg2.hash b/package/gnupg2/gnupg2.hash
index 7eb8e5947..36fa575c7 100644
--- a/package/gnupg2/gnupg2.hash
+++ b/package/gnupg2/gnupg2.hash
@@ -1,4 +1,4 @@
-# From https://lists.gnupg.org/pipermail/gnupg-announce/2017q2/000404.html
-sha1 500ddae8e4225ae2e300934090f9b9a427b8def1 gnupg-2.1.20.tar.bz2
+# From https://lists.gnupg.org/pipermail/gnupg-announce/2017q2/000405.html
+sha1 1852c066bc21893bc52026ead78edf50fdf15e13 gnupg-2.1.21.tar.bz2
# Calculated based on the hash above
-sha256 24cf9a69369be64a9f6f8cc11a1be33ab7780ad77a6a1b93719438f49f69960d gnupg-2.1.20.tar.bz2
+sha256 7aead8a8ba75b69866f583b6c747d91414d523bfdfbe9a8e0fe026b16ba427dd gnupg-2.1.21.tar.bz2
diff --git a/package/gnupg2/gnupg2.mk b/package/gnupg2/gnupg2.mk
index db7f4cbd5..e5451639f 100644
--- a/package/gnupg2/gnupg2.mk
+++ b/package/gnupg2/gnupg2.mk
@@ -4,7 +4,7 @@
#
################################################################################
-GNUPG2_VERSION = 2.1.20
+GNUPG2_VERSION = 2.1.21
GNUPG2_SOURCE = gnupg-$(GNUPG2_VERSION).tar.bz2
GNUPG2_SITE = ftp://ftp.gnupg.org/gcrypt/gnupg
GNUPG2_LICENSE = GPL-3.0+
--
2.13.0
^ permalink raw reply related
* [Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict
From: Thomas Petazzoni @ 2017-05-17 13:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <b2085612a223f59a2f7ef18a9bd97603226aa03d.1478784433.git.baruch@tkos.co.il>
Hello Baruch,
I'm reviving this old thread, because my colleague Florent (in Cc) has
found an issue with this patch.
On Thu, 10 Nov 2016 15:27:11 +0200, Baruch Siach wrote:
> +# [1] http://www.openwall.com/lists/musl/2015/10/08/2
> +ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
> +define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
> + $(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \
> + $(STAGING_DIR)/usr/include/linux/libc-compat.h
> +endef
The problem with this is that libc-compat.h was introduced only in
kernel 3.12 (it seems). Therefore, trying to build a musl toolchain
with kernel headers 3.10 currently fails, with this $(SED) command
failing because $(STAGING_DIR)/usr/include/linux/libc-compat.h does not
exist.
So, we could add a kernel headers >= 3.12 to the condition to make the
build work, but then we wouldn't have the fix that these modifications
provide to avoid conflicts between libc and kernel headers.
Do you know if kernel headers < 3.12 are unaffected by the libc/kernel
headers conflict issue? If they are, do you know what the solution is
for kernel headers < 3.12 ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH] gnutls: bump version to 3.5.12
From: Peter Korsgaard @ 2017-05-17 13:03 UTC (permalink / raw)
To: buildroot
For details, see the release notes:
https://lists.gnupg.org/pipermail/gnutls-devel/2017-May/008427.html
https://lists.gnupg.org/pipermail/gnutls-devel/2017-April/008393.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
This contains a number of bugfixes and some of them with possible security
implications, so it IMHO makes sense to add to master.
package/gnutls/gnutls.hash | 2 +-
package/gnutls/gnutls.mk | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/gnutls/gnutls.hash b/package/gnutls/gnutls.hash
index 64b86d759..8e2469a5b 100644
--- a/package/gnutls/gnutls.hash
+++ b/package/gnutls/gnutls.hash
@@ -1,2 +1,2 @@
# Locally calculated after checking pgp signature
-sha256 af443e86ba538d4d3e37c4732c00101a492fe4b56a55f4112ff0ab39dbe6579d gnutls-3.5.10.tar.xz
+sha256 63cb39a5eaa029381df2e49a74cfb7be89fc4a592445191818ffe1e66bde57cb gnutls-3.5.12.tar.xz
diff --git a/package/gnutls/gnutls.mk b/package/gnutls/gnutls.mk
index 47da90fd7..c192469f9 100644
--- a/package/gnutls/gnutls.mk
+++ b/package/gnutls/gnutls.mk
@@ -5,7 +5,7 @@
################################################################################
GNUTLS_VERSION_MAJOR = 3.5
-GNUTLS_VERSION = $(GNUTLS_VERSION_MAJOR).10
+GNUTLS_VERSION = $(GNUTLS_VERSION_MAJOR).12
GNUTLS_SOURCE = gnutls-$(GNUTLS_VERSION).tar.xz
GNUTLS_SITE = ftp://ftp.gnutls.org/gcrypt/gnutls/v$(GNUTLS_VERSION_MAJOR)
GNUTLS_LICENSE = LGPL-2.1+ (core library), GPL-3.0+ (gnutls-openssl library)
--
2.11.0
^ permalink raw reply related
* [Buildroot] [Bug 9881] New: systemd-resolved not setting resolv.conf link
From: bugzilla at busybox.net @ 2017-05-17 12:46 UTC (permalink / raw)
To: buildroot
https://bugs.busybox.net/show_bug.cgi?id=9881
Bug ID: 9881
Summary: systemd-resolved not setting resolv.conf link
Product: buildroot
Version: 2017.02.1
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: posted at heine.so
CC: buildroot at uclibc.org
Target Milestone: ---
I have a configuration with Network-Manager and systemd-resolved but without
systemd-networkd.
This leads to a system with an invalid resolv.conf configuration.
The built system still has this configuration from skeleton:
/etc/resolv.conf -> ../tmp/resolv.conf
systemd is not touching /etc/resolv.conf since it exists (but points to
nothing.)
the systemd.mk defines this:
define SYSTEMD_INSTALL_RESOLVCONF_HOOK
ln -sf ../run/systemd/resolve/resolv.conf \
$(TARGET_DIR)/etc/resolv.conf
endef
But this is only used when systemd-networkd is selected. I guess this should
also be done when only BR2_PACKAGE_SYSTEMD_RESOLVED is selected.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* [Buildroot] [Bug 9876] aarch64 support with gcc 4.8 toolchain
From: bugzilla at busybox.net @ 2017-05-17 12:38 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-9876-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=9876
--- Comment #2 from Jean-pierre Cartal <jpcartal@free.fr> ---
Hi,
Thanks for your help.
Unfortunately we don't have much choice regarding the toolchain version as it
is currently provided by a 3rd party. We might try to use buildroot toolchain
since that would indeed solve our issue. Thanks for the tip on where to remove
the lp64 option.
As a side note, wouldn't it make sense to disable aarch64 compilation with
external gcc toolchains older than 4.9.x since it will not work ?
Regards.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* [Buildroot] [Bug 9876] aarch64 support with gcc 4.8 toolchain
From: bugzilla at busybox.net @ 2017-05-17 12:32 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-9876-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=9876
Peter Korsgaard <jacmet@uclibc.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #1 from Peter Korsgaard <jacmet@uclibc.org> ---
(In reply to Jean-pierre Cartal from comment #0)
You could remove the lp64 line from arch/Config.in.arm, but considering how old
gcc 4.8 is compared to aarch64, does it really make sense to use such an old
toolchain?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* [Buildroot] [PATCH v3] package/pulseview: fix a build issue
From: Peter Korsgaard @ 2017-05-17 12:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1495015800-30480-1-git-send-email-brgl@bgdev.pl>
>>>>> "Bartosz" == Bartosz Golaszewski <brgl@bgdev.pl> writes:
> Backport an upstream patch fixing the build issue related to boost
> math definitions.
> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Committed after adding a reference to the autobuilder failures, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit] package/pulseview: fix a build issue
From: Peter Korsgaard @ 2017-05-17 12:26 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=f884abe4de72b942406ca16c4f54e02a0c57cce4
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Backport an upstream patch fixing the build issue related to boost
math definitions.
Fixes:
http://autobuild.buildroot.net/results/e9f/e9f3f175e203529c44ecf92a34b82a0b3a473e34/
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
...txt-Avoid-fext-numeric-literals-not-suppo.patch | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/package/pulseview/0003-CMakeLists.txt-Avoid-fext-numeric-literals-not-suppo.patch b/package/pulseview/0003-CMakeLists.txt-Avoid-fext-numeric-literals-not-suppo.patch
new file mode 100644
index 0000000..89137f2
--- /dev/null
+++ b/package/pulseview/0003-CMakeLists.txt-Avoid-fext-numeric-literals-not-suppo.patch
@@ -0,0 +1,28 @@
+From 6ad4d7a6f17edecc3523a7ab3d627f9a70dbacc1 Mon Sep 17 00:00:00 2001
+From: Uwe Hermann <uwe@hermann-uwe.de>
+Date: Wed, 17 May 2017 11:00:44 +0200
+Subject: [PATCH] CMakeLists.txt: Avoid -fext-numeric-literals, (not supported
+ by clang).
+
+This (re-)fixes bug #863.
+
+Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
+---
+ CMakeLists.txt | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index e8bc79f..e7e4432 100644
+--- a/CMakeLists.txt
++++ b/CMakeLists.txt
+@@ -395,6 +395,7 @@ add_definitions(${QT_DEFINITIONS} -DQT_NO_KEYWORDS)
+ add_definitions(-D__STDC_LIMIT_MACROS)
+ add_definitions(-Wall -Wextra)
+ add_definitions(-std=c++11)
++add_definitions(-DBOOST_MATH_DISABLE_FLOAT128=1)
+
+ if(ENABLE_DECODE)
+ add_definitions(-DENABLE_DECODE)
+--
+2.9.3
+
^ permalink raw reply related
* [Buildroot] [Bug 9876] New: aarch64 support with gcc 4.8 toolchain
From: bugzilla at busybox.net @ 2017-05-17 11:34 UTC (permalink / raw)
To: buildroot
https://bugs.busybox.net/show_bug.cgi?id=9876
Bug ID: 9876
Summary: aarch64 support with gcc 4.8 toolchain
Product: buildroot
Version: 2017.02
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: jpcartal at free.fr
CC: buildroot at uclibc.org
Target Milestone: ---
Hello,
I'm trying to compile for the aarch64 architecture using an external gcc 4.8
toolchain.
However I get the following error :
>>> toolchain-external-custom Installing to staging directory
/usr/bin/install -D -m 0755
/home/jpcartal/Dev/Ssd/buildroot/buildroot-2017.02/N30_test/build/toolchain-external-custom/toolchain-wrapper
/home/jpcartal/Dev/Ssd/buildroot/buildroot-2017.02/N30_test/host/usr/bin/toolchain-wrapper
aarch64-linux-gcc: error: unrecognized command line option '-mabi=lp64'
My understanding is that the mabi=lp64 option is only available on gcc 4.9.x
and newer.
Is there any solution available to compile for aarch64 architecture with a gcc
4.8.x toolchain ?
Thanks for your help.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* [Buildroot] [PATCH v3] package/pulseview: fix a build issue
From: Bartosz Golaszewski @ 2017-05-17 10:10 UTC (permalink / raw)
To: buildroot
Backport an upstream patch fixing the build issue related to boost
math definitions.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
---
v1 -> v2:
- backported the upstream patch instead of fixing it myself
v2 -> v3:
- dropped the patch numbering
- added the missing sign-off
...txt-Avoid-fext-numeric-literals-not-suppo.patch | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 package/pulseview/0003-CMakeLists.txt-Avoid-fext-numeric-literals-not-suppo.patch
diff --git a/package/pulseview/0003-CMakeLists.txt-Avoid-fext-numeric-literals-not-suppo.patch b/package/pulseview/0003-CMakeLists.txt-Avoid-fext-numeric-literals-not-suppo.patch
new file mode 100644
index 0000000..89137f2
--- /dev/null
+++ b/package/pulseview/0003-CMakeLists.txt-Avoid-fext-numeric-literals-not-suppo.patch
@@ -0,0 +1,28 @@
+From 6ad4d7a6f17edecc3523a7ab3d627f9a70dbacc1 Mon Sep 17 00:00:00 2001
+From: Uwe Hermann <uwe@hermann-uwe.de>
+Date: Wed, 17 May 2017 11:00:44 +0200
+Subject: [PATCH] CMakeLists.txt: Avoid -fext-numeric-literals, (not supported
+ by clang).
+
+This (re-)fixes bug #863.
+
+Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
+---
+ CMakeLists.txt | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index e8bc79f..e7e4432 100644
+--- a/CMakeLists.txt
++++ b/CMakeLists.txt
+@@ -395,6 +395,7 @@ add_definitions(${QT_DEFINITIONS} -DQT_NO_KEYWORDS)
+ add_definitions(-D__STDC_LIMIT_MACROS)
+ add_definitions(-Wall -Wextra)
+ add_definitions(-std=c++11)
++add_definitions(-DBOOST_MATH_DISABLE_FLOAT128=1)
+
+ if(ENABLE_DECODE)
+ add_definitions(-DENABLE_DECODE)
+--
+2.9.3
+
--
2.9.3
^ 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