* [Buildroot] [PATCH 1/1] toolchain-external: dynamic loader symlink to actual location of musl libc.so
From: Ilya Kuzmich @ 2017-05-18 13:03 UTC (permalink / raw)
To: buildroot
Test whenever musl libc.so located at /lib or /usr/lib and create dynamic
library loader symlink accordingly.
Signed-off-by: Ilya Kuzmich <ilya.kuzmich@gmail.com>
---
toolchain/toolchain-external/pkg-toolchain-external.mk | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/toolchain/toolchain-external/pkg-toolchain-external.mk b/toolchain/toolchain-external/pkg-toolchain-external.mk
index 9670350..438d714 100644
--- a/toolchain/toolchain-external/pkg-toolchain-external.mk
+++ b/toolchain/toolchain-external/pkg-toolchain-external.mk
@@ -489,7 +489,12 @@ else
MUSL_ARCH = $(ARCH)
endif
define TOOLCHAIN_EXTERNAL_MUSL_LD_LINK
- ln -sf libc.so $(TARGET_DIR)/lib/ld-musl-$(MUSL_ARCH).so.1
+ if test -e $(STAGING_DIR)/usr/lib/libc.so; then \
+ LD_LINK_TARGET=../usr/lib/libc.so ;\
+ else \
+ LD_LINK_TARGET=libc.so ;\
+ fi ;\
+ ln -sf "$${LD_LINK_TARGET}" $(TARGET_DIR)/lib/ld-musl-$(MUSL_ARCH).so.1 ;
endef
endif
--
2.7.4
^ permalink raw reply related
* [Buildroot] [PATCH 1/1] package/avrdude: fix gpio definition, add kconfig option
From: Matthew Weber @ 2017-05-18 12:37 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1495061934-57465-1-git-send-email-matthew.weber@rockwellcollins.com>
All,
On Wed, May 17, 2017 at 5:58 PM, Matt Weber
<matthew.weber@rockwellcollins.com> wrote:
> From: Sam Voss <samuel.voss@rockwellcollins.com>
>
> Fix bug causing '--enable-linuxgpio' to not work
> due to a misnamed definition. This patch has been
> submitted upstream at https://github.com/kcuzner/avrdude/pull/15.
The upstream portion was merged yesterday, will send a v2 later today
removing it and bumping the version.
Matt
^ permalink raw reply
* [Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict
From: Baruch Siach @ 2017-05-18 11:37 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20170518132448.3996edba@free-electrons.com>
Hi Thomas,
On Thu, May 18, 2017 at 01:24:48PM +0200, Thomas Petazzoni wrote:
> On Thu, 18 May 2017 14:17:44 +0300, Baruch Siach wrote:
> > Would that be better (untested)?
> >
> > diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk
> > index e29837357a27..e15ceeb426fa 100644
> > --- a/toolchain/toolchain/toolchain.mk
> > +++ b/toolchain/toolchain/toolchain.mk
> > @@ -21,8 +21,10 @@ TOOLCHAIN_ADD_TOOLCHAIN_DEPENDENCY = NO
> > # IFF_DORMANT and IFF_ECHO, add another macro to suppress them in the
> > # kernel header, and avoid macro/enum conflict.
> > #
> > +# Kernel version 3.12 introduced the libc-compat.h header.
> > +#
> > # [1] http://www.openwall.com/lists/musl/2015/10/08/2
> > -ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
> > +ifeq ($(BR2_TOOLCHAIN_USES_MUSL)$(BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12),yy)
> > define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
> > $(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \
> > $(STAGING_DIR)/usr/include/linux/libc-compat.h
>
> Yes. The question is whether we will see those build failures due to
> kernel/userspace headers conflicts. Do you remember a simple
> package/scenario that triggers the problem?
The following two commits in this series, c0b756cac412 (Revert "bridge-utils:
fix build with musl"), and bae792e4c04 (Revert "norm: add patch to fix musl
build"), point at some likely build failure candidates.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict
From: Thomas Petazzoni @ 2017-05-18 11:24 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20170518111744.pto4qg53yttqe4a2@tarshish>
Hello,
On Thu, 18 May 2017 14:17:44 +0300, Baruch Siach wrote:
> Would that be better (untested)?
>
> diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk
> index e29837357a27..e15ceeb426fa 100644
> --- a/toolchain/toolchain/toolchain.mk
> +++ b/toolchain/toolchain/toolchain.mk
> @@ -21,8 +21,10 @@ TOOLCHAIN_ADD_TOOLCHAIN_DEPENDENCY = NO
> # IFF_DORMANT and IFF_ECHO, add another macro to suppress them in the
> # kernel header, and avoid macro/enum conflict.
> #
> +# Kernel version 3.12 introduced the libc-compat.h header.
> +#
> # [1] http://www.openwall.com/lists/musl/2015/10/08/2
> -ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
> +ifeq ($(BR2_TOOLCHAIN_USES_MUSL)$(BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12),yy)
> define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
> $(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \
> $(STAGING_DIR)/usr/include/linux/libc-compat.h
Yes. The question is whether we will see those build failures due to
kernel/userspace headers conflicts. Do you remember a simple
package/scenario that triggers the problem?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict
From: Baruch Siach @ 2017-05-18 11:17 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20170518091030.66a9cbee@free-electrons.com>
Hi Thomas,
On Thu, May 18, 2017 at 09:10:30AM +0200, Thomas Petazzoni wrote:
> On Thu, 18 May 2017 07:57:54 +0300, Baruch Siach wrote:
>
> > I have not tested kernel headers earlier than v3.12. Having a look at the
> > headers and the log of kernel commit cfd280c91253cc28 (net: sync some IP
> > headers with glibc), I'm pretty sure that the same issue also affects older
> > kernels.
> >
> > Should we just disallow build of musl toolchain with older kernels? Something
> > like:
>
> That's one option, though a bit annoying, no? Just for this "small"
> reason, we prevent people from using musl toolchains on kernels older
> than 3.12 ?
Would that be better (untested)?
diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk
index e29837357a27..e15ceeb426fa 100644
--- a/toolchain/toolchain/toolchain.mk
+++ b/toolchain/toolchain/toolchain.mk
@@ -21,8 +21,10 @@ TOOLCHAIN_ADD_TOOLCHAIN_DEPENDENCY = NO
# IFF_DORMANT and IFF_ECHO, add another macro to suppress them in the
# kernel header, and avoid macro/enum conflict.
#
+# Kernel version 3.12 introduced the libc-compat.h header.
+#
# [1] http://www.openwall.com/lists/musl/2015/10/08/2
-ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
+ifeq ($(BR2_TOOLCHAIN_USES_MUSL)$(BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12),yy)
define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
$(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \
$(STAGING_DIR)/usr/include/linux/libc-compat.h
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply related
* [Buildroot] [PATCH next] redis: bump version to 3.2.9
From: Vicente Olivert Riera @ 2017-05-18 10:32 UTC (permalink / raw)
To: buildroot
Remove sha1 hash. Upstream provides now a sha256 hash.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
package/redis/redis.hash | 4 +---
package/redis/redis.mk | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/package/redis/redis.hash b/package/redis/redis.hash
index 3cd86470b..2eef91cc0 100644
--- a/package/redis/redis.hash
+++ b/package/redis/redis.hash
@@ -1,4 +1,2 @@
# From https://github.com/antirez/redis-hashes/blob/master/README
-sha1 6780d1abb66f33a97aad0edbe020403d0a15b67f redis-3.2.8.tar.gz
-# Calculated based on the hash above
-sha256 61b373c23d18e6cc752a69d5ab7f676c6216dc2853e46750a8c4ed791d68482c redis-3.2.8.tar.gz
+sha256 6eaacfa983b287e440d0839ead20c2231749d5d6b78bbe0e0ffa3a890c59ff26 redis-3.2.9.tar.gz
diff --git a/package/redis/redis.mk b/package/redis/redis.mk
index 3f4956cf3..67e9e7e8c 100644
--- a/package/redis/redis.mk
+++ b/package/redis/redis.mk
@@ -4,7 +4,7 @@
#
################################################################################
-REDIS_VERSION = 3.2.8
+REDIS_VERSION = 3.2.9
REDIS_SITE = http://download.redis.io/releases
REDIS_LICENSE = BSD-3-Clause (core); MIT and BSD family licenses (Bundled components)
REDIS_LICENSE_FILES = COPYING
--
2.13.0
^ permalink raw reply related
* [Buildroot] [PATCH v5 next 2/2] cmake: bump version to 3.8.1
From: Vicente Olivert Riera @ 2017-05-18 9:47 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20170518094746.657-1-Vincent.Riera@imgtec.com>
cmake depends on rhash, but host-cmake doesn't. This is because we use
the bundled dependencies for host-cmake but not for target.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
Changes v4 -> v5:
- Nothing
Changes v3 -> v4:
- Nothing
Changes v2 -> v3:
- Bump version to 3.8.1
- Change LIBRHASH references to RHASH
Changes v1 -> v2:
- Added explanation in the commit log about why rhash dependency is
needed for cmake but not for host-cmake. (Arnout)
---
package/cmake/Config.in | 1 +
package/cmake/cmake.hash | 4 ++--
package/cmake/cmake.mk | 6 +++---
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/package/cmake/Config.in b/package/cmake/Config.in
index 64ab15418..e7bd14e69 100644
--- a/package/cmake/Config.in
+++ b/package/cmake/Config.in
@@ -29,6 +29,7 @@ config BR2_PACKAGE_CMAKE_CTEST
select BR2_PACKAGE_BZIP2
select BR2_PACKAGE_XZ
select BR2_PACKAGE_LIBUV
+ select BR2_PACKAGE_RHASH
help
CTest is a testing tool distributed as a part of CMake. It
can be used to automate updating (using CVS for example),
diff --git a/package/cmake/cmake.hash b/package/cmake/cmake.hash
index 13c023759..2aea9bc11 100644
--- a/package/cmake/cmake.hash
+++ b/package/cmake/cmake.hash
@@ -1,2 +1,2 @@
-# From http://www.cmake.org/files/v3.7/cmake-3.7.2-SHA-256.txt
-sha256 dc1246c4e6d168ea4d6e042cfba577c1acd65feea27e56f5ff37df920c30cae0 cmake-3.7.2.tar.gz
+# From http://www.cmake.org/files/v3.8/cmake-3.8.1-SHA-256.txt
+sha256 ce5d9161396e06501b00e52933783150a87c33080d4bdcef461b5b7fd24ac228 cmake-3.8.1.tar.gz
diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk
index d9eea3285..10af41504 100644
--- a/package/cmake/cmake.mk
+++ b/package/cmake/cmake.mk
@@ -4,8 +4,8 @@
#
################################################################################
-CMAKE_VERSION_MAJOR = 3.7
-CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).2
+CMAKE_VERSION_MAJOR = 3.8
+CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).1
CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR)
CMAKE_LICENSE = BSD-3-Clause
CMAKE_LICENSE_FILES = Copyright.txt
@@ -22,7 +22,7 @@ CMAKE_LICENSE_FILES = Copyright.txt
# the system-wide libraries instead of rebuilding and statically
# linking with the ones bundled into the CMake sources.
-CMAKE_DEPENDENCIES = zlib jsoncpp libcurl libarchive expat bzip2 xz libuv
+CMAKE_DEPENDENCIES = zlib jsoncpp libcurl libarchive expat bzip2 xz libuv rhash
CMAKE_CONF_OPTS = \
-DKWSYS_LFS_WORKS=TRUE \
--
2.13.0
^ permalink raw reply related
* [Buildroot] [PATCH v5 next 1/2] rhash: new package
From: Vicente Olivert Riera @ 2017-05-18 9:47 UTC (permalink / raw)
To: buildroot
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
Changes v4 -> v5:
- Do not install the console utility to staging.
Changes v3 -> v4:
- Add a comment explaining why we install the console utility to the
staging directory. (Baruch)
- Perform the installation of the console utility to the staging
directory into a post-install-staginig-hook. (Yann)
Changes v2 -> v3:
- Nothing
Changes v1 -> v2:
- Rename package to rhash
- Take the help text of the library instead of the console utility
- Sub-config option for the rhash binary starts with the package name
- Conditionals for shared/static/shared-static reordered
- Put make options into a make_opts variable
- Install the console utility to staging as well
(All suggestions by Arnout)
---
package/Config.in | 1 +
package/rhash/Config.in | 24 ++++++++++++++++++
package/rhash/rhash.hash | 3 +++
package/rhash/rhash.mk | 66 ++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 94 insertions(+)
create mode 100644 package/rhash/Config.in
create mode 100644 package/rhash/rhash.hash
create mode 100644 package/rhash/rhash.mk
diff --git a/package/Config.in b/package/Config.in
index 7991353f9..e07e380d5 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -964,6 +964,7 @@ menu "Crypto"
source "package/mbedtls/Config.in"
source "package/nettle/Config.in"
source "package/openssl/Config.in"
+ source "package/rhash/Config.in"
source "package/tinydtls/Config.in"
source "package/trousers/Config.in"
source "package/ustream-ssl/Config.in"
diff --git a/package/rhash/Config.in b/package/rhash/Config.in
new file mode 100644
index 000000000..65812438e
--- /dev/null
+++ b/package/rhash/Config.in
@@ -0,0 +1,24 @@
+config BR2_PACKAGE_RHASH
+ bool "rhash"
+ select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT_IF_LOCALE
+ help
+ LibRHash is a professional, portable, thread-safe C library for
+ computing a wide variety of hash sums, such as CRC32, MD4, MD5,
+ SHA1, SHA256, SHA512, SHA3, AICH, ED2K, Tiger, DC++ TTH, BitTorrent
+ BTIH, GOST R 34.11-94, RIPEMD-160, HAS-160, EDON-R, Whirlpool and
+ Snefru.
+
+ https://github.com/rhash/RHash
+
+if BR2_PACKAGE_RHASH
+
+config BR2_PACKAGE_RHASH_BIN
+ bool "rhash binary"
+ depends on !BR2_STATIC_LIBS
+ help
+ Install rhash console utility
+
+comment "rhash binary needs a toolchain w/ dynamic library"
+ depends on BR2_STATIC_LIBS
+
+endif
diff --git a/package/rhash/rhash.hash b/package/rhash/rhash.hash
new file mode 100644
index 000000000..5efc3a67b
--- /dev/null
+++ b/package/rhash/rhash.hash
@@ -0,0 +1,3 @@
+# From https://sourceforge.net/projects/rhash/files/rhash/1.3.4/
+md5 0b51010604659e9e99f6307b053ba13b rhash-1.3.4-src.tar.gz
+sha1 411d8c7ba84fa9763bc49fa2fd3a7587712fd52c rhash-1.3.4-src.tar.gz
diff --git a/package/rhash/rhash.mk b/package/rhash/rhash.mk
new file mode 100644
index 000000000..5a31bef08
--- /dev/null
+++ b/package/rhash/rhash.mk
@@ -0,0 +1,66 @@
+################################################################################
+#
+# rhash
+#
+################################################################################
+
+RHASH_VERSION = 1.3.4
+RHASH_SOURCE = rhash-$(RHASH_VERSION)-src.tar.gz
+RHASH_SITE = https://sourceforge.net/projects/rhash/files/rhash/$(RHASH_VERSION)
+RHASH_LICENSE = MIT
+RHASH_LICENSE_FILES = COPYING
+RHASH_INSTALL_STAGING = YES
+
+ifeq ($(BR2_NEEDS_GETTEXT_IF_LOCALE),y)
+RHASH_DEPENDENCIES += gettext
+RHASH_ADDCFLAGS += -DUSE_GETTEXT
+RHASH_ADDLDFLAGS += -lintl
+endif
+
+ifeq ($(BR2_PACKAGE_OPENSSL)x$(BR2_STATIC_LIBS),yx)
+RHASH_DEPENDENCIES += openssl
+RHASH_ADDCFLAGS += -DOPENSSL_RUNTIME -rdynamic
+RHASH_ADDLDFLAGS += -ldl
+endif
+
+RHASH_MAKE_OPTS = \
+ ADDCFLAGS="$(RHASH_ADDCFLAGS)" \
+ ADDLDFLAGS="$(RHASH_ADDLDFLAGS)" \
+ PREFIX="/usr"
+
+ifeq ($(BR2_SHARED_LIBS),y)
+RHASH_BUILD_TARGETS = lib-shared build-shared
+RHASH_INSTALL_TARGETS = install-lib-shared install-so-link
+else ifeq ($(BR2_STATIC_LIBS),y)
+RHASH_BUILD_TARGETS = lib-static
+RHASH_INSTALL_TARGETS = install-lib-static
+else
+RHASH_BUILD_TARGETS = lib-static lib-shared build-shared
+RHASH_INSTALL_TARGETS = install-lib-static install-lib-shared install-so-link
+endif
+
+define RHASH_BUILD_CMDS
+ $(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D) \
+ $(RHASH_MAKE_OPTS) $(RHASH_BUILD_TARGETS)
+endef
+
+define RHASH_INSTALL_STAGING_CMDS
+ $(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D)/librhash \
+ DESTDIR="$(STAGING_DIR)" $(RHASH_MAKE_OPTS) $(RHASH_INSTALL_TARGETS) \
+ install-headers
+endef
+
+define RHASH_INSTALL_TARGET_CMDS
+ $(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D)/librhash \
+ DESTDIR="$(TARGET_DIR)" $(RHASH_MAKE_OPTS) $(RHASH_INSTALL_TARGETS)
+endef
+
+ifeq ($(BR2_PACKAGE_RHASH_BIN),y)
+define RHASH_INSTALL_TARGET_RHASH_BIN
+ $(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D) \
+ DESTDIR="$(TARGET_DIR)" $(RHASH_MAKE_OPTS) install-shared
+endef
+RHASH_POST_INSTALL_TARGET_HOOKS += RHASH_INSTALL_TARGET_RHASH_BIN
+endif
+
+$(eval $(generic-package))
--
2.13.0
^ permalink raw reply related
* [Buildroot] [PATCH] package/ntp: fix aarch64/mips build, -fPIC required
From: Thomas Petazzoni @ 2017-05-18 9:11 UTC (permalink / raw)
To: buildroot
In-Reply-To: <e27400a3-9128-57f5-57a3-d85cd307eb3d@imgtec.com>
Hello,
On Thu, 18 May 2017 10:02:26 +0100, Vicente Olivert Riera wrote:
> thank you very much for fixing this! It's sad that we have to use such
> kind of hacks or patches to fix something that shouldn't happen at all,
> since the ntp configure script can accept --with-pic=yes.
Not sure what you mean here. The ntp configure script detects if fPIC
is needed or not. The only thing that was missing is that this flag was
not propagated to ntpq/Makefile.am.
See my final commit,
https://git.buildroot.org/buildroot/commit/?id=7fde83cdf0da338937dae13144eea2923e5c2730.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH] package/ntp: fix aarch64/mips build, -fPIC required
From: Vicente Olivert Riera @ 2017-05-18 9:02 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20170517214810.35d31ce4@free-electrons.com>
Hi Romain and Thomas,
thank you very much for fixing this! It's sad that we have to use such
kind of hacks or patches to fix something that shouldn't happen at all,
since the ntp configure script can accept --with-pic=yes.
Anyway, glad to see this fixed :-) Thanks again!
Vincent
On 17/05/17 20:48, Thomas Petazzoni wrote:
> 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
>
^ permalink raw reply
* [Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict
From: Thomas Petazzoni @ 2017-05-18 7:10 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20170518045754.ecwqdtj35acvzk6b@tarshish>
Hello,
On Thu, 18 May 2017 07:57:54 +0300, Baruch Siach wrote:
> I have not tested kernel headers earlier than v3.12. Having a look at the
> headers and the log of kernel commit cfd280c91253cc28 (net: sync some IP
> headers with glibc), I'm pretty sure that the same issue also affects older
> kernels.
>
> Should we just disallow build of musl toolchain with older kernels? Something
> like:
That's one option, though a bit annoying, no? Just for this "small"
reason, we prevent people from using musl toolchains on kernels older
than 3.12 ?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH 1/1] ltp-testsuite: bump version to 20170516
From: Petr Vorel @ 2017-05-18 6:56 UTC (permalink / raw)
To: buildroot
Drop patch accepted upstream.
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
---
...-unused-and-not-available-for-uClibc-ng-l.patch | 157 ---------------------
package/ltp-testsuite/ltp-testsuite.hash | 4 +-
package/ltp-testsuite/ltp-testsuite.mk | 2 +-
3 files changed, 3 insertions(+), 160 deletions(-)
delete mode 100644 package/ltp-testsuite/0004-rusers.h-is-unused-and-not-available-for-uClibc-ng-l.patch
diff --git a/package/ltp-testsuite/0004-rusers.h-is-unused-and-not-available-for-uClibc-ng-l.patch b/package/ltp-testsuite/0004-rusers.h-is-unused-and-not-available-for-uClibc-ng-l.patch
deleted file mode 100644
index fc3dce97e..000000000
--- a/package/ltp-testsuite/0004-rusers.h-is-unused-and-not-available-for-uClibc-ng-l.patch
+++ /dev/null
@@ -1,157 +0,0 @@
-From 780bec6c2742231ca73d4dee51c727815cf857b3 Mon Sep 17 00:00:00 2001
-From: Erico Nunes <nunes.erico@gmail.com>
-Date: Fri, 30 Sep 2016 17:45:31 +0200
-Subject: [PATCH] rusers.h is unused and not available for uClibc-ng / libtirpc
-
-Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
-[Erico: Rebase for ltp 20160920]
-Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
----
- .../tests_pack/rpc_suite/rpc/rpc_auth_auth_destroy/rpc_auth_destroy.c | 1 -
- .../rpc_suite/rpc/rpc_auth_authnone_create/rpc_authnone_create.c | 1 -
- .../rpc_suite/rpc/rpc_auth_authunix_create/rpc_authunix_create.c | 1 -
- .../rpc/rpc_auth_authunix_create_default/rpc_authunix_create_default.c | 1 -
- .../rpc_suite/rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create.c | 1 -
- .../rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create_limits.c | 1 -
- .../rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create_stress.c | 1 -
- .../rpc/rpc_createdestroy_clntudp_bufcreate/rpc_clntudp_bufcreate.c | 1 -
- .../rpc_createdestroy_clntudp_bufcreate/rpc_clntudp_bufcreate_limits.c | 1 -
- .../rpc_suite/rpc/rpc_createdestroy_clntudp_create/rpc_clntudp_create.c | 1 -
- .../rpc/rpc_createdestroy_clntudp_create/rpc_clntudp_create_stress.c | 1 -
- 11 files changed, 11 deletions(-)
-
-diff --git a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_auth_destroy/rpc_auth_destroy.c b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_auth_destroy/rpc_auth_destroy.c
-index 7f157e1..728c023 100644
---- a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_auth_destroy/rpc_auth_destroy.c
-+++ b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_auth_destroy/rpc_auth_destroy.c
-@@ -30,7 +30,6 @@
- #include <time.h>
- #include <rpc/rpc.h>
- #include <sys/socket.h>
--#include <rpcsvc/rusers.h>
- #include <utmp.h>
- #include <sys/time.h>
- #include <netdb.h>
-diff --git a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_authnone_create/rpc_authnone_create.c b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_authnone_create/rpc_authnone_create.c
-index d9a3111..8d80a5e 100644
---- a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_authnone_create/rpc_authnone_create.c
-+++ b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_authnone_create/rpc_authnone_create.c
-@@ -30,7 +30,6 @@
- #include <time.h>
- #include <rpc/rpc.h>
- #include <sys/socket.h>
--#include <rpcsvc/rusers.h>
- #include <utmp.h>
- #include <sys/time.h>
- #include <netdb.h>
-diff --git a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_authunix_create/rpc_authunix_create.c b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_authunix_create/rpc_authunix_create.c
-index cabffc7..a4d1d6f 100644
---- a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_authunix_create/rpc_authunix_create.c
-+++ b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_authunix_create/rpc_authunix_create.c
-@@ -30,7 +30,6 @@
- #include <time.h>
- #include <rpc/rpc.h>
- #include <sys/socket.h>
--#include <rpcsvc/rusers.h>
- #include <utmp.h>
- #include <sys/time.h>
- #include <netdb.h>
-diff --git a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_authunix_create_default/rpc_authunix_create_default.c b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_authunix_create_default/rpc_authunix_create_default.c
-index 4f10466..863aec7 100644
---- a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_authunix_create_default/rpc_authunix_create_default.c
-+++ b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_auth_authunix_create_default/rpc_authunix_create_default.c
-@@ -30,7 +30,6 @@
- #include <time.h>
- #include <rpc/rpc.h>
- #include <sys/socket.h>
--#include <rpcsvc/rusers.h>
- #include <utmp.h>
- #include <sys/time.h>
- #include <netdb.h>
-diff --git a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create.c b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create.c
-index 290f357..e849468 100644
---- a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create.c
-+++ b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create.c
-@@ -30,7 +30,6 @@
- #include <time.h>
- #include <rpc/rpc.h>
- #include <sys/socket.h>
--#include <rpcsvc/rusers.h>
- #include <utmp.h>
- #include <sys/time.h>
- #include <netdb.h>
-diff --git a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create_limits.c b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create_limits.c
-index 55bac16..8c1800b 100644
---- a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create_limits.c
-+++ b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create_limits.c
-@@ -30,7 +30,6 @@
- #include <time.h>
- #include <rpc/rpc.h>
- #include <sys/socket.h>
--#include <rpcsvc/rusers.h>
- #include <utmp.h>
- #include <sys/time.h>
- #include <netdb.h>
-diff --git a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create_stress.c b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create_stress.c
-index 09d1bf9..384a00d 100644
---- a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create_stress.c
-+++ b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clnttcp_create/rpc_clnttcp_create_stress.c
-@@ -30,7 +30,6 @@
- #include <time.h>
- #include <rpc/rpc.h>
- #include <sys/socket.h>
--#include <rpcsvc/rusers.h>
- #include <utmp.h>
- #include <sys/time.h>
- #include <netdb.h>
-diff --git a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_bufcreate/rpc_clntudp_bufcreate.c b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_bufcreate/rpc_clntudp_bufcreate.c
-index 3e15306..285eb21 100644
---- a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_bufcreate/rpc_clntudp_bufcreate.c
-+++ b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_bufcreate/rpc_clntudp_bufcreate.c
-@@ -30,7 +30,6 @@
- #include <time.h>
- #include <rpc/rpc.h>
- #include <sys/socket.h>
--#include <rpcsvc/rusers.h>
- #include <utmp.h>
- #include <sys/time.h>
- #include <netdb.h>
-diff --git a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_bufcreate/rpc_clntudp_bufcreate_limits.c b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_bufcreate/rpc_clntudp_bufcreate_limits.c
-index a7030a2..1f2690a 100644
---- a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_bufcreate/rpc_clntudp_bufcreate_limits.c
-+++ b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_bufcreate/rpc_clntudp_bufcreate_limits.c
-@@ -30,7 +30,6 @@
- #include <time.h>
- #include <rpc/rpc.h>
- #include <sys/socket.h>
--#include <rpcsvc/rusers.h>
- #include <utmp.h>
- #include <sys/time.h>
- #include <netdb.h>
-diff --git a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_create/rpc_clntudp_create.c b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_create/rpc_clntudp_create.c
-index 06f4740..faa8ef6 100644
---- a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_create/rpc_clntudp_create.c
-+++ b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_create/rpc_clntudp_create.c
-@@ -30,7 +30,6 @@
- #include <time.h>
- #include <rpc/rpc.h>
- #include <sys/socket.h>
--#include <rpcsvc/rusers.h>
- #include <utmp.h>
- #include <sys/time.h>
- #include <netdb.h>
-diff --git a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_create/rpc_clntudp_create_stress.c b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_create/rpc_clntudp_create_stress.c
-index ca38aa0..974f5fb 100644
---- a/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_create/rpc_clntudp_create_stress.c
-+++ b/testcases/network/rpc/rpc-tirpc/tests_pack/rpc_suite/rpc/rpc_createdestroy_clntudp_create/rpc_clntudp_create_stress.c
-@@ -30,7 +30,6 @@
- #include <time.h>
- #include <rpc/rpc.h>
- #include <sys/socket.h>
--#include <rpcsvc/rusers.h>
- #include <utmp.h>
- #include <sys/time.h>
- #include <netdb.h>
---
-2.7.4
-
diff --git a/package/ltp-testsuite/ltp-testsuite.hash b/package/ltp-testsuite/ltp-testsuite.hash
index b8311e094..68b95234d 100644
--- a/package/ltp-testsuite/ltp-testsuite.hash
+++ b/package/ltp-testsuite/ltp-testsuite.hash
@@ -1,2 +1,2 @@
-# From: https://github.com/linux-test-project/ltp/releases/download/20170116/ltp-full-20170116.tar.xz.sha1
-sha1 b42047fe0d30db9b2c760bd1ab901ecb133835fc ltp-full-20170116.tar.xz
+# From: https://github.com/linux-test-project/ltp/releases/download/20170516/ltp-full-20170516.tar.xz.sha1
+sha1 bd5210b73b14708c88449089a3a3c64ace3cd22a ltp-full-20170516.tar.xz
diff --git a/package/ltp-testsuite/ltp-testsuite.mk b/package/ltp-testsuite/ltp-testsuite.mk
index 7f26bd2a5..1790309f8 100644
--- a/package/ltp-testsuite/ltp-testsuite.mk
+++ b/package/ltp-testsuite/ltp-testsuite.mk
@@ -4,7 +4,7 @@
#
################################################################################
-LTP_TESTSUITE_VERSION = 20170116
+LTP_TESTSUITE_VERSION = 20170516
LTP_TESTSUITE_SOURCE = ltp-full-$(LTP_TESTSUITE_VERSION).tar.xz
LTP_TESTSUITE_SITE = https://github.com/linux-test-project/ltp/releases/download/$(LTP_TESTSUITE_VERSION)
LTP_TESTSUITE_LICENSE = GPL-2.0, GPL-2.0+
--
2.12.2
^ permalink raw reply related
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-17
From: Thomas Petazzoni @ 2017-05-18 6:31 UTC (permalink / raw)
To: buildroot
Hello,
Build statistics for 2017-05-17
================================
successes : 206
failures : 8
timeouts : 0
TOTAL : 214
Classification of failures by reason
====================================
modem-manager-1.6.4 | 2
icu-58.2 | 1
libepoxy-1.4.1 | 1
mpv-0.25.0 | 1
pulseview-0.3.0 | 1
rabbitmq-c-v0.8.0 | 1
unknown | 1
Detail of failures
===================
bfin | icu-58.2 | NOK | http://autobuild.buildroot.net/results/4828d9fc18283bda4c07af2c67f8ca9490dca28d | ORPH
mips64el | libepoxy-1.4.1 | NOK | http://autobuild.buildroot.net/results/c29d2ffffe960c5d3e565ff00706ca6fd7622f1d |
xtensa | modem-manager-1.6.4 | NOK | http://autobuild.buildroot.net/results/94c111c8014aa98998efa0af2ed726002b7fdca6 |
microblazeel | modem-manager-1.6.4 | NOK | http://autobuild.buildroot.net/results/fb7f7cb3bd903d90c9d9bd97a49acbfb6d137f29 |
arm | mpv-0.25.0 | NOK | http://autobuild.buildroot.net/results/501101000e36ea17deab198b12f9f611641f43fd |
x86_64 | pulseview-0.3.0 | NOK | http://autobuild.buildroot.net/results/8dbaaca8d894bb335bc876a9f36a874364dd34f4 |
arm | rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/3e15dad9ee4803cf465277b999dca69318fda09d |
powerpc | unknown | NOK | http://autobuild.buildroot.net/results/ea140fa600616f20e282902f25899f600741b123 |
--
http://autobuild.buildroot.net
^ permalink raw reply
* [Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict
From: Baruch Siach @ 2017-05-18 4:57 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20170517153353.0bd784c9@free-electrons.com>
Hi Thomas,
On Wed, May 17, 2017 at 03:33:53PM +0200, Thomas Petazzoni wrote:
> 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 ?
I have not tested kernel headers earlier than v3.12. Having a look at the
headers and the log of kernel commit cfd280c91253cc28 (net: sync some IP
headers with glibc), I'm pretty sure that the same issue also affects older
kernels.
Should we just disallow build of musl toolchain with older kernels? Something
like:
diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
index 91cddc237429..396f6d8ec2a5 100644
--- a/toolchain/toolchain-buildroot/Config.in
+++ b/toolchain/toolchain-buildroot/Config.in
@@ -74,6 +74,8 @@ config BR2_TOOLCHAIN_BUILDROOT_MUSL
# sh2 nommu is supported by musl, but we don't have support
# for it in Buildroot.
depends on BR2_USE_MMU
+ # We need the kernel libc-compat.h header
+ depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12
select BR2_TOOLCHAIN_USES_MUSL
help
This option selects musl as the C library for the
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply related
* [Buildroot] [PATCH 2/2 v2] package/qt5base: link with -latomic for sparc
From: Baruch Siach @ 2017-05-18 3:34 UTC (permalink / raw)
To: buildroot
In-Reply-To: <6bdfcdff79478a9835c4c5d0296f8f62d5b64d66.1495055675.git.yann.morin.1998@free.fr>
Hi Yann,
On Wed, May 17, 2017 at 11:15:29PM +0200, Yann E. MORIN wrote:
> Qt 5.8 needs atomic operations, which are provided in libatomic when it
> exists, ike on sparc with gcc >= 4.8.
>
> Fixes:
> http://autobuild.buildroot.org/results/49b/49bc9345b9849c9c3c53ace290c534ff7bb98683/
> http://autobuild.buildroot.org/results/9f2/9f213406954be51dfcad76ebdce8b73850842180/
>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Julien Corjon <corjon.j@ecagroup.com>
> Cc: Peter Seiderer <ps.report@gmx.net>
>
> ---
> Changes v1 -> v2:
> - condition is on HAS_LIBATOMIC, not on BR2_sparc (Thomas)
The commit subject line should also to match that change.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [Buildroot] [PATCH 1/1] package/avrdude: fix gpio definition, add kconfig option
From: Matthew Weber @ 2017-05-18 3:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20170518032306.mbvzslnrmtrh45it@tarshish>
Baruch,
On May 17, 2017 10:23 PM, "Baruch Siach" <baruch@tkos.co.il> wrote:
Hi Matt, Sam,
On Wed, May 17, 2017 at 05:58:54PM -0500, Matt Weber wrote:
> +if BR2_PACKAGE_AVRDUDE
> +
> +config BR2_PACKAGE_AVRDUDE_LINUXGPIO
> + bool "linux gpio"
> + depends on BR2_PACKAGE_AVRDUDE
> + help
> + Enables the tool to use the Linux Sysfs based GPIO framework for
GPIO
> + access by configuring AVRDude with '--enable-linuxgpio'.
> +endif
How big is the size impact of enabling this option? If it is relatively
small,
enabling gpio support unconditionally would be better, I think.
Agreed, the only reason we made it optional was compatibility, as currently
it's disabled.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170517/a0f23692/attachment.html>
^ permalink raw reply
* [Buildroot] [PATCH 1/1] package/avrdude: fix gpio definition, add kconfig option
From: Baruch Siach @ 2017-05-18 3:23 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1495061934-57465-1-git-send-email-matthew.weber@rockwellcollins.com>
Hi Matt, Sam,
On Wed, May 17, 2017 at 05:58:54PM -0500, Matt Weber wrote:
> +if BR2_PACKAGE_AVRDUDE
> +
> +config BR2_PACKAGE_AVRDUDE_LINUXGPIO
> + bool "linux gpio"
> + depends on BR2_PACKAGE_AVRDUDE
> + help
> + Enables the tool to use the Linux Sysfs based GPIO framework for GPIO
> + access by configuring AVRDude with '--enable-linuxgpio'.
> +endif
How big is the size impact of enabling this option? If it is relatively small,
enabling gpio support unconditionally would be better, I think.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [Buildroot] [PATCH 1/1] package/avrdude: fix gpio definition, add kconfig option
From: Matt Weber @ 2017-05-17 22:58 UTC (permalink / raw)
To: buildroot
From: Sam Voss <samuel.voss@rockwellcollins.com>
Fix bug causing '--enable-linuxgpio' to not work
due to a misnamed definition. This patch has been
submitted upstream at https://github.com/kcuzner/avrdude/pull/15.
Add the option to enable linux gpio configure option
in menuconfig.
Signed-off-by: Sam Voss <samuel.voss@rockwellcollins.com>
Signed-off-by: Matt Weber <matthew.weber@rockwellcollins.com>
---
.../0001-Avrdude-Fix-HAVE_LINUX_GPIO-def.patch | 29 ++++++++++++++++++++++
package/avrdude/Config.in | 10 ++++++++
package/avrdude/avrdude.mk | 6 +++++
3 files changed, 45 insertions(+)
create mode 100644 package/avrdude/0001-Avrdude-Fix-HAVE_LINUX_GPIO-def.patch
diff --git a/package/avrdude/0001-Avrdude-Fix-HAVE_LINUX_GPIO-def.patch b/package/avrdude/0001-Avrdude-Fix-HAVE_LINUX_GPIO-def.patch
new file mode 100644
index 0000000..6ed6ea8
--- /dev/null
+++ b/package/avrdude/0001-Avrdude-Fix-HAVE_LINUX_GPIO-def.patch
@@ -0,0 +1,29 @@
+From edeab3f6b5295fa795aa6f841d30831729a181d8 Mon Sep 17 00:00:00 2001
+From: Sam Voss <samuel.voss@rockwellcollins.com>
+Date: Fri, 17 Mar 2017 09:36:53 -0500
+Subject: [PATCH 1/1] Avrdude: Fix HAVE_LINUX_GPIO def
+
+This patch has been submitted upstream at
+ https://github.com/kcuzner/avrdude/pull/15.
+
+Signed-off-by: Sam Voss <samuel.voss@rockwellcollins.com>
+---
+ avrdude/pindefs.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/avrdude/pindefs.h b/avrdude/pindefs.h
+index c060708..a227b68 100644
+--- a/avrdude/pindefs.h
++++ b/avrdude/pindefs.h
+@@ -59,7 +59,7 @@ enum {
+ #define PIN_MIN 0 /* smallest allowed pin number */
+ #define PIN_MAX 31 /* largest allowed pin number */
+
+-#ifdef HAVE_LINUX_GPIO
++#ifdef HAVE_LINUXGPIO
+ /* Embedded systems might have a lot more gpio than only 0-31 */
+ #undef PIN_MAX
+ #define PIN_MAX 255 /* largest allowed pin number */
+--
+1.9.1
+
diff --git a/package/avrdude/Config.in b/package/avrdude/Config.in
index 3757f17..4c51e8d 100644
--- a/package/avrdude/Config.in
+++ b/package/avrdude/Config.in
@@ -15,6 +15,16 @@ config BR2_PACKAGE_AVRDUDE
https://github.com/kcuzner/avrdude
+if BR2_PACKAGE_AVRDUDE
+
+config BR2_PACKAGE_AVRDUDE_LINUXGPIO
+ bool "linux gpio"
+ depends on BR2_PACKAGE_AVRDUDE
+ help
+ Enables the tool to use the Linux Sysfs based GPIO framework for GPIO
+ access by configuring AVRDude with '--enable-linuxgpio'.
+endif
+
comment "avrdude needs a uClibc or glibc toolchain w/ threads, wchar, dynamic library"
depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_USE_WCHAR || BR2_STATIC_LIBS \
|| !(BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_USES_GLIBC)
diff --git a/package/avrdude/avrdude.mk b/package/avrdude/avrdude.mk
index f914ed7..19ffdfa 100644
--- a/package/avrdude/avrdude.mk
+++ b/package/avrdude/avrdude.mk
@@ -23,6 +23,12 @@ else ifeq ($(BR2_PACKAGE_LIBFTDI),y)
AVRDUDE_DEPENDENCIES += libftdi
endif
+ifeq ($(BR2_PACKAGE_AVRDUDE_LINUXGPIO),y)
+AVRDUDE_CONF_OPTS = --enable-linuxgpio
+else
+AVRDUDE_CONF_OPTS = --disable-linuxgpio
+endif
+
# if /etc/avrdude.conf exists, the installation process creates a
# backup file, which we do not want in the context of Buildroot.
define AVRDUDE_REMOVE_BACKUP_FILE
--
1.9.1
^ permalink raw reply related
* [Buildroot] Analysis of build results for 2017-05-16
From: Thomas Petazzoni @ 2017-05-17 21:59 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20170517212023.478bd24a@free-electrons.com>
Hello,
On Wed, 17 May 2017 21:20:23 +0200, Thomas Petazzoni wrote:
> > 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
Couldn't reproduce so far. I've started a rebuild of a failed
configuration.
> > 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'
Fixed proposed at: https://patchwork.ozlabs.org/patch/763789/.
> > sh4 | libepoxy-1.4.1 | NOK | http://autobuild.buildroot.net/results/38701cee74110de90cd72f720b3ee8bd69666325 |
>
> The EGL issue, I will send a patch.
I've worked on the patch tonight, I've started some builds to verify it
works fine in all situations.
> > 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.
Still needs investigation.
> > 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.
Committed:
https://git.buildroot.org/buildroot/commit/?id=2677210f545c3f3e8c52c973e08c3a460c521e5b.
> > 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.
Fixed by
https://git.buildroot.org/buildroot/commit/?id=7fde83cdf0da338937dae13144eea2923e5c2730
>
> > 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.
Fixed by
https://git.buildroot.org/buildroot/commit/?id=19e78e509e5e729437d2188b28aee7655340c67d.
Summary, on 10 failures:
- 2 remains to be investigated (cmake and libmemcached)
- 6 have already been fixed
- 2 have patches
Good night!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH] cppcms: fix build on machines with libgpg-error installed
From: Thomas Petazzoni @ 2017-05-17 21:53 UTC (permalink / raw)
To: buildroot
In configuration where target architecture == host architecture, and
libgpg-error is installed system-wide with development files, the build
of cppcms fails with:
/home/test/buildroot/output/host/usr/bin/x86_64-amd-linux-gnu-g++ --sysroot=/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -Wall -Wextra -DNDEBUG CMakeFiles/base64_test.dir/tests/base64_test.cpp.o -o base64_test -L/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib -Wl,-rpath,/home/test/buildroot/output/build/cppcms-1.0.5:/home/test/buildroot/output/build/cppcms-1.0.5/booster:/usr/lib -rdynamic libcppcms.so.1.0.5 booster/libbooster.so.0.0.3 -lpthread /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libpcre.so /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libdl.so /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libz.so
/home/test/buildroot/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/buildroot/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/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpgrt_lock_destroy at GPG_ERROR_1.0'
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_err_code_from_syserror at GPG_ERROR_1.0'
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_err_code_from_errno at GPG_ERROR_1.0'
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpgrt_lock_unlock at GPG_ERROR_1.0'
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_strerror at GPG_ERROR_1.0'
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_strsource at GPG_ERROR_1.0'
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpgrt_lock_lock at GPG_ERROR_1.0'
The problem comes from the
"-Wl,-rpath,/home/test/buildroot/output/build/cppcms-1.0.5:/home/test/buildroot/output/build/cppcms-1.0.5/booster:/usr/lib"
option, which tells the linker to search for libraries in /usr/lib.
This commit fixes that by asking CMake to not add any rpath when
building cppcms.
Fixes:
http://autobuild.buildroot.net/results/a7eb1ede552ae14f409cfd7bd877bcf25ca69a74/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/cppcms/cppcms.mk | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/package/cppcms/cppcms.mk b/package/cppcms/cppcms.mk
index 1f6c09d..9d05e81 100644
--- a/package/cppcms/cppcms.mk
+++ b/package/cppcms/cppcms.mk
@@ -11,6 +11,10 @@ CPPCMS_LICENSE_FILES = COPYING.TXT
CPPCMS_SITE = http://downloads.sourceforge.net/project/cppcms/cppcms/$(CPPCMS_VERSION)
CPPCMS_INSTALL_STAGING = YES
+# disable rpath to avoid getting /usr/lib added to the link search
+# path
+CPPCMS_CONF_OPTS = -DCMAKE_SKIP_RPATH=ON
+
CPPCMS_DEPENDENCIES = zlib pcre libgcrypt
ifeq ($(BR2_PACKAGE_CPPCMS_ICU),y)
--
2.7.4
^ permalink raw reply related
* [Buildroot] [PATCH 2/2 v2] package/qt5base: link with -latomic for sparc
From: Yann E. MORIN @ 2017-05-17 21:15 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1495055675.git.yann.morin.1998@free.fr>
Qt 5.8 needs atomic operations, which are provided in libatomic when it
exists, ike on sparc with gcc >= 4.8.
Fixes:
http://autobuild.buildroot.org/results/49b/49bc9345b9849c9c3c53ace290c534ff7bb98683/
http://autobuild.buildroot.org/results/9f2/9f213406954be51dfcad76ebdce8b73850842180/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Julien Corjon <corjon.j@ecagroup.com>
Cc: Peter Seiderer <ps.report@gmx.net>
---
Changes v1 -> v2:
- condition is on HAS_LIBATOMIC, not on BR2_sparc (Thomas)
---
package/qt5/qt5base/qt5base.mk | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/package/qt5/qt5base/qt5base.mk b/package/qt5/qt5base/qt5base.mk
index 81774b74a6..5944c869bb 100644
--- a/package/qt5/qt5base/qt5base.mk
+++ b/package/qt5/qt5base/qt5base.mk
@@ -215,6 +215,13 @@ endef
endif
QT5BASE_ARCH_CONFIG_FILE = $(@D)/mkspecs/devices/linux-buildroot-g++/arch.conf
+ifeq ($(BR2_TOOLCHAIN_HAS_LIBATOMIC)$(BR2_PACKAGE_QT5_VERSION_LATEST),yy)
+# Qt 5.8 needs atomics, which on sparc are in -latomic
+define QT5BASE_CONFIGURE_ARCH_CONFIG
+ printf 'LIBS += -latomic\n' >$(QT5BASE_ARCH_CONFIG_FILE)
+endef
+endif
+
define QT5BASE_CONFIGURE_CMDS
$(INSTALL) -m 0644 -D $(QT5BASE_PKGDIR)/qmake.conf \
$(@D)/mkspecs/devices/linux-buildroot-g++/qmake.conf
--
2.11.0
^ permalink raw reply related
* [Buildroot] [PATCH 1/2 v2] package/qt5base: install arch-specific configuration
From: Yann E. MORIN @ 2017-05-17 21:15 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1495055675.git.yann.morin.1998@free.fr>
For some architectures, it is necessary to link with additional
libraries, such as -latomic for sparc.
Add a bit of support to make that easy; actual use will be introduced in
the following patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Julien Corjon <corjon.j@ecagroup.com>
Cc: Peter Seiderer <ps.report@gmx.net>
---
Changes v1 -> v2:
- rename macro
---
package/qt5/qt5base/qmake.conf | 3 +++
package/qt5/qt5base/qt5base.mk | 3 +++
2 files changed, 6 insertions(+)
diff --git a/package/qt5/qt5base/qmake.conf b/package/qt5/qt5base/qmake.conf
index 49cf898316..8b6debe583 100644
--- a/package/qt5/qt5base/qmake.conf
+++ b/package/qt5/qt5base/qmake.conf
@@ -21,5 +21,8 @@ CONFIG += nostrip
QMAKE_LIBS += -lrt -lpthread -ldl
QMAKE_CFLAGS_ISYSTEM =
+# Architecturespecific configuration
+include(arch.conf)
+
include(../common/linux_device_post.conf)
load(qt_config)
diff --git a/package/qt5/qt5base/qt5base.mk b/package/qt5/qt5base/qt5base.mk
index 0c088350e5..81774b74a6 100644
--- a/package/qt5/qt5base/qt5base.mk
+++ b/package/qt5/qt5base/qt5base.mk
@@ -214,12 +214,15 @@ define QT5BASE_CONFIGURE_CONFIG_FILE
endef
endif
+QT5BASE_ARCH_CONFIG_FILE = $(@D)/mkspecs/devices/linux-buildroot-g++/arch.conf
define QT5BASE_CONFIGURE_CMDS
$(INSTALL) -m 0644 -D $(QT5BASE_PKGDIR)/qmake.conf \
$(@D)/mkspecs/devices/linux-buildroot-g++/qmake.conf
$(INSTALL) -m 0644 -D $(QT5BASE_PKGDIR)/qplatformdefs.h \
$(@D)/mkspecs/devices/linux-buildroot-g++/qplatformdefs.h
$(QT5BASE_CONFIGURE_CONFIG_FILE)
+ touch $(QT5BASE_ARCH_CONFIG_FILE)
+ $(QT5BASE_CONFIGURE_ARCH_CONFIG)
(cd $(@D); \
$(TARGET_MAKE_ENV) \
PKG_CONFIG="$(PKG_CONFIG_HOST_BINARY)" \
--
2.11.0
^ permalink raw reply related
* [Buildroot] [PATCH 0/2 v2] package/qt5base: fix sparc compilation
From: Yann E. MORIN @ 2017-05-17 21:15 UTC (permalink / raw)
To: buildroot
Hello All!
This small series aims at fixing the build of qt-5.8 on sparc.
Qt 5.8 needs atomic operations, which on some architectures are compiler
builtins, while on other archs they are provided by a helper library,
libatomic. For sparc, atomics are in libatomic.
First, we introduce a new qmake config snippet, arch.conf, which is
included from our qmake.conf.
By default, that file is empty, except when libatomic is present in the
toolchain, in which case it add -latomic to the list of libraries to
link with.
Regards,
Yann E. MORIN.
The following changes since commit 19e78e509e5e729437d2188b28aee7655340c67d
oracle-mysql: add patch to fix gcc 6.x build issue (2017-05-17 22:24:14 +0200)
are available in the git repository at:
git://git.buildroot.org/~ymorin/git/buildroot.git
for you to fetch changes up to 6bdfcdff79478a9835c4c5d0296f8f62d5b64d66
package/qt5base: link with -latomic for sparc (2017-05-17 23:08:55 +0200)
----------------------------------------------------------------
Yann E. MORIN (2):
package/qt5base: install arch-specific configuration
package/qt5base: link with -latomic for sparc
package/qt5/qt5base/qmake.conf | 3 +++
package/qt5/qt5base/qt5base.mk | 10 ++++++++++
2 files changed, 13 insertions(+)
--
.-----------------.--------------------.------------------.--------------------.
| 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] RPi B+ update
From: Marco Trapanese @ 2017-05-17 20:49 UTC (permalink / raw)
To: buildroot
In-Reply-To: <2C134724-B0DB-4EAB-907E-3C97364972DC@openadk.org>
Il 17/05/2017 19:36, Waldemar Brodkorb ha scritto:
> 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.
Il 17/05/2017 21:29, Peter Korsgaard ha scritto:
>
> Unless the system boots with new fw and the old zImage. Did you try that
> combination?
Hi both!
I've just tried to boot with the old zImage and the new firmware: it
hangs on the colored background on power up. The same happens using
mkknlimg on the old kernel.
Marco
^ permalink raw reply
* [Buildroot] [PATCH] fbgrab: explicitly build fbgrab target to workaround gzip issue
From: Peter Korsgaard @ 2017-05-17 20:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20170517145251.9047-1-peter@korsgaard.com>
>>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:
> 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>
Committed to 2017.02.x, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox