Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH v4 1/2] rhash: new package
From: Vicente Olivert Riera @ 2017-05-09  9:28 UTC (permalink / raw)
  To: buildroot

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
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   | 73 ++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 101 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 d57813c..9b64ce2 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 0000000..6581243
--- /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 0000000..5efc3a6
--- /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 0000000..aa1a28d
--- /dev/null
+++ b/package/rhash/rhash.mk
@@ -0,0 +1,73 @@
+################################################################################
+#
+# 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)
+# We also install the rhash console utility to the staging directory
+# since we want it to be a superset of the target directory.
+define RHASH_INSTALL_STAGING_RHASH_BIN
+	$(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D) \
+		DESTDIR="$(STAGING_DIR)" $(RHASH_MAKE_OPTS) install-shared
+endef
+RHASH_POST_INSTALL_STAGING_HOOKS += RHASH_INSTALL_STAGING_RHASH_BIN
+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.10.2

^ permalink raw reply related

* [Buildroot] Analysis of build results for 2017-05-08
From: Yegor Yefremov @ 2017-05-09  9:20 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170509093537.5560182b@free-electrons.com>

On Tue, May 9, 2017 at 9:35 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> Alexey, Yegor, Bernd, Yann, Vicente, Fabrice, Frank, Floris, Peter,
> J?r?me, there are some questions/issues for you below :-)
>
> On Tue,  9 May 2017 08:28:24 +0200 (CEST), Thomas Petazzoni wrote:
>
>> Build statistics for 2017-05-08
>> ================================
>>
>>       successes : 217
>>        failures : 23
>
> We're doing quite well for a beginning of the debugging cycle, so it'd
> be great to reduce even further the number of build failures. Let's
> analyze a few of them.
>
> On 23 issues:
>
>    13 issues that have no solution yet
>    10 issues that have a solution committed, or close to be committed
>
>>       xtensa |                   boost-1.63.0 | NOK | http://autobuild.buildroot.net/results/436f6173bb29a945abc75899a6b74e1266362fc9 |
>
> error: Name clash for '<pstage/lib>libboost_system.a'
>
> Yegor, you are in the DEVELOPERS file for Boost, could you have a look ?

OMG I'm the only one registered as DEVELOPER for boost.

This situation seems to occur, when both iconv and icu are selected:

    - iconv (libc)             : yes
    - icu                      : yes

Need to dig further.

Yegor

^ permalink raw reply

* [Buildroot] [uclibc-ng-devel] Conflict between uClibc-ng if_arp.h and kernel headers since Linux 4.11 ?
From: Waldemar Brodkorb @ 2017-05-09  9:13 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170504233931.450f0a40@free-electrons.com>

Hi,

> Am 04.05.2017 um 23:39 schrieb Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> 
> Hello,
> 
> Since a few days, we are seeing build failures of the radvd package in
> Buildroot:
> 
>  http://autobuild.buildroot.net/?reason=radvd-2.12
> 
> The build failure is:
> 
> /home/buildroot/autobuild/run/instance-2/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/include/linux/if_arp.h:121:8: error: redefinition of 'struct arpreq_old'
> struct arpreq_old {
>        ^~~~~~~~~~
> In file included from includes.h:90:0,
>                 from recv.c:17:
> /home/buildroot/autobuild/run/instance-2/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/include/net/if_arp.h:147:8: note: originally defined here
> struct arpreq_old
>        ^~~~~~~~~~
> [...]
> 
> The build failures happens with uClibc-ng toolchains in combination
> with Linux 4.11 kernel headers, so it seems to be a new thing caused by
> Linux 4.11 headers. However the kernel Git history doesn't show any
> change on this header file between 4.10 and 4.11.
> 
> Any idea?

Not, yet. I am still investigating. May be something with the libc-compat.h mechanism inside the kernel changed. I can reproduce the issue, but had no time yet to bisect the kernel to find the commit which breaks radvd compile.

best regards
 Waldemar 

^ permalink raw reply

* [Buildroot] [PATCH] lua: use target LDFLAGS
From: François Perrad @ 2017-05-09  8:32 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <6d72098cd529e9364107dd2727d22eda57635c80.1494253706.git.baruch@tkos.co.il>

2017-05-08 16:28 GMT+02:00 Baruch Siach <baruch@tkos.co.il>:
> This adds '-static' to the link command when BR2_STATIC_LIBS=y, making the lua
> binary really static.
>
> Cc: Francois Perrad <francois.perrad@gadz.org>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>

Acked-by: Francois Perrad <francois.perrad@gadz.org>

> ---
>  package/lua/lua.mk | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/package/lua/lua.mk b/package/lua/lua.mk
> index 5ef61e039e36..bc0a9d456b9c 100644
> --- a/package/lua/lua.mk
> +++ b/package/lua/lua.mk
> @@ -70,6 +70,7 @@ define LUA_BUILD_CMDS
>         CC="$(TARGET_CC)" RANLIB="$(TARGET_RANLIB)" \
>         CFLAGS="$(TARGET_CFLAGS) $(LUA_CFLAGS)" \
>         MYLIBS="$(LUA_MYLIBS)" AR="$(TARGET_CROSS)ar rcu" \
> +       MYLDFLAGS="$(TARGET_LDFLAGS)" \
>         BUILDMODE=$(LUA_BUILDMODE) \
>         PKG_VERSION=$(LUA_VERSION) -C $(@D)/src all
>  endef
> --
> 2.11.0
>

^ permalink raw reply

* [Buildroot] Analysis of build results for 2017-05-08
From: Thomas Petazzoni @ 2017-05-09  7:35 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170509062824.6D04D208E1@mail.free-electrons.com>

Hello,

Alexey, Yegor, Bernd, Yann, Vicente, Fabrice, Frank, Floris, Peter,
J?r?me, there are some questions/issues for you below :-)

On Tue,  9 May 2017 08:28:24 +0200 (CEST), Thomas Petazzoni wrote:

> Build statistics for 2017-05-08
> ================================
> 
>       successes : 217
>        failures : 23 

We're doing quite well for a beginning of the debugging cycle, so it'd
be great to reduce even further the number of build failures. Let's
analyze a few of them.

On 23 issues:

   13 issues that have no solution yet
   10 issues that have a solution committed, or close to be committed

>       xtensa |                   boost-1.63.0 | NOK | http://autobuild.buildroot.net/results/436f6173bb29a945abc75899a6b74e1266362fc9 |     

error: Name clash for '<pstage/lib>libboost_system.a'

Yegor, you are in the DEVELOPERS file for Boost, could you have a look ?

>    powerpc64 |                   daemon-0.6.4 | NOK | http://autobuild.buildroot.net/results/ed21ac166f2151aa69a7790a17ff05f05afa512d |     

Would be fixed by https://patchwork.ozlabs.org/patch/759742/.

>          arc |                   libcdio-0.94 | NOK | http://autobuild.buildroot.net/results/17baccfb72de050aee9bc8ba2b46442afe45292d |     
>          arc |                   libcdio-0.94 | NOK | http://autobuild.buildroot.net/results/8f8ad583f03edb6294dce3cf6de51391320bbafc |     
>          arc |                   libcdio-0.94 | NOK | http://autobuild.buildroot.net/results/a262cc45114cc3ddf51cb9db5ab35971bf32b8cb |     

ARC toolchain issue. Alexey, could you have a look ?

>      powerpc |                 libepoxy-1.4.1 | NOK | http://autobuild.buildroot.net/results/88774af2845e17cab021a72c8f3171fe30b3a1ff |     
>     mips64el |                 libepoxy-1.4.1 | NOK | http://autobuild.buildroot.net/results/6912abef6ebb03f9ac4888967b522ab707a51319 |     

I have submitted a patch upstream for this issue, I will submit it to
Buildroot hopefully today.

>        sparc |         ltp-testsuite-20170116 | NOK | http://autobuild.buildroot.net/results/d7c3b145a64ed3916b89ddb4090050f3b9205e37 |     

It's being handled by Romain. He has sent a v2, but it still has some
issues, I guess Romain will send another version soon.

>     mips64el |                     mpir-3.0.0 | NOK | http://autobuild.buildroot.net/results/4f62a79e7567c6f7a61373e3095f771ff12a57ef |     
>  powerpc64le |                     mpir-3.0.0 | NOK | http://autobuild.buildroot.net/results/17e523be894b60d7a9b2a3303f02c3fb34816828 |     
>     mips64el |                     mpir-3.0.0 | NOK | http://autobuild.buildroot.net/results/9c90ffcb15a6bcddcafb6288ba742177392ddaa1 |     

Would be all fixed by my series on mpir.

>         i686 |                  mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/8a068af584a52cb48375da851e8d7ddb9ee9b646 |     

libavcodec/x86/ac3dsp_init.c: In function 'ac3_downmix_sse':
libavcodec/x86/ac3dsp_init.c:161:9: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
libavcodec/x86/ac3dsp_init.c:165:9: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
libavcodec/x86/ac3dsp_init.c:161:9: error: 'asm' operand has impossible constraints

Bernd ?

>         mips |                  mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/863e56002599e51e8e9cd7459ddb8931d1055ae8 |     

libpostproc/postprocess.c:94:53: error: expected ',' or ';' before 'FFMPEG_VERSION'
 const char postproc_ffversion[] = "FFmpeg version " FFMPEG_VERSION;

Bernd ? :-)

>         i686 |                     mpv-0.25.0 | NOK | http://autobuild.buildroot.net/results/ac72a2a47705cf527684e15c95c97504ac17349c |     
>          arm |                     mpv-0.25.0 | NOK | http://autobuild.buildroot.net/results/faf374b70436257d70131e42592e333c00cd982a |     
>          sh4 |                     mpv-0.25.0 | NOK | http://autobuild.buildroot.net/results/eef0e90a270838a0792142b94212e1dbd0781314 |     

All fixed by
https://git.buildroot.org/buildroot/commit/?id=4b72b54fd3b0074864e5ad36ec2fdcd30f4d58eb

>     mips64el |                      nut-2.7.4 | NOK | http://autobuild.buildroot.net/results/63a83af7cdc1db88397ac5a40b25bf787c50955d |     

scan_usb.c:37:29: error: unknown type name 'usb_dev_handle'
(and more USB related errors)

Yann, you are listed in the DEVELOPERS file for "nut". Could you have a
look ?

>       mipsel |                      php-7.1.4 | NOK | http://autobuild.buildroot.net/results/0ff0866a6c8be7dfeea099de0c5c514afac5572f | ORPH

checking for SQLBindCol in -lodbc... no
configure: error: Your ODBC library does not exist or there was an error. Check config.log for more information

In config.log:

/home/test/autobuild/run/instance-0/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libodbc.a(SQLCreateDataSource.o): In function `SQLCreateDataSource.part.0':
SQLCreateDataSource.c:(.text+0x54): undefined reference to `lt_dlopen'
SQLCreateDataSource.c:(.text+0x58): undefined reference to `lt_dlopen'
SQLCreateDataSource.c:(.text+0x68): undefined reference to `lt_dlsym'
SQLCreateDataSource.c:(.text+0x74): undefined reference to `lt_dlsym'

It's a static linking issue.

Vicente, Fabrice, Frank, Floris, over the last months, you have
contributed changes on the PHP package. Would you be willing to adopt
it (i.e being listed in the DEVELOPERS file) ?

>          arm |                 poppler-0.54.0 | NOK | http://autobuild.buildroot.net/results/d7216e2c14c24ed5a0129b7729aae3ae584b44db |     

  CXXLD    libpoppler-qt4.la
../../libtool: line 7489: cd: usr/lib: No such file or directory
libtool:   error: cannot determine absolute directory name of 'usr/lib'

Peter (Seiderer), another Poppler/Qt issue it seems.

>        sparc |                 protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/16640aa938dc3907bc04bb80ee1fb0d54a9460c0 | ORPH

./.libs/libprotobuf.so: undefined reference to `__atomic_fetch_add_4'
./.libs/libprotobuf.so: undefined reference to `__atomic_compare_exchange_4'

We need to link against libatomic.

>          arc |                     radvd-2.12 | NOK | http://autobuild.buildroot.net/results/878fb42a19aa56a128fa73b7bed39aad57241107 | ORPH

Conflict between <net/if_arp.h> and <linux/if_arp.h>.

>       x86_64 |               strongswan-5.4.0 | NOK | http://autobuild.buildroot.net/results/ba1298e71ef28857654ae8d4593d09e4fe8cdda0 |     

af_alg_ops.c:110:22: error: conflicting types for 'crypt'
 METHOD(af_alg_ops_t, crypt, bool,

J?r?me, you are looking after strongswan. Could you have a look ?

>         or1k |                    zmqpp-4.1.2 | NOK | http://autobuild.buildroot.net/results/bdca3f0e11cd9f6dbb68e84a8cc3ff1ea8dd799f |     

src/client/options.cpp: In function 'client_options process_command_line(int, const char**)':
src/client/options.cpp:139:1: internal compiler error: in merge_overlapping_regs, at regrename.c:304

Compiler bug. We should try without optimizations, and see if gcc 6.x
has the issue or not.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [PATCH] .gitignore: add vim temporary files
From: Baruch Siach @ 2017-05-09  6:57 UTC (permalink / raw)
  To: buildroot

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index bb02d9f57270..393eae97135d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,4 +12,5 @@
 *.orig
 *.rej
 *~
+.*.swp
 *.pyc
-- 
2.11.0

^ permalink raw reply related

* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-08
From: Thomas Petazzoni @ 2017-05-09  6:28 UTC (permalink / raw)
  To: buildroot

Hello,

Build statistics for 2017-05-08
================================

      successes : 217
       failures : 23 
       timeouts : 0  
          TOTAL : 240

Classification of failures by reason
====================================

                  libcdio-0.94 | 3 
                    mpir-3.0.0 | 3 
                    mpv-0.25.0 | 3 
                libepoxy-1.4.1 | 2 
                 mplayer-1.3.0 | 2 
                  boost-1.63.0 | 1 
                  daemon-0.6.4 | 1 
        ltp-testsuite-20170116 | 1 
                     nut-2.7.4 | 1 
                     php-7.1.4 | 1 
                poppler-0.54.0 | 1 
                protobuf-3.2.0 | 1 
                    radvd-2.12 | 1 
              strongswan-5.4.0 | 1 
                   zmqpp-4.1.2 | 1 


Detail of failures
===================

      xtensa |                   boost-1.63.0 | NOK | http://autobuild.buildroot.net/results/436f6173bb29a945abc75899a6b74e1266362fc9 |     
   powerpc64 |                   daemon-0.6.4 | NOK | http://autobuild.buildroot.net/results/ed21ac166f2151aa69a7790a17ff05f05afa512d |     
         arc |                   libcdio-0.94 | NOK | http://autobuild.buildroot.net/results/17baccfb72de050aee9bc8ba2b46442afe45292d |     
         arc |                   libcdio-0.94 | NOK | http://autobuild.buildroot.net/results/8f8ad583f03edb6294dce3cf6de51391320bbafc |     
         arc |                   libcdio-0.94 | NOK | http://autobuild.buildroot.net/results/a262cc45114cc3ddf51cb9db5ab35971bf32b8cb |     
     powerpc |                 libepoxy-1.4.1 | NOK | http://autobuild.buildroot.net/results/88774af2845e17cab021a72c8f3171fe30b3a1ff |     
    mips64el |                 libepoxy-1.4.1 | NOK | http://autobuild.buildroot.net/results/6912abef6ebb03f9ac4888967b522ab707a51319 |     
       sparc |         ltp-testsuite-20170116 | NOK | http://autobuild.buildroot.net/results/d7c3b145a64ed3916b89ddb4090050f3b9205e37 |     
    mips64el |                     mpir-3.0.0 | NOK | http://autobuild.buildroot.net/results/4f62a79e7567c6f7a61373e3095f771ff12a57ef |     
 powerpc64le |                     mpir-3.0.0 | NOK | http://autobuild.buildroot.net/results/17e523be894b60d7a9b2a3303f02c3fb34816828 |     
    mips64el |                     mpir-3.0.0 | NOK | http://autobuild.buildroot.net/results/9c90ffcb15a6bcddcafb6288ba742177392ddaa1 |     
        i686 |                  mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/8a068af584a52cb48375da851e8d7ddb9ee9b646 |     
        mips |                  mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/863e56002599e51e8e9cd7459ddb8931d1055ae8 |     
        i686 |                     mpv-0.25.0 | NOK | http://autobuild.buildroot.net/results/ac72a2a47705cf527684e15c95c97504ac17349c |     
         arm |                     mpv-0.25.0 | NOK | http://autobuild.buildroot.net/results/faf374b70436257d70131e42592e333c00cd982a |     
         sh4 |                     mpv-0.25.0 | NOK | http://autobuild.buildroot.net/results/eef0e90a270838a0792142b94212e1dbd0781314 |     
    mips64el |                      nut-2.7.4 | NOK | http://autobuild.buildroot.net/results/63a83af7cdc1db88397ac5a40b25bf787c50955d |     
      mipsel |                      php-7.1.4 | NOK | http://autobuild.buildroot.net/results/0ff0866a6c8be7dfeea099de0c5c514afac5572f | ORPH
         arm |                 poppler-0.54.0 | NOK | http://autobuild.buildroot.net/results/d7216e2c14c24ed5a0129b7729aae3ae584b44db |     
       sparc |                 protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/16640aa938dc3907bc04bb80ee1fb0d54a9460c0 | ORPH
         arc |                     radvd-2.12 | NOK | http://autobuild.buildroot.net/results/878fb42a19aa56a128fa73b7bed39aad57241107 | ORPH
      x86_64 |               strongswan-5.4.0 | NOK | http://autobuild.buildroot.net/results/ba1298e71ef28857654ae8d4593d09e4fe8cdda0 |     
        or1k |                    zmqpp-4.1.2 | NOK | http://autobuild.buildroot.net/results/bdca3f0e11cd9f6dbb68e84a8cc3ff1ea8dd799f |     

-- 
http://autobuild.buildroot.net

^ permalink raw reply

* [Buildroot] Analysis of build results for 2017-05-07
From: Bernd Kuhls @ 2017-05-09  5:24 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170508224233.7332472b@free-electrons.com>

Am Mon, 08 May 2017 22:42:33 +0200 schrieb Thomas Petazzoni:

>>         m68k |                     ffmpeg-3.3 | NOK |
>>         http://autobuild.buildroot.net/results/
dc5a042952c3f1f6a6fa06db0e7ac70f701c50dc
>>         |
> 
> undefined reference to `__sync_fetch_and_add_4'
> 
> We should add the appropriate BR2_TOOLCHAIN_* dependency.

Hi Thomas,

corresponding patches were discussed in the last weeks:

http://patchwork.ozlabs.org/patch/756664/
http://patchwork.ozlabs.org/patch/751131/

Regards, Bernd

^ permalink raw reply

* [Buildroot] [PATCH v2 2/2] package/ltp-testsuite: add dependency on BR2_TOOLCHAIN_HAS_SYNC_4
From: Thomas Petazzoni @ 2017-05-08 21:30 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170508211833.3462-2-romain.naour@gmail.com>

Hello,

On Mon,  8 May 2017 23:18:33 +0200, Romain Naour wrote:

>  comment "ltp-testsuite needs a glibc or uClibc toolchain w/ NPTL"
>  	depends on !BR2_nios2
> +	depends on !BR2_TOOLCHAIN_HAS_SYNC_4 && !BR2_arc && !BR2_i386 \
> +		&& !BR2_powerpc && !BR2_powerpc64 && !BR2_powerpc64le \
> +		&& !BR2_x86_64

Wrong. You want the dependencies on the Config.in comment in the same
direction as for the main symbol. Or better: introduce a
BR2_PACKAGE_LTP_TESTSUITE_ARCH_SUPPORTS.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [PATCH v2 1/2] package/ltp-testsuite: remove ldd commande test with static only build
From: Thomas Petazzoni @ 2017-05-08 21:29 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170508211833.3462-1-romain.naour@gmail.com>

Hello,

On Mon,  8 May 2017 23:18:32 +0200, Romain Naour wrote:
> ldd command build system try to build a shared library unconditionally:
> 
> arc-linux-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -matomic -Os -static \
> 	-I[...]/sysroot/usr/include/tirpc   -g -O2 -fno-strict-aliasing -pipe \
> 	-Wall -W -Wold-style-definition -shared -o lddfile1.obj.so lddfile1.o
> 
> Fixes:
> http://autobuild.buildroot.net/results/2ec/2eccf9f517ab15d8d459b06195423fdfe3fba9fa
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>

Typo in commit title: s/commande/command. No need to respin for this.

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [PATCH v2] package/efl: fix unmet dependencies
From: Yann E. MORIN @ 2017-05-08 21:29 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <bfcd0a55-957d-f5e8-922f-ede41dff9c47@gmail.com>

Romain, All,

On 2017-05-08 23:25 +0200, Romain Naour spake thusly:
> Le 08/05/2017 ? 23:11, Yann E. MORIN a ?crit :
[--SNIP--]
> > +		|| !BR2_PACKAGE_EFL_EEZE || !Br2_EMNABLE_LOCALE
> meh s/Br2/BR2/
> s/Br2_EMNABLE_LOCALE/BR2_ENABLE_LOCALE/

Yep, so I'll refrain from hacking anymore before I get some sleep...

Thanks! :-)

Regards,
Yann E. MORIN.

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

^ permalink raw reply

* [Buildroot] [PATCH v2] package/efl: fix unmet dependencies
From: Romain Naour @ 2017-05-08 21:25 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170508211149.1964-1-yann.morin.1998@free.fr>

Le 08/05/2017 ? 23:11, Yann E. MORIN a ?crit :
> EFL's elput selects libinput but forgot to propagate its dependencies.
> Which requires they be propagated further to a second sub-option, then
> to a third one.
> 
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Romain Naour <romain.naour@openwide.fr>
> 
> ---
> Changes v1 -> v2:
>   - porpagate dependency to comments as well  (Romain)
>   - fix commit log typoes  (Romain, me)
> ---
>  package/efl/Config.in | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/package/efl/Config.in b/package/efl/Config.in
> index 371ed3f0d4..7b29e57c0a 100644
> --- a/package/efl/Config.in
> +++ b/package/efl/Config.in
> @@ -178,13 +178,15 @@ config BR2_PACKAGE_EFL_WAYLAND
>  	depends on BR2_PACKAGE_MESA3D_OPENGL_EGL # Evas DRM Engine
>  	depends on BR2_PACKAGE_EFL_EEZE # efl drm
>  	depends on BR2_PACKAGE_EFL_OPENGLES # OpenGL ES with EGL support only
> +	depends on BR2_ENABLE_LOCALE # efl-drm <- efl-elput <- linput
>  	select BR2_PACKAGE_EFL_DRM
>  	select BR2_PACKAGE_WAYLAND_PROTOCOLS
>  
> -comment "Wayland support needs udev /dev management (eeze) and OpenGL ES w/ EGL, threads"
> +comment "Wayland support needs udev /dev management (eeze), OpenGL ES w/ EGL, threads, locales"
>  	depends on BR2_PACKAGE_WAYLAND
>  	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_PACKAGE_MESA3D_OPENGL_EGL \
> -		|| !BR2_PACKAGE_EFL_OPENGLES || !BR2_PACKAGE_EFL_EEZE
> +		|| !BR2_PACKAGE_EFL_OPENGLES || !BR2_PACKAGE_EFL_EEZE \
> +		|| !BR2_ENABLE_LOCALE
>  
>  choice
>  	bool "OpenGL support"
> @@ -216,6 +218,7 @@ endchoice # OpenGL support
>  
>  config BR2_PACKAGE_EFL_ELPUT
>  	bool "Elput"
> +	depends on BR2_ENABLE_LOCALE # libinput
>  	depends on BR2_PACKAGE_EFL_EEZE
>  	select BR2_PACKAGE_LIBINPUT
>  	select BR2_PACKAGE_LIBXKBCOMMON
> @@ -226,23 +229,24 @@ config BR2_PACKAGE_EFL_ELPUT
>  	  libinput without having to duplicate the code in each
>  	  subsystem.
>  
> -comment "Elput support needs udev /dev management (eeze)"
> -	depends on !BR2_PACKAGE_EFL_EEZE
> +comment "Elput support needs udev /dev management (eeze), locales"
> +	depends on !BR2_PACKAGE_EFL_EEZE || !BR2_ENABLE_LOCALE
>  
>  config BR2_PACKAGE_EFL_DRM
>  	bool "Evas DRM Engine"
>  	depends on BR2_PACKAGE_EFL_EEZE
>  	depends on BR2_TOOLCHAIN_HAS_THREADS # libdrm
>  	depends on BR2_PACKAGE_MESA3D_OPENGL_EGL # require libgbm from mesa3d
> +	depends on BR2_ENABLE_LOCALE # efl-elput <- libinput
>  	select BR2_PACKAGE_EFL_ELPUT
>  	select BR2_PACKAGE_LIBDRM
>  	select BR2_PACKAGE_LIBXKBCOMMON
>  	help
>  	  This option enable building support for the Evas DRM Engine.
>  
> -comment "Evas DRM Engine needs udev /dev management (eeze) and mesa3d w/ EGL support, threads"
> +comment "Evas DRM Engine needs udev /dev management (eeze), mesa3d w/ EGL support, threads, locales"
>  	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_PACKAGE_MESA3D_OPENGL_EGL \
> -		|| !BR2_PACKAGE_EFL_EEZE
> +		|| !BR2_PACKAGE_EFL_EEZE || !Br2_EMNABLE_LOCALE

meh s/Br2/BR2/

s/Br2_EMNABLE_LOCALE/BR2_ENABLE_LOCALE/

:)
Romain

>  
>  comment "libevas loaders"
>  
> 

^ permalink raw reply

* [Buildroot] [PATCH 2/2] package/ltp-testsuite: disable for sparc
From: Romain Naour @ 2017-05-08 21:19 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170508225421.14efb2b1@free-electrons.com>

Hi Thomas,

Le 08/05/2017 ? 22:54, Thomas Petazzoni a ?crit :
> Hello,
> 
> On Mon, 8 May 2017 22:31:00 +0200, Romain Naour wrote:
> 
>>> This is wrong: we have BR2_TOOLCHAIN_HAS_SYNC_xyz symbols for this.
>>> Sparc is not the only architecture affected.  
>>
>> I was able to build ltp-testsuite with the following config where none of
>> BR2_TOOLCHAIN_HAS_SYNC_* are set:
>>
>> BR2_arcle=y
>> # BR2_ARC_ATOMIC_EXT is not set
>> BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
>> BR2_PACKAGE_LTP_TESTSUITE=y
>>
>> Other architecture are not available due to toolchain dependencies
>>
>> So It's seems related to sparc.
>>
>> I tested with test-pkg to discover these two build issues.
> 
> Investigation of include/tst_atomic.h explains what's happening. Here
> is the code in tst_atomic.h:
> 
> #if HAVE_SYNC_ADD_AND_FETCH == 1
> static inline int tst_atomic_add_return(int i, int *v)
> {
>         return __sync_add_and_fetch(v, i);
> }
> 
> #elif defined(__i386__) || defined(__x86_64__)
> ... x86 specific implementation of tst_atomic_add_return()
> #elif defined(__powerpc__) || defined(__powerpc64__)
> ... powerpc specific implementation of tst_atomic_add_return()
> #elif defined(__s390__) || defined(__s390x__)
> ... S390 specific implementation of tst_atomic_add_return()
> #elif defined(__arc__)
> ... ARC specific implementation of tst_atomic_add_return()
> #else /* HAVE_SYNC_ADD_AND_FETCH == 1 */
> # error Your compiler does not provide __sync_add_and_fetch and LTP\
>         implementation is missing for your architecture.
> #endif
> 
> So, the right dependency is:
> 
> 	# Needs __sync*() built-ins for 4-byte data, except on a few
> 	# architectures for which a specific implementation is provided
> 	# in ltp-testsuite
> 	depends on BR2_TOOLCHAIN_HAS_SYNC_4 || BR2_arc || BR2_i386 || BR2_powerpc || BR2_powerpc64 || BR2_powerpc64le || BR2_x86_64

Fixed in v2, thanks for the help.

Best regards,
Romain

> 
> Best regards,
> 
> Thomas
> 

^ permalink raw reply

* [Buildroot] [PATCH v2 2/2] package/ltp-testsuite: add dependency on BR2_TOOLCHAIN_HAS_SYNC_4
From: Romain Naour @ 2017-05-08 21:18 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170508211833.3462-1-romain.naour@gmail.com>

As stated in commit [1], sparc toolchains doesn't have
any of __sync_*() family of functions implementation.

When __sync_add_and_fetch() is missing, ltp fallback to a local
implementation of tst_atomic_add_return() specific for each
supported architecture.
But there is none for sparc.

So add a dependency on BR2_TOOLCHAIN_HAS_SYNC_4 except for
architectures where a specific implementation is provided
in ltp-testsuite.

Fixes:
http://autobuild.buildroot.net/results/d7c/d7c3b145a64ed3916b89ddb4090050f3b9205e37

[1] 6856e417da4f3aa77e2a814db2a89429af072f7d

Signed-off-by: Romain Naour <romain.naour@gmail.com>
---
v2: add a dependency on BR2_TOOLCHAIN_HAS_SYNC_4 except for arc, i386,
    powerpc, powerpc64, powerpc64le and x86_64
---
 package/ltp-testsuite/Config.in | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/package/ltp-testsuite/Config.in b/package/ltp-testsuite/Config.in
index a7d3e58..efa21e2 100644
--- a/package/ltp-testsuite/Config.in
+++ b/package/ltp-testsuite/Config.in
@@ -3,6 +3,12 @@ config BR2_PACKAGE_LTP_TESTSUITE
 	depends on BR2_USE_MMU # fork()
 	depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL
 	depends on !BR2_TOOLCHAIN_USES_MUSL
+	# Needs __sync*() built-ins for 4-byte data, except on a few
+	# architectures for which a specific implementation is provided
+	# in ltp-testsuite
+	depends on BR2_TOOLCHAIN_HAS_SYNC_4 || BR2_arc || BR2_i386 \
+		|| BR2_powerpc || BR2_powerpc64 || BR2_powerpc64le \
+		|| BR2_x86_64
 	# does not build, cachectl.h issue
 	depends on !BR2_nios2
 	select BR2_PACKAGE_LIBTIRPC if !BR2_TOOLCHAIN_HAS_NATIVE_RPC
@@ -13,5 +19,8 @@ config BR2_PACKAGE_LTP_TESTSUITE
 
 comment "ltp-testsuite needs a glibc or uClibc toolchain w/ NPTL"
 	depends on !BR2_nios2
+	depends on !BR2_TOOLCHAIN_HAS_SYNC_4 && !BR2_arc && !BR2_i386 \
+		&& !BR2_powerpc && !BR2_powerpc64 && !BR2_powerpc64le \
+		&& !BR2_x86_64
 	depends on BR2_USE_MMU
 	depends on !BR2_TOOLCHAIN_HAS_THREADS_NPTL || BR2_TOOLCHAIN_USES_MUSL
-- 
2.9.3

^ permalink raw reply related

* [Buildroot] [PATCH v2 1/2] package/ltp-testsuite: remove ldd commande test with static only build
From: Romain Naour @ 2017-05-08 21:18 UTC (permalink / raw)
  To: buildroot

ldd command build system try to build a shared library unconditionally:

arc-linux-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -matomic -Os -static \
	-I[...]/sysroot/usr/include/tirpc   -g -O2 -fno-strict-aliasing -pipe \
	-Wall -W -Wold-style-definition -shared -o lddfile1.obj.so lddfile1.o

Fixes:
http://autobuild.buildroot.net/results/2ec/2eccf9f517ab15d8d459b06195423fdfe3fba9fa

Signed-off-by: Romain Naour <romain.naour@gmail.com>
---
 package/ltp-testsuite/ltp-testsuite.mk | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/package/ltp-testsuite/ltp-testsuite.mk b/package/ltp-testsuite/ltp-testsuite.mk
index 7f26bd2..2a7f620 100644
--- a/package/ltp-testsuite/ltp-testsuite.mk
+++ b/package/ltp-testsuite/ltp-testsuite.mk
@@ -68,4 +68,12 @@ endef
 LTP_TESTSUITE_POST_PATCH_HOOKS += LTP_TESTSUITE_REMOVE_UNSUPPORTED
 endif
 
+# ldd command build system try to build a shared library unconditionally.
+ifeq ($(BR2_STATIC_LIBS),y)
+define LTP_TESTSUITE_REMOVE_LDD
+	rm -rf $(@D)/testcases/commands/ldd
+endef
+LTP_TESTSUITE_POST_PATCH_HOOKS += LTP_TESTSUITE_REMOVE_LDD
+endif
+
 $(eval $(autotools-package))
-- 
2.9.3

^ permalink raw reply related

* [Buildroot] [PATCH v3 1/2] rhash: new package
From: Yann E. MORIN @ 2017-05-08 21:16 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170508173456.fep2syi43cvqs7ul@tarshish>

Vicente, Baruch, All,

On 2017-05-08 20:34 +0300, Baruch Siach spake thusly:
> Hi Vicente,
> 
> On Mon, May 08, 2017 at 06:00:06PM +0100, Vicente Olivert Riera wrote:
> > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> > ---
> > 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)
> 
> [...]
> 
> > +ifeq ($(BR2_PACKAGE_RHASH_BIN),y)
> > +define RHASH_INSTALL_RHASH_BIN
> > +	$(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D) \
> > +		DESTDIR="$(STAGING_DIR)" $(RHASH_MAKE_OPTS) install-shared
> 
> You mention above that Arnout suggested to install the binaries to staging. 
> But this is quite unusual. A comment explaining the reason for that would be 
> nice.

And please do so in a post-staging-install hook, not in the post-target-install
hook.

Regards,
Yann E. MORIN.

> > +	$(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_RHASH_BIN
> > +endif
> > +
> > +$(eval $(generic-package))
> 
> 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 -
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

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

^ permalink raw reply

* [Buildroot] [PATCH v2] package/efl: fix unmet dependencies
From: Yann E. MORIN @ 2017-05-08 21:11 UTC (permalink / raw)
  To: buildroot

EFL's elput selects libinput but forgot to propagate its dependencies.
Which requires they be propagated further to a second sub-option, then
to a third one.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>

---
Changes v1 -> v2:
  - porpagate dependency to comments as well  (Romain)
  - fix commit log typoes  (Romain, me)
---
 package/efl/Config.in | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/package/efl/Config.in b/package/efl/Config.in
index 371ed3f0d4..7b29e57c0a 100644
--- a/package/efl/Config.in
+++ b/package/efl/Config.in
@@ -178,13 +178,15 @@ config BR2_PACKAGE_EFL_WAYLAND
 	depends on BR2_PACKAGE_MESA3D_OPENGL_EGL # Evas DRM Engine
 	depends on BR2_PACKAGE_EFL_EEZE # efl drm
 	depends on BR2_PACKAGE_EFL_OPENGLES # OpenGL ES with EGL support only
+	depends on BR2_ENABLE_LOCALE # efl-drm <- efl-elput <- linput
 	select BR2_PACKAGE_EFL_DRM
 	select BR2_PACKAGE_WAYLAND_PROTOCOLS
 
-comment "Wayland support needs udev /dev management (eeze) and OpenGL ES w/ EGL, threads"
+comment "Wayland support needs udev /dev management (eeze), OpenGL ES w/ EGL, threads, locales"
 	depends on BR2_PACKAGE_WAYLAND
 	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_PACKAGE_MESA3D_OPENGL_EGL \
-		|| !BR2_PACKAGE_EFL_OPENGLES || !BR2_PACKAGE_EFL_EEZE
+		|| !BR2_PACKAGE_EFL_OPENGLES || !BR2_PACKAGE_EFL_EEZE \
+		|| !BR2_ENABLE_LOCALE
 
 choice
 	bool "OpenGL support"
@@ -216,6 +218,7 @@ endchoice # OpenGL support
 
 config BR2_PACKAGE_EFL_ELPUT
 	bool "Elput"
+	depends on BR2_ENABLE_LOCALE # libinput
 	depends on BR2_PACKAGE_EFL_EEZE
 	select BR2_PACKAGE_LIBINPUT
 	select BR2_PACKAGE_LIBXKBCOMMON
@@ -226,23 +229,24 @@ config BR2_PACKAGE_EFL_ELPUT
 	  libinput without having to duplicate the code in each
 	  subsystem.
 
-comment "Elput support needs udev /dev management (eeze)"
-	depends on !BR2_PACKAGE_EFL_EEZE
+comment "Elput support needs udev /dev management (eeze), locales"
+	depends on !BR2_PACKAGE_EFL_EEZE || !BR2_ENABLE_LOCALE
 
 config BR2_PACKAGE_EFL_DRM
 	bool "Evas DRM Engine"
 	depends on BR2_PACKAGE_EFL_EEZE
 	depends on BR2_TOOLCHAIN_HAS_THREADS # libdrm
 	depends on BR2_PACKAGE_MESA3D_OPENGL_EGL # require libgbm from mesa3d
+	depends on BR2_ENABLE_LOCALE # efl-elput <- libinput
 	select BR2_PACKAGE_EFL_ELPUT
 	select BR2_PACKAGE_LIBDRM
 	select BR2_PACKAGE_LIBXKBCOMMON
 	help
 	  This option enable building support for the Evas DRM Engine.
 
-comment "Evas DRM Engine needs udev /dev management (eeze) and mesa3d w/ EGL support, threads"
+comment "Evas DRM Engine needs udev /dev management (eeze), mesa3d w/ EGL support, threads, locales"
 	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_PACKAGE_MESA3D_OPENGL_EGL \
-		|| !BR2_PACKAGE_EFL_EEZE
+		|| !BR2_PACKAGE_EFL_EEZE || !Br2_EMNABLE_LOCALE
 
 comment "libevas loaders"
 
-- 
2.11.0

^ permalink raw reply related

* [Buildroot] [PATCH 2/2] package/ltp-testsuite: disable for sparc
From: Thomas Petazzoni @ 2017-05-08 20:54 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <dfb284aa-556a-e072-6901-75e45f0a8762@gmail.com>

Hello,

On Mon, 8 May 2017 22:31:00 +0200, Romain Naour wrote:

> > This is wrong: we have BR2_TOOLCHAIN_HAS_SYNC_xyz symbols for this.
> > Sparc is not the only architecture affected.  
> 
> I was able to build ltp-testsuite with the following config where none of
> BR2_TOOLCHAIN_HAS_SYNC_* are set:
> 
> BR2_arcle=y
> # BR2_ARC_ATOMIC_EXT is not set
> BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
> BR2_PACKAGE_LTP_TESTSUITE=y
> 
> Other architecture are not available due to toolchain dependencies
> 
> So It's seems related to sparc.
> 
> I tested with test-pkg to discover these two build issues.

Investigation of include/tst_atomic.h explains what's happening. Here
is the code in tst_atomic.h:

#if HAVE_SYNC_ADD_AND_FETCH == 1
static inline int tst_atomic_add_return(int i, int *v)
{
        return __sync_add_and_fetch(v, i);
}

#elif defined(__i386__) || defined(__x86_64__)
... x86 specific implementation of tst_atomic_add_return()
#elif defined(__powerpc__) || defined(__powerpc64__)
... powerpc specific implementation of tst_atomic_add_return()
#elif defined(__s390__) || defined(__s390x__)
... S390 specific implementation of tst_atomic_add_return()
#elif defined(__arc__)
... ARC specific implementation of tst_atomic_add_return()
#else /* HAVE_SYNC_ADD_AND_FETCH == 1 */
# error Your compiler does not provide __sync_add_and_fetch and LTP\
        implementation is missing for your architecture.
#endif

So, the right dependency is:

	# Needs __sync*() built-ins for 4-byte data, except on a few
	# architectures for which a specific implementation is provided
	# in ltp-testsuite
	depends on BR2_TOOLCHAIN_HAS_SYNC_4 || BR2_arc || BR2_i386 || BR2_powerpc || BR2_powerpc64 || BR2_powerpc64le || BR2_x86_64

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [PATCH] package/efl: fix unmet dependencies
From: Romain Naour @ 2017-05-08 20:53 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170508203030.8852-1-yann.morin.1998@free.fr>

Hi Yann, All,

Le 08/05/2017 ? 22:30, Yann E. MORIN a ?crit :
> EFL's elput selects libinput but forgot to propagate its dependencies.
> Which reauires they be propagated fruther to a seonc sub-option, and
> then to a third one.
> 
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Romain Naour <romain.naour@openwide.fr>
> ---
>  package/efl/Config.in | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/package/efl/Config.in b/package/efl/Config.in
> index 371ed3f0d4..e5b5643c79 100644
> --- a/package/efl/Config.in
> +++ b/package/efl/Config.in
> @@ -178,6 +178,7 @@ config BR2_PACKAGE_EFL_WAYLAND
>  	depends on BR2_PACKAGE_MESA3D_OPENGL_EGL # Evas DRM Engine
>  	depends on BR2_PACKAGE_EFL_EEZE # efl drm
>  	depends on BR2_PACKAGE_EFL_OPENGLES # OpenGL ES with EGL support only
> +	depends on BR2_ENABLE_LOCALE # efl-drm <- efl-elput <- linput
>  	select BR2_PACKAGE_EFL_DRM
>  	select BR2_PACKAGE_WAYLAND_PROTOCOLS

Update the comment bellow

comment "Wayland support needs udev /dev management (eeze) and OpenGL ES w/ EGL,
threads, locale"

but it start to be very long :p

>  
> @@ -216,6 +217,7 @@ endchoice # OpenGL support
>  
>  config BR2_PACKAGE_EFL_ELPUT
>  	bool "Elput"
> +	depends on BR2_ENABLE_LOCALE # libinput
>  	depends on BR2_PACKAGE_EFL_EEZE
>  	select BR2_PACKAGE_LIBINPUT
>  	select BR2_PACKAGE_LIBXKBCOMMON

Same for Elput comment

> @@ -234,6 +236,7 @@ config BR2_PACKAGE_EFL_DRM
>  	depends on BR2_PACKAGE_EFL_EEZE
>  	depends on BR2_TOOLCHAIN_HAS_THREADS # libdrm
>  	depends on BR2_PACKAGE_MESA3D_OPENGL_EGL # require libgbm from mesa3d
> +	depends on BR2_ENABLE_LOCALE # efl-elput <- libinput
>  	select BR2_PACKAGE_EFL_ELPUT
>  	select BR2_PACKAGE_LIBDRM
>  	select BR2_PACKAGE_LIBXKBCOMMON

and for efl_drm comment

Best regards,
Romain

> 

^ permalink raw reply

* [Buildroot] [PATCH] package/espeak: add comment to ignore 'unmet dependencies'
From: Yann E. MORIN @ 2017-05-08 20:46 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170508214911.6c0abdb4@free-electrons.com>

Thomas, All,

On 2017-05-08 21:49 +0200, Thomas Petazzoni spake thusly:
> Hello,
> 
> On Sun,  7 May 2017 22:38:56 +0200, Yann E. MORIN wrote:
> > On master 86b4eeccc4, espeak can generate spurious 'unmet dependencies'
> > messages:
> > 
> >     $ make KCONFIG_SEED=0x7A85DEE0 randconfig
> >     warning: (BR2_PACKAGE_ESPEAK_AUDIO_BACKEND_ALSA) selects
> >     BR2_PACKAGE_PORTAUDIO_CXX which has unmet directdependencies
> >     (BR2_PACKAGE_PORTAUDIO && BR2_INSTALL_LIBSTDCPP)
> > 
> > However, the dpendency chain *is* correct. There is something that
> > causes the kconfig parser to get really confused...
> > 
> > Add a comment statng the issue is spurious, so noone tries to fix it.
> 
> Indeed, I don't see anything wrong in this dependency chain.
> 
> >  config BR2_PACKAGE_ESPEAK_AUDIO_BACKEND_ALSA
> >  	bool "alsa via portaudio"
> > +	# Selecting portaudio generates spurious "unmet dependencies"
> > +	# warnings. Unless you are changing the dependencies of espeak
> > +	# or portaudio, just ignore those spurious warnings.
> >  	select BR2_PACKAGE_PORTAUDIO
> >  	select BR2_PACKAGE_PORTAUDIO_CXX
> 
> Perhaps we could simply add a "depends on BR2_INSTALL_LIBSTDCPP" here,
> which most likely would silence the warning?

Nope, it does not work. The only thing that breaks the dependency chain
is that the select on portaudio be changed into a depends. I could well
provide a patch to that effect, but that not very user-firendly... :-/

Regards,
Yann E. MORIN.

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

^ permalink raw reply

* [Buildroot] Analysis of build results for 2017-05-07
From: Thomas Petazzoni @ 2017-05-08 20:42 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170508062835.044A8207F0@mail.free-electrons.com>

Hello,

On Mon,  8 May 2017 08:28:35 +0200 (CEST), Thomas Petazzoni wrote:

>          arc |                     cups-2.2.3 | NOK | http://autobuild.buildroot.net/results/fe7fda3a1975571523558d02c8396deda7b65f9c | ORPH

Compiling search.c...
/tmp/ccC9w3Ls.s: Assembler messages:
/tmp/ccC9w3Ls.s:114: Error: operand out of range (128 is not between -128 and 127)

Toolchain issue on ARC. Alexey, is this problem already known on your side ?

>         m68k |                   daemon-0.6.4 | NOK | http://autobuild.buildroot.net/results/3338539743c8b0399c6b0fcbbb7c28b58bf3f387 |     

Proposed fixed: https://patchwork.ozlabs.org/patch/759742/

>         m68k |                     ffmpeg-3.3 | NOK | http://autobuild.buildroot.net/results/dc5a042952c3f1f6a6fa06db0e7ac70f701c50dc |     

undefined reference to `__sync_fetch_and_add_4'

We should add the appropriate BR2_TOOLCHAIN_* dependency.

>        nios2 |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/6785eb2c6fba73885df7f586409dc7193f70429f | ORPH
>          arm |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/3474b2dcab2aa232f569c84b62320dc6a9411a23 | ORPH
>         i686 |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/00058baa19bd8e44529bc28026bd2bd3e8968f35 | ORPH
>     mips64el |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/2b2a266ae7ad2edd9875c136811e98aafc38b9a0 | ORPH
>       mipsel |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/51c5c7865767b7f1589bc642e6e6170ee98afda3 | ORPH
>         i586 |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/809a9c5b895475a6f5ab787edb8faa25bfde940f | ORPH
>       x86_64 |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/1ed0f3b179fc0e506406fd13c0c24e36950a8169 | ORPH
>     mips64el |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/c9213690ed53b61da87bb726298bdb9e527dd682 | ORPH
>         mips |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/1d50ed79447633047eb9d073d6658fdac9798afd | ORPH
>       xtensa |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/3dfac664efaf109eaa2e56a282501575d1fd5155 | ORPH
>       x86_64 |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/135f7147f3e55ebb5ade85f01149569a59551ca2 | ORPH
>      sparc64 |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/fde45fe33c3832a81c1952d67eb04d19e25c9c24 | ORPH
>      powerpc |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/5f2fa5a677c74a8b661057ead480e683f6fd8867 | ORPH
>        sparc |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/787d8132a6ffa1ed27e67fff5f5a075a38b092e9 | ORPH
>          sh4 |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/778b13b8b3d6868aba9d6b41dcf6afb62b5accdd | ORPH
>          arm |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/1311e642c7af0411c5e9e8384477ae25588c1696 | ORPH
>       mipsel |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/fefe457471b6819a59fe9275d34765739e92a90e | ORPH
>        nios2 |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/0424a2c6203890d3835bbc66f2b5a6ac94b596c5 | ORPH
>        sparc |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/0be3a50a8a92152aca9c40cc77a566fbbed5fb5d | ORPH
>         or1k |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/f60cae991544eb2c3940e17db9d12a29c76133c6 | ORPH
>  powerpc64le |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/271311e6c2138beac6c66463ecf9ca60cd0d37d8 | ORPH
>      sparc64 |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/572cd899ae3bf4ae20e67578a1de7ff584fcb297 | ORPH
>  powerpc64le |            host-protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/6918b5950e600ed3cd72d8e48bf974b73b1bcc80 | ORPH

All fixed, by adding a gcc >= 4.5 dependency. Thanks to Romain for
having worked on this.

>       x86_64 | kvm-unit-tests-5731572b2ac2... | NOK | http://autobuild.buildroot.net/results/a4a65d01f049db83a93de92660f228dd18532625 |     

I'm proposing https://patchwork.ozlabs.org/patch/759789/ to fix this.

>          arc |         ltp-testsuite-20170116 | NOK | http://autobuild.buildroot.net/results/2eccf9f517ab15d8d459b06195423fdfe3fba9fa |     

/home/test/autobuild/run/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/6.3.0/../../../../arc-buildroot-linux-uclibc/bin/ld: /home/test/autobuild/run/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/6.3.0/crtbeginT.o: relocation R_ARC_32_ME against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC
/home/test/autobuild/run/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/6.3.0/crtbeginT.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

I think this one would be fixed by Romain's patch
https://patchwork.ozlabs.org/patch/759755/.

>         m68k |         ltp-testsuite-20170116 | NOK | http://autobuild.buildroot.net/results/e02fdd1d4abb06c6ebb9fb5f2cbf948a9e62016d |     

/tmp/cc6ITqke.o: In function `worker':
/home/peko/autobuild/instance-1/output/build/ltp-testsuite-20170116/lib/newlib_tests/test08.c:52: undefined reference to `pthread_barrier_wait'

Already fixed by https://git.buildroot.org/buildroot/commit/?id=362d185b309a1634901d4cb35bc1778d58e2015a.

>        sparc |         ltp-testsuite-20170116 | NOK | http://autobuild.buildroot.net/results/fa5072b35b9de0aa3dc7f4ef4dc654121f7ed992 |     

../include/tst_atomic.h:135:3: error: #error Your compiler does not provide __sync_add_and_fetch and LTP implementation is missing for your architecture.

Romain proposed to exclude Sparc, but I believe a better patch that
uses BR2_TOOLCHAIN_HAS_SYNC_xyz should be used instead.

>         m68k |         ltp-testsuite-20170116 | NOK | http://autobuild.buildroot.net/results/5a5a214f72f5babc7abb9629046b5037758bed7f |     
>         m68k |         ltp-testsuite-20170116 | NOK | http://autobuild.buildroot.net/results/3e0bbf41e339e62422463773bf07945f048a9501 |     

Both also fixed by https://git.buildroot.org/buildroot/commit/?id=362d185b309a1634901d4cb35bc1778d58e2015a.

>         mips | make[1]: *** Waiting for un... | TIM | http://autobuild.buildroot.net/results/d1ee618f8eb8846af0b9f4654ea0b81c81ed8ed3 |     

Ignore.

>  powerpc64le |                     mpir-3.0.0 | NOK | http://autobuild.buildroot.net/results/aca8eb763c5a3990a98583127fdbc4658c278891 |     
>          arm |                     mpir-3.0.0 | NOK | http://autobuild.buildroot.net/results/ec67ffdef74b9a61d0491e71f8cb2f8f0b6daa50 |     

Both (and other build issues on mpir) would be fixed by my patch series:

  https://patchwork.ozlabs.org/patch/759766/
  https://patchwork.ozlabs.org/patch/759765/
  https://patchwork.ozlabs.org/patch/759768/
  https://patchwork.ozlabs.org/patch/759767/

>          arm |                     mpv-0.25.0 | NOK | http://autobuild.buildroot.net/results/b470cfba451ce9ba648e3a2f3ae08429db8bdee9 |     
>          arm |                     mpv-0.25.0 | NOK | http://autobuild.buildroot.net/results/0cc6bde872c34311e10f9c725a64553f485efa1a |     

Fixed by https://git.buildroot.org/buildroot/commit/?id=4b72b54fd3b0074864e5ad36ec2fdcd30f4d58eb

>      aarch64 |                   ntp-4.2.8p10 | NOK | http://autobuild.buildroot.net/results/ee8676f4790c38493203726a5a3357b9bc594630 | ORPH

/home/dawncrow/buildroot-test/scripts/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-buildroot-linux-gnu/5.4.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: ../ntpq/libntpq.a(libntpq_a-libntpq.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against external symbol `stderr@@GLIBC_2.17' can not be used when making a shared object; recompile with -fPIC
/home/dawncrow/buildroot-test/scripts/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-buildroot-linux-gnu/5.4.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: ../ntpq/libntpq.a(libntpq_a-libntpq.o)(.text+0x304): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `stderr@@GLIBC_2.17'

Not sure what's going on here. Missing -fPIC apparently. It fails
similarly on lots of platforms:
http://autobuild.buildroot.net/?reason=ntp-4.2.8p10.

>       x86_64 |                  opencv3-3.2.0 | NOK | http://autobuild.buildroot.net/results/43b4acebe74e5546354b392c7618bfc7a2933867 |     

This would be fixed by https://patchwork.ozlabs.org/patch/758798/.

>       x86_64 |                pulseview-0.3.0 | NOK | http://autobuild.buildroot.net/results/ae006828c2562a5a35fa01871797996412ba3d12 |     

/home/rclinux/rc-buildroot-test/scripts/instance-1/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/math/special_functions/detail/erf_inv.hpp:46:10: note: use -std=gnu++11 or -fext-numeric-literals to enable more built-in suffixes
/home/rclinux/rc-buildroot-test/scripts/instance-1/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/math/special_functions/detail/erf_inv.hpp:47:10: error: unable to find numeric literal operator 'operator""Q'
          BOOST_MATH_BIG_CONSTANT(T, 64, -0.00836874819741736770379),

Gaah, some Boost stuff... Anyone ?

Bartosz, since you added pulseview, perhaps you could have a look ?

>     mips64el |                  qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/e0e687bed0f962c0c7893971c342984d9aa99d80 |     

I believe this one has been fixed by
https://git.buildroot.org/buildroot/commit/?id=4860e05a63bf01156466a1a8007de38e2839501a.

>        sparc |                  qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/9f213406954be51dfcad76ebdce8b73850842180 |     

ERROR: detected a std::atomic implementation that fails for function pointers.
Please apply the patch corresponding to your Standard Library vendor, found in
  qtbase/config.tests/common/atomicfptr

Peter (Seiderer), could you have a look ?

>       x86_64 |                qt5webkit-5.6.2 | NOK | http://autobuild.buildroot.net/results/d846065c6909c06e1fe0444e224f89795b93b242 |     

/home/test/autobuild/run/instance-3/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-ctng_locales-linux-gnu/4.8.2/../../../../x86_64-ctng_locales-linux-gnu/bin/ld: final link failed: Memory exhausted

Spurious issue on my autobuilder, it seems.

>      powerpc |              rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/13824f5c36475c3d371f8b6b8f35b82e1e6bd047 |     

Static linking issue, with zlib and intl.

>       xtensa |                     radvd-2.12 | NOK | http://autobuild.buildroot.net/results/f10b5d0eb83b3fb1fe84ce63f6fba7f48488b769 | ORPH
>       xtensa |                     radvd-2.12 | NOK | http://autobuild.buildroot.net/results/07d2160501dbfa5ecf91d38b32a6b8f7c4d7802a | ORPH
>          arc |                     radvd-2.12 | NOK | http://autobuild.buildroot.net/results/b009b9767f1e8f41bd990575c29fe0f84146a54a | ORPH

Redefinition issues between <net/if_arp.h> and <linux/if_arp.h>. Anyone
to take a look ?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [PATCH] kvm-unit-tests: fix build on x86-64 with specific gcc versions
From: Thomas Petazzoni @ 2017-05-08 20:41 UTC (permalink / raw)
  To: buildroot

kvm-unit-tests uses the following code on x86/x86-64:

static inline u64 scale_delta(u64 delta, u64 mul_frac)
{
        u64 product, unused;

        __asm__ (
                "mul %3"
                : "=d" (product), "=a" (unused) : "1" (delta), "rm" ((u64)mul_frac) );

        return product;
}

The "mul" instruction does not have a suffix that indicates the width of
the data being multiplied. When the data is passed in a register, there
is no need to specify the width, but with some gcc versions, the data is
passed as a memory reference, and therefore the assembler does not know
the width of the data to be multiplied. It causes the following build
failure:

x86/hyperv_clock.c: Assembler messages:
x86/hyperv_clock.c:21: Error: no instruction mnemonic suffix given and no register operands; can't size instruction

Since the data being multiplied is 64 bit, we explicitly specify the
instruction as being "mulq".

Fixes:

  http://autobuild.buildroot.net/results/a4a65d01f049db83a93de92660f228dd18532625/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 ...clock-be-explicit-about-mul-instruction-d.patch | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 package/kvm-unit-tests/0001-x86-hyperv_clock-be-explicit-about-mul-instruction-d.patch

diff --git a/package/kvm-unit-tests/0001-x86-hyperv_clock-be-explicit-about-mul-instruction-d.patch b/package/kvm-unit-tests/0001-x86-hyperv_clock-be-explicit-about-mul-instruction-d.patch
new file mode 100644
index 0000000..c8ee6b1
--- /dev/null
+++ b/package/kvm-unit-tests/0001-x86-hyperv_clock-be-explicit-about-mul-instruction-d.patch
@@ -0,0 +1,35 @@
+From 022ae220d6e7b5bd064bc8698c271dca4dac7d8c Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Date: Mon, 8 May 2017 22:27:25 +0200
+Subject: [PATCH] x86/hyperv_clock: be explicit about mul instruction data size
+
+With gcc 4.7.2, the build fails with:
+
+x86/hyperv_clock.c: Assembler messages:
+x86/hyperv_clock.c:21: Error: no instruction mnemonic suffix given and no register operands; can't size instruction
+
+In order to avoid this, make the mul instruction data size explicit by
+adding the appropriate suffix. It operates on 64-bit data, so use
+"mulq".
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+---
+ x86/hyperv_clock.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/x86/hyperv_clock.c b/x86/hyperv_clock.c
+index 8b1deba..6c4dd56 100644
+--- a/x86/hyperv_clock.c
++++ b/x86/hyperv_clock.c
+@@ -19,7 +19,7 @@ static inline u64 scale_delta(u64 delta, u64 mul_frac)
+ 	u64 product, unused;
+ 
+ 	__asm__ (
+-		"mul %3"
++		"mulq %3"
+ 		: "=d" (product), "=a" (unused) : "1" (delta), "rm" ((u64)mul_frac) );
+ 
+ 	return product;
+-- 
+2.7.4
+
-- 
2.7.4

^ permalink raw reply related

* [Buildroot] [PATCH 2/2] package/ltp-testsuite: disable for sparc
From: Romain Naour @ 2017-05-08 20:31 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170508212552.651ed63b@free-electrons.com>

Hi Thomas,

Le 08/05/2017 ? 21:25, Thomas Petazzoni a ?crit :
> Hello,
> 
> On Mon,  8 May 2017 21:08:19 +0200, Romain Naour wrote:
> 
>> +	# missing __sync_*() family of functions
>> +	depends on !BR2_sparc
> 
> This is wrong: we have BR2_TOOLCHAIN_HAS_SYNC_xyz symbols for this.
> Sparc is not the only architecture affected.

I was able to build ltp-testsuite with the following config where none of
BR2_TOOLCHAIN_HAS_SYNC_* are set:

BR2_arcle=y
# BR2_ARC_ATOMIC_EXT is not set
BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
BR2_PACKAGE_LTP_TESTSUITE=y

Other architecture are not available due to toolchain dependencies

So It's seems related to sparc.

I tested with test-pkg to discover these two build issues.

Best regards,
Romain

> 
> Thomas
> 

^ permalink raw reply

* [Buildroot] [PATCH] package/efl: fix unmet dependencies
From: Yann E. MORIN @ 2017-05-08 20:30 UTC (permalink / raw)
  To: buildroot

EFL's elput selects libinput but forgot to propagate its dependencies.
Which reauires they be propagated fruther to a seonc sub-option, and
then to a third one.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>
---
 package/efl/Config.in | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/package/efl/Config.in b/package/efl/Config.in
index 371ed3f0d4..e5b5643c79 100644
--- a/package/efl/Config.in
+++ b/package/efl/Config.in
@@ -178,6 +178,7 @@ config BR2_PACKAGE_EFL_WAYLAND
 	depends on BR2_PACKAGE_MESA3D_OPENGL_EGL # Evas DRM Engine
 	depends on BR2_PACKAGE_EFL_EEZE # efl drm
 	depends on BR2_PACKAGE_EFL_OPENGLES # OpenGL ES with EGL support only
+	depends on BR2_ENABLE_LOCALE # efl-drm <- efl-elput <- linput
 	select BR2_PACKAGE_EFL_DRM
 	select BR2_PACKAGE_WAYLAND_PROTOCOLS
 
@@ -216,6 +217,7 @@ endchoice # OpenGL support
 
 config BR2_PACKAGE_EFL_ELPUT
 	bool "Elput"
+	depends on BR2_ENABLE_LOCALE # libinput
 	depends on BR2_PACKAGE_EFL_EEZE
 	select BR2_PACKAGE_LIBINPUT
 	select BR2_PACKAGE_LIBXKBCOMMON
@@ -234,6 +236,7 @@ config BR2_PACKAGE_EFL_DRM
 	depends on BR2_PACKAGE_EFL_EEZE
 	depends on BR2_TOOLCHAIN_HAS_THREADS # libdrm
 	depends on BR2_PACKAGE_MESA3D_OPENGL_EGL # require libgbm from mesa3d
+	depends on BR2_ENABLE_LOCALE # efl-elput <- libinput
 	select BR2_PACKAGE_EFL_ELPUT
 	select BR2_PACKAGE_LIBDRM
 	select BR2_PACKAGE_LIBXKBCOMMON
-- 
2.11.0

^ permalink raw reply related

* [Buildroot] [PATCH] package/espeak: add comment to ignore 'unmet dependencies'
From: Thomas Petazzoni @ 2017-05-08 19:49 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170507203856.5328-1-yann.morin.1998@free.fr>

Hello,

On Sun,  7 May 2017 22:38:56 +0200, Yann E. MORIN wrote:
> On master 86b4eeccc4, espeak can generate spurious 'unmet dependencies'
> messages:
> 
>     $ make KCONFIG_SEED=0x7A85DEE0 randconfig
>     warning: (BR2_PACKAGE_ESPEAK_AUDIO_BACKEND_ALSA) selects
>     BR2_PACKAGE_PORTAUDIO_CXX which has unmet directdependencies
>     (BR2_PACKAGE_PORTAUDIO && BR2_INSTALL_LIBSTDCPP)
> 
> However, the dpendency chain *is* correct. There is something that
> causes the kconfig parser to get really confused...
> 
> Add a comment statng the issue is spurious, so noone tries to fix it.

Indeed, I don't see anything wrong in this dependency chain.

>  config BR2_PACKAGE_ESPEAK_AUDIO_BACKEND_ALSA
>  	bool "alsa via portaudio"
> +	# Selecting portaudio generates spurious "unmet dependencies"
> +	# warnings. Unless you are changing the dependencies of espeak
> +	# or portaudio, just ignore those spurious warnings.
>  	select BR2_PACKAGE_PORTAUDIO
>  	select BR2_PACKAGE_PORTAUDIO_CXX

Perhaps we could simply add a "depends on BR2_INSTALL_LIBSTDCPP" here,
which most likely would silence the warning?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply


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