* [Buildroot] [PATCH 1/3] package/enet: new package
From: Romain Naour @ 2019-04-22 17:10 UTC (permalink / raw)
To: buildroot
enet will be used by supertuxkart 1.0.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
---
Build tested with test-pkg -a
---
DEVELOPERS | 1 +
package/Config.in | 1 +
package/enet/Config.in | 16 ++++++++++++++++
package/enet/enet.hash | 3 +++
package/enet/enet.mk | 14 ++++++++++++++
5 files changed, 35 insertions(+)
create mode 100644 package/enet/Config.in
create mode 100644 package/enet/enet.hash
create mode 100644 package/enet/enet.mk
diff --git a/DEVELOPERS b/DEVELOPERS
index ea6b802de4..9a8f4bc191 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -1916,6 +1916,7 @@ N: Romain Naour <romain.naour@gmail.com>
F: package/aubio/
F: package/bullet/
F: package/efl/
+F: package/enet/
F: package/enlightenment/
F: package/flare-engine/
F: package/flare-game/
diff --git a/package/Config.in b/package/Config.in
index 4f3836ae10..349cefbe02 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -1532,6 +1532,7 @@ menu "Networking"
source "package/czmq/Config.in"
source "package/daq/Config.in"
source "package/davici/Config.in"
+ source "package/enet/Config.in"
source "package/filemq/Config.in"
source "package/flickcurl/Config.in"
source "package/fmlib/Config.in"
diff --git a/package/enet/Config.in b/package/enet/Config.in
new file mode 100644
index 0000000000..ef3f1523da
--- /dev/null
+++ b/package/enet/Config.in
@@ -0,0 +1,16 @@
+config BR2_PACKAGE_ENET
+ bool "enet"
+ help
+ ENet's purpose is to provide a relatively thin, simple
+ and robust network communication layer on top of UDP
+ (User Datagram Protocol).The primary feature it
+ provides is optional reliable, in-order delivery of
+ packets.
+
+ ENet omits certain higher level networking features
+ such as authentication, lobbying, server discovery,
+ encryption, or other similar tasks that are
+ particularly application specific so that the library
+ remains flexible, portable, and easily embeddable.
+
+ http://enet.bespin.org
diff --git a/package/enet/enet.hash b/package/enet/enet.hash
new file mode 100644
index 0000000000..ed5231c779
--- /dev/null
+++ b/package/enet/enet.hash
@@ -0,0 +1,3 @@
+# Locally computed
+sha256 98f6f57aab0a424469619ed3047728f0d3901ce8f0dea919c11e7966d807e870 enet-1.3.14.tar.gz
+sha256 eebe647a9ef7e596b0e8b9216c215f169d762af1a27904a87bc2e05b83735d35 LICENSE
diff --git a/package/enet/enet.mk b/package/enet/enet.mk
new file mode 100644
index 0000000000..b12c1b60af
--- /dev/null
+++ b/package/enet/enet.mk
@@ -0,0 +1,14 @@
+################################################################################
+#
+# enet
+#
+################################################################################
+
+ENET_VERSION = 1.3.14
+ENET_SITE = http://enet.bespin.org/download
+ENET_LICENSE = MIT
+ENET_LICENSE_FILES = LICENSE
+
+ENET_INSTALL_STAGING = YES
+
+$(eval $(autotools-package))
--
2.14.5
^ permalink raw reply related
* [Buildroot] [PATCH 1/1] package/lynx: fix build with latomic
From: Fabrice Fontaine @ 2019-04-22 10:48 UTC (permalink / raw)
To: buildroot
Help lynx finding openssl dependencies by giving it a path in --with-ssl
and using pkg-config to directly pass the correct libraries in LIBS.
This will disable the call to pkg-config and CF_ADD_LIBS which has the
sad behavior of removing duplicates ...
As a result, build fails because, the following correct dependencies:
configure:14170: testing adding -L/accts/mlweber1/rclinux/rc-buildroot-test/scripts/instance-0/output/host/bin/../sparc-buildroot-linux-uclibc/sysroot/usr/lib -lssl -L/accts/mlweber1/rclinux/rc-buildroot-test/scripts/instance-0/output/host/bin/../sparc-buildroot-linux-uclibc/sysroot/usr/lib -lz -pthread -latomic -lcrypto -lz -pthread -latomic to LIBS ...
is replaced by:
-L/accts/mlweber1/rclinux/rc-buildroot-test/scripts/instance-0/output/host/bin/../sparc-buildroot-linux-uclibc/sysroot/usr/lib -lssl -lz -pthread -latomic -lcrypto
As a result, static linking fails on crypto because the second -latomic
has been removed ...
Fixes:
- http://autobuild.buildroot.org/results/2c28426253014d93e86e3ba6ed578e84317a9f19
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
package/lynx/lynx.mk | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/package/lynx/lynx.mk b/package/lynx/lynx.mk
index 174d741dd9..3ac5b4cabf 100644
--- a/package/lynx/lynx.mk
+++ b/package/lynx/lynx.mk
@@ -21,8 +21,9 @@ LYNX_CONF_OPTS += --with-screen=slang
endif
ifeq ($(BR2_PACKAGE_OPENSSL),y)
-LYNX_DEPENDENCIES += openssl
-LYNX_CONF_OPTS += --with-ssl
+LYNX_DEPENDENCIES += host-pkgconf openssl
+LYNX_CONF_OPTS += --with-ssl=$(STAGING_DIR)/usr
+LYNX_CONF_ENV = LIBS=`$(PKG_CONFIG_HOST_BINARY) --libs openssl`
else ifeq ($(BR2_PACKAGE_GNUTLS),y)
LYNX_DEPENDENCIES += gnutls
LYNX_CONF_OPTS += --with-gnutls
--
2.20.1
^ permalink raw reply related
* [Buildroot] [PATCH] package/qt5base: fix qmake parallel build
From: Giulio Benetti @ 2019-04-22 9:58 UTC (permalink / raw)
To: buildroot
In-Reply-To: <c060cbb3-21e2-5dcd-18ec-835106f2e682@micronovasrl.com>
When configuring qt5base, qmake is built, but it's not built in parallel
mode. This is due to MAKEFLAGS having 2 dashes on its tail, so this:
MAKEFLAGS="$(MAKEFLAGS) -j$(PARALLEL_JOBS)"
expands in this(i.e. 5 njobs):
MAKEFLAGS="--no-print-directory -- -j5"
and -j5 gets ignored due to "--" preceeding -j5.
Double dashes are part of $(MAKEFLAGS) only when evaluated by shell.
Swap $(MAKEFLAGS) and -j$(PARALLEL_JOBS) to avoid having "--" before
-j$(PARALLEL_JOBS), this way -j$(PARALLEL_JOBS) won't be ignored by
./configure.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
package/qt5/qt5base/qt5base.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/qt5/qt5base/qt5base.mk b/package/qt5/qt5base/qt5base.mk
index 0b45c50a66..e73b8931aa 100644
--- a/package/qt5/qt5base/qt5base.mk
+++ b/package/qt5/qt5base/qt5base.mk
@@ -324,7 +324,7 @@ define QT5BASE_CONFIGURE_CMDS
(cd $(@D); \
$(TARGET_MAKE_ENV) \
PKG_CONFIG="$(PKG_CONFIG_HOST_BINARY)" \
- MAKEFLAGS="$(MAKEFLAGS) -j$(PARALLEL_JOBS)" \
+ MAKEFLAGS="-j$(PARALLEL_JOBS) $(MAKEFLAGS)" \
./configure \
-v \
-prefix /usr \
--
2.17.1
^ permalink raw reply related
* [Buildroot] Qt5 parallel build of qmake
From: Giulio Benetti @ 2019-04-22 9:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <3d42506c-0a69-f3e9-cbc3-c36e21b47cd0@mind.be>
Hello Arnout,
Il 22/04/2019 09:56, Arnout Vandecappelle ha scritto:
>
>
> On 22/04/2019 00:43, Giulio Benetti wrote:
>> Hello Arnout, All,
>>
>> Il 21/04/2019 09:08, Arnout Vandecappelle ha scritto:
>>>
>>>
>>> On 18/04/2019 00:53, Giulio Benetti wrote:
>>>> Hi Arnout, All,
>>>>
>>>> Il 18/04/2019 00:16, Arnout Vandecappelle ha scritto:
>>>>> ?? Hi all,
>>>>>
>>>>> ?? I've put a few people in Cc that seem to be active users of Qt5.
>>>>>
>>>>> ?? I noticed during a test build that during the configure step, qmake is built
>>>>> but not in parallel. I think it should be possible to enable parallel build for
>>>>> qmake by passing MAKE="$(MAKE)" in the environment during configuration. Would
>>>>> someone be interested in checking that out?
>>
>> I've found out which is the problem and where is its origin.
>>
>> On qt5base(and every other package using MAKEFLAGS) this:
>> MAKEFLAGS="$(MAKEFLAGS) -j$(PARALLEL_JOBS)"
>> expands in this:
>> MAKEFLAGS=" --no-print-directory -- -j5"
>> so -j5 is ignored, then is not built in parallel.
>>
>> In:
>> https://git.buildroot.net/buildroot/tree/support/scripts/mkmakefile#n33
>
> Note that I observed the same issue without out-of-tree build, and anyway if I
> do out-of-tree build I always use explicit O= rather than the generated
> makefile. So the problem is not (only) due to mkmakefile.
>
>>
>> basic Makefile is created with a dashed argument(-C to pass Buildroot Root
>> Makefile as argument), but then also O=... option is passed.
>>
>> Here is a snippet of my Makefile file created by mkmakefile script:
>> ...
>> MAKEARGS := -C /home/giuliobenetti/git/buildroot
>> MAKEARGS += O=$(if $(patsubst /%,,$(makedir)),$(CURDIR)/)$(patsubst
>> %/,%,$(makedir))
>
> Note that MAKEARGS is not a special variable for make...
>
>>
>> MAKEFLAGS += --no-print-directory
>
> But MAKEFLAGS is. However, the MAKEFLAGS variable is always rebuilt by the new
> make process by combining the environment variable MAKEFLAGS with the command
> line options that are passed to it.
>
>
>> .PHONY: _all $(MAKECMDGOALS)
>>
>> all??? := $(filter-out Makefile,$(MAKECMDGOALS))
>>
>> _all:
>> ????echo Root MAKEARGS=$(MAKEARGS)
>> ????echo Root MAKEFLAGS=$(MAKEFLAGS)
>> ????$(Q)umask 0022 && $(MAKE) $(MAKEARGS) $(all)
>> ...
>>
>> Doing lot of tries I've found out(I didn't know) that "make", when
>> evaluates $(MAKEARGS) it works as expected and gives:
>> Root MAKEARGS=-C /home/giuliobenetti/git/buildroot
>> O=/home/giuliobenetti/git/build-br/.
>>
>> BUT, when printing MAKEFLAGS with echo, it gives:
>> Root MAKEFLAGS= --no-print-directory --
>>
>> qt5base and every other package using $(MAKEFLAGS) under a *recipe* only will
>> always evaluate $(MAKEFLAGS) as "--".
>> Indeed if you try to use $(info $(MAKEFLAGS)) it will be different, without
>> showing the 2 dashes.
>
> The difference between echo and $(info) is that echo is in a subshell and info
> is not. So apparently, make doesn't just manipulate $(MAKEFLAGS) when it starts,
> but also when it forks a subprocess.
Yes, this is what I've noticed.
>
>> Going deeper I've found that those 2 dashes are appended only if you pass to
>> MAKEARGS some variable like "O=/home/..."
>> I mean, if you remove "O=/home/..." then MAKEFLAGS is "--no-print-directory" only.
>
> That is ...weird... because you do the echo in the outer make, which doesn't
> know that MAKEARGS has any relation with MAKEFLAGS...
Right, the point is that MAKEARGS is passed to $(MAKE) as:
$(MAKE) $(MAKEARGS) $(all)
>
>> The point is that MAKEARGS expects Makefile arguments only and not Variable as I
>> understand. When you add variables, a "--" is appended between Make flags and
>> Variables.
>
> Yes, when make starts, it reworks things so that the variables go into
> MAKEOVERRIDES.
>
>
>> One possible solution I thought is cleaning MAKEFLAGS from those isolated 2 dashes.
>
> I don't think that that's possible, because they're not really there.
>
>> Before I thought to pass directly O=/home/.. when calling $(MAKE),
>> but the problems comes out again, since in sub-makefile, that will be a MAKEARGS
>> again.
>> I don't see any different way to deny Make to emit "--".
>>
>> This impacts MAKEFLAGS variable everywhere when evaluated under recipe like
>> "echo $(MAKEFLAGS)" and it works in this way for both make-4.1 and make-3.82 too.
>>
>> What do you think?
>
> What about swapping the -j and the MAKEFLAGS in qt5base? I.e.
>
> MAKEFLAGS="-j$(PARALLEL_JOBS) $(MAKEFLAGS)"
That was my first idea, then trying to go deeper it took me out of the
track.
Yes, this is the best solution.
In the beginning I thought it was Makefile introducing some "--" dirt,
instead it is "make" that behaves that way when passing variables.
Also, MAKEFLAGS is not used very frequently.
So I go with swapping MAKEFLAGS and PARALLEL_JOBS.
Thank you
Best regards
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
> Regards,
> Arnout
>>
>> Happy easter and kind regards!
^ permalink raw reply
* [Buildroot] [PATCH v2,1/1] package/neon: add NLS dependencies
From: Fabrice Fontaine @ 2019-04-22 9:16 UTC (permalink / raw)
To: buildroot
neon checks for bind_textdomain_codeset
Helps neon to find lintl so it will correctly add -lintl to neon-config
en neon.pc. This will fix build of packages using neon such as nu
Fixes:
- http://autobuild.buildroot.org/results/f7e6afce4b3335573f3cc62d282368b288e9a65a
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
Changes v1 -> v2:
- Help neon finding TARGET_NLS_LIBS
package/neon/neon.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/package/neon/neon.mk b/package/neon/neon.mk
index 1b8eb368c2..2c00e6a8b4 100644
--- a/package/neon/neon.mk
+++ b/package/neon/neon.mk
@@ -11,7 +11,8 @@ NEON_LICENSE_FILES = src/COPYING.LIB test/COPYING README
NEON_INSTALL_STAGING = YES
NEON_CONF_OPTS = --without-gssapi --disable-rpath
NEON_CONFIG_SCRIPTS = neon-config
-NEON_DEPENDENCIES = host-pkgconf
+NEON_DEPENDENCIES = host-pkgconf $(TARGET_NLS_DEPENDENCIES)
+NEON_CONF_ENV = ne_cv_libsfor_bindtextdomain=$(TARGET_NLS_LIBS)
ifeq ($(BR2_PACKAGE_NEON_ZLIB),y)
NEON_CONF_OPTS += --with-zlib=$(STAGING_DIR)
--
2.20.1
^ permalink raw reply related
* [Buildroot] [PATCH v2] package/ascii-invaders: Add the game ascii-invaders
From: Thomas Huth @ 2019-04-22 8:11 UTC (permalink / raw)
To: buildroot
An ASCII-art game like Space Invaders using ncurses.
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
---
v2:
- I'm submitting the patch individually now, to ease the review
- Addressed Gilles' review feedback from v1
- Cleaned warnings from utils/check-package
- Checked with utils/test-pkg, added POST_EXTRACT_HOOK to fix a problem
when linking the program statically
- Use $(call github, ...) helper to create the SITE variable
DEVELOPERS | 3 +++
package/Config.in | 1 +
package/ascii-invaders/Config.in | 7 ++++++
package/ascii-invaders/ascii-invaders.hash | 5 ++++
package/ascii-invaders/ascii-invaders.mk | 28 ++++++++++++++++++++++
5 files changed, 44 insertions(+)
create mode 100644 package/ascii-invaders/Config.in
create mode 100644 package/ascii-invaders/ascii-invaders.hash
create mode 100644 package/ascii-invaders/ascii-invaders.mk
diff --git a/DEVELOPERS b/DEVELOPERS
index ea6b802de4..1e69c72e41 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -2166,6 +2166,9 @@ F: support/scripts/size-stats
F: utils/size-stats-compare
F: toolchain/
+N: Thomas Huth <huth@tuxfamily.org>
+F: package/ascii-invaders/
+
N: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
F: arch/Config.in.arm
F: boot/boot-wrapper-aarch64/
diff --git a/package/Config.in b/package/Config.in
index 4f3836ae10..3642c5679b 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -243,6 +243,7 @@ comment "Themes"
endmenu
menu "Games"
+ source "package/ascii-invaders/Config.in"
source "package/chocolate-doom/Config.in"
source "package/doom-wad/Config.in"
source "package/flare-engine/Config.in"
diff --git a/package/ascii-invaders/Config.in b/package/ascii-invaders/Config.in
new file mode 100644
index 0000000000..f02ab74994
--- /dev/null
+++ b/package/ascii-invaders/Config.in
@@ -0,0 +1,7 @@
+config BR2_PACKAGE_ASCII_INVADERS
+ bool "ascii_invaders"
+ select BR2_PACKAGE_NCURSES
+ help
+ An ASCII-art game like Space Invaders using ncurses.
+
+ https://github.com/macdice/ascii-invaders
diff --git a/package/ascii-invaders/ascii-invaders.hash b/package/ascii-invaders/ascii-invaders.hash
new file mode 100644
index 0000000000..b4805e7b1d
--- /dev/null
+++ b/package/ascii-invaders/ascii-invaders.hash
@@ -0,0 +1,5 @@
+# Locally calculated
+sha512 326708ffc2c277e04575920c58f6a267e0bf46f8d2a3dbca9b5c317fb01006d4f673ab35f92f292549cc52dbee4400a84c85478eb81b9bd7703689a705547bc7 v1.0.1.tar.gz
+
+# Hash for license file
+sha512 1e455684996d7733b2f1ccd4606d034694d16ceff6ede6125d7f1537d20dabe05976cca4cef5cbf6c31352cbd62a515fd8e34a2ffb54dae1181c1116b24c6cf7 LICENSE
diff --git a/package/ascii-invaders/ascii-invaders.mk b/package/ascii-invaders/ascii-invaders.mk
new file mode 100644
index 0000000000..c91e0eeaa8
--- /dev/null
+++ b/package/ascii-invaders/ascii-invaders.mk
@@ -0,0 +1,28 @@
+################################################################################
+#
+# ASCII-Invaders
+#
+################################################################################
+
+ASCII_INVADERS_VERSION = v1.0.1
+ASCII_INVADERS_SOURCE = $(ASCII_INVADERS_VERSION).tar.gz
+ASCII_INVADERS_SITE = $(call github,macdice,ascii-invaders,$(ASCII_INVADERS_VERSION))
+ASCII_INVADERS_DEPENDENCIES = ncurses
+ASCII_INVADERS_LICENSE = GPL-2.0+
+ASCII_INVADERS_LICENSE_FILES = LICENSE
+
+# For compiling statically, libraries must be specified after the object file
+define ASCII_INVADERS_POST_EXTRACT_FIXUP
+ sed -i 's/\$$(LIBS) invaders.o/invaders.o \$$(LIBS)/' $(@D)/Makefile
+endef
+ASCII_INVADERS_POST_EXTRACT_HOOKS += ASCII_INVADERS_POST_EXTRACT_FIXUP
+
+define ASCII_INVADERS_BUILD_CMDS
+ $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D)
+endef
+
+define ASCII_INVADERS_INSTALL_TARGET_CMDS
+ $(INSTALL) -D -m 0755 $(@D)/ascii_invaders $(TARGET_DIR)/usr/bin/ascii_invaders
+endef
+
+$(eval $(generic-package))
--
2.17.2
^ permalink raw reply related
* [Buildroot] Qt5 parallel build of qmake
From: Arnout Vandecappelle @ 2019-04-22 7:56 UTC (permalink / raw)
To: buildroot
In-Reply-To: <36d88896-c2f0-8522-09f8-37d2fec19acd@micronovasrl.com>
On 22/04/2019 00:43, Giulio Benetti wrote:
> Hello Arnout, All,
>
> Il 21/04/2019 09:08, Arnout Vandecappelle ha scritto:
>>
>>
>> On 18/04/2019 00:53, Giulio Benetti wrote:
>>> Hi Arnout, All,
>>>
>>> Il 18/04/2019 00:16, Arnout Vandecappelle ha scritto:
>>>> ?? Hi all,
>>>>
>>>> ?? I've put a few people in Cc that seem to be active users of Qt5.
>>>>
>>>> ?? I noticed during a test build that during the configure step, qmake is built
>>>> but not in parallel. I think it should be possible to enable parallel build for
>>>> qmake by passing MAKE="$(MAKE)" in the environment during configuration. Would
>>>> someone be interested in checking that out?
>
> I've found out which is the problem and where is its origin.
>
> On qt5base(and every other package using MAKEFLAGS) this:
> MAKEFLAGS="$(MAKEFLAGS) -j$(PARALLEL_JOBS)"
> expands in this:
> MAKEFLAGS=" --no-print-directory -- -j5"
> so -j5 is ignored, then is not built in parallel.
>
> In:
> https://git.buildroot.net/buildroot/tree/support/scripts/mkmakefile#n33
Note that I observed the same issue without out-of-tree build, and anyway if I
do out-of-tree build I always use explicit O= rather than the generated
makefile. So the problem is not (only) due to mkmakefile.
>
> basic Makefile is created with a dashed argument(-C to pass Buildroot Root
> Makefile as argument), but then also O=... option is passed.
>
> Here is a snippet of my Makefile file created by mkmakefile script:
> ...
> MAKEARGS := -C /home/giuliobenetti/git/buildroot
> MAKEARGS += O=$(if $(patsubst /%,,$(makedir)),$(CURDIR)/)$(patsubst
> %/,%,$(makedir))
Note that MAKEARGS is not a special variable for make...
>
> MAKEFLAGS += --no-print-directory
But MAKEFLAGS is. However, the MAKEFLAGS variable is always rebuilt by the new
make process by combining the environment variable MAKEFLAGS with the command
line options that are passed to it.
> .PHONY: _all $(MAKECMDGOALS)
>
> all??? := $(filter-out Makefile,$(MAKECMDGOALS))
>
> _all:
> ????echo Root MAKEARGS=$(MAKEARGS)
> ????echo Root MAKEFLAGS=$(MAKEFLAGS)
> ????$(Q)umask 0022 && $(MAKE) $(MAKEARGS) $(all)
> ...
>
> Doing lot of tries I've found out(I didn't know) that "make", when
> evaluates $(MAKEARGS) it works as expected and gives:
> Root MAKEARGS=-C /home/giuliobenetti/git/buildroot
> O=/home/giuliobenetti/git/build-br/.
>
> BUT, when printing MAKEFLAGS with echo, it gives:
> Root MAKEFLAGS= --no-print-directory --
>
> qt5base and every other package using $(MAKEFLAGS) under a *recipe* only will
> always evaluate $(MAKEFLAGS) as "--".
> Indeed if you try to use $(info $(MAKEFLAGS)) it will be different, without
> showing the 2 dashes.
The difference between echo and $(info) is that echo is in a subshell and info
is not. So apparently, make doesn't just manipulate $(MAKEFLAGS) when it starts,
but also when it forks a subprocess.
> Going deeper I've found that those 2 dashes are appended only if you pass to
> MAKEARGS some variable like "O=/home/..."
> I mean, if you remove "O=/home/..." then MAKEFLAGS is "--no-print-directory" only.
That is ...weird... because you do the echo in the outer make, which doesn't
know that MAKEARGS has any relation with MAKEFLAGS...
> The point is that MAKEARGS expects Makefile arguments only and not Variable as I
> understand. When you add variables, a "--" is appended between Make flags and
> Variables.
Yes, when make starts, it reworks things so that the variables go into
MAKEOVERRIDES.
> One possible solution I thought is cleaning MAKEFLAGS from those isolated 2 dashes.
I don't think that that's possible, because they're not really there.
> Before I thought to pass directly O=/home/.. when calling $(MAKE),
> but the problems comes out again, since in sub-makefile, that will be a MAKEARGS
> again.
> I don't see any different way to deny Make to emit "--".
>
> This impacts MAKEFLAGS variable everywhere when evaluated under recipe like
> "echo $(MAKEFLAGS)" and it works in this way for both make-4.1 and make-3.82 too.
>
> What do you think?
What about swapping the -j and the MAKEFLAGS in qt5base? I.e.
MAKEFLAGS="-j$(PARALLEL_JOBS) $(MAKEFLAGS)"
Regards,
Arnout
>
> Happy easter and kind regards!
^ permalink raw reply
* [Buildroot] [PATCH] package/linux-tools: fix kconfig coding style
From: Yann E. MORIN @ 2019-04-22 7:34 UTC (permalink / raw)
To: buildroot
Fix coding style introduced in d5edfa6eef (package/linux-tools/perf: add
dependency on 32-bit sync builtins).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
---
package/linux-tools/Config.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/linux-tools/Config.in b/package/linux-tools/Config.in
index 90b4825fee..1c660f76f5 100644
--- a/package/linux-tools/Config.in
+++ b/package/linux-tools/Config.in
@@ -45,8 +45,8 @@ config BR2_PACKAGE_LINUX_TOOLS_PCI
config BR2_PACKAGE_LINUX_TOOLS_PERF
bool "perf"
- select BR2_PACKAGE_LINUX_TOOLS
depends on BR2_TOOLCHAIN_HAS_SYNC_4
+ select BR2_PACKAGE_LINUX_TOOLS
help
perf (sometimes "Perf Events" or perf tools, originally
"Performance Counters for Linux") - is a performance
--
2.14.1
^ permalink raw reply related
* [Buildroot] [PATCH v4 3/3] .gitlab-ci.yml: add trigger per job
From: Arnout Vandecappelle @ 2019-04-22 7:19 UTC (permalink / raw)
To: buildroot
In-Reply-To: <5cbd187c3c9b_707a3f9fd611a0e8645dd@ultri5.mail>
On 22/04/2019 03:27, Ricardo Martincoski wrote:
> Hello,
>
> On Sat, Apr 13, 2019 at 10:46 AM, Arnout Vandecappelle wrote:
>
>> On 08/04/2019 05:22, Ricardo Martincoski wrote:
>>> The check-* jobs are fast, so there is no need to add a per job trigger
>>> for them.
>>
>> This bit is no longer true, right?
I'm sorry, I had not read it correctly. I had read "The check-* jobs are fast,
so there is no need to exclude them from the defconfig and test branches."
Indeed, there is no need to add a per job trigger. The main reason for that is
though that they'll run for every push anyway, so adding a separate trigger is
kind of useless.
>
> I still think:
> - The check-* jobs are fast
> - there is no *need* to add a per job trigger for them.
> But with v4 of this series indeed it should be easy to add a per job trigger
> for them too, for consistence or some other reason.
>
>>
>> I can fix that up while applying, no need to resend.
>
> So feel free to add them *if* you keep current behavior. For example, now when
> one pushes a branch to GitLab the 4 check-* jobs run.
> I guess you would need to do this for each of the 4 jobs:
>
> check-DEVELOPERS:
> extends: .check_base
> + only:
> + - triggers
> + - tags
> + - branches
> + - /-check-DEVELOPERS$/
>
> If you intend to change the current behavior, please do this in a follow up
> patch so we can discuss a little more during its review.
So no, that was not at all my intention.
>> Also, I'll squash patches 2 and 3. Patch 2 is really not worth much on its own
>> IMO. It would make more sense to introduce the _base keys in a separate patch
>> (i.e. moving the artifacts to _base) and include the variable name in that
>> patch. But I don't think it's worth the effort to try to split like that.
>
> OK. Please feel free to squash them.
I'll do that when I get around to applying them :-)
Regards,
Arnout
^ permalink raw reply
* [Buildroot] [RFC 1/1] br2-external: Alow to include toolchain from external tree
From: Arnout Vandecappelle @ 2019-04-22 7:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20190421175343.GD21166@scaer>
On 21/04/2019 19:53, Yann E. MORIN wrote:
>> - For the removal of prepare-kconfig, maybe mention that it reverts
>> 9429e7b698638399ecfd73aa37545594f253a074
> I see reverts as a way to state "this was incorrect, so we undo it", and
> this is definitely not the case here; this is technically not a revert.
Refering to the original commit makes it easy to see that the only reason why
this was introduced in the first place was for this particular creation of the
.br2-external.in file.
Regards,
Arnout
^ permalink raw reply
* [Buildroot] [PATCH 11/12 v3] support/scripts: use show-info to extract dependency graph
From: Yann E. MORIN @ 2019-04-22 6:53 UTC (permalink / raw)
To: buildroot
In-Reply-To: <5cbd07729d823_6f5c2ad964f8616052718@ultri5.mail>
Ricardo, All,
[Typoes fixed, thanks.]
On 2019-04-21 21:14 -0300, Ricardo Martincoski spake thusly:
> On Mon, Apr 15, 2019 at 04:47 PM, Yann E. MORIN wrote:
> > Since show-dependency-graph never went into a release so far, and
> > show-info does provide the same (and more), swith to using show-info.
[--SNIP--]
> When I do this before and after this patch:
> $ make qemu_arm_versatile_defconfig
> $ make graph-depends
> The color for "rootfs-common" and "rootfs-ext2" changes.
> Can you reproduce it?
Yes.
> Is this intended?
More or less, yes.
> If not intended, do we care enough?
IMHO, not really.
However, I still have further improvements to do about the graphs, and
one of them was to add a new 'colour' to rootfs items.
>
> [snip]
> > + versions[pkg] = \
> > + None if pkg_list[pkg]["type"] == "rootfs" \
> > + else "virtual" if pkg_list[pkg]["virtual"] \
> > + else pkg_list[pkg]["version"]
>
> Why not the straightforward version?
> if pkg_list[pkg]["type"] == "rootfs":
> versions[pkg] = None
> elif pkg_list[pkg]["virtual"]:
> versions[pkg] = "virtual"
> else:
> versions[pkg] = pkg_list[pkg]["version"]
Because this is not pythonic!
Seriously, yes, the main reason is to write python scripts in the most
pythonic way I can, for two reasons:
1- I try to use the idioms and best practices of the language I write
in, so that those that come later and are pofficient in the language
can maintain it without having to cleanup before;
2- I learn python along the way...
So yes, this looks very more pythonic than the if-else-blocs which look
much more like C or shell...
And it takes 6 lines instead of 4! ;-)
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply
* [Buildroot] [autobuild.buildroot.net] Build results for 2019-04-21
From: Thomas Petazzoni @ 2019-04-22 6:00 UTC (permalink / raw)
To: buildroot
Hello,
Build statistics for 2019-04-21
===============================
branch | OK | NOK | TIM | TOT |
2019.02.x | 21 | 1 | 0 | 22 |
master | 139 | 36 | 4 | 179 |
Results for branch 'master'
===========================
Classification of failures by reason
------------------------------------
dhcp-4.4.1 | 4
linknx-0.0.1.37 | 4
cracklib-2.9.7 | 3
libcpprestsdk-v2.10.12 | 3
netsurf | 3
host-efl-1.22.0 | 2
jemalloc-5.2.0 | 2
libkrb5-1.16.2 | 2
ncmpc-0.34 | 2
qt5enginio-1.6.3 | 2
brotli-1.0.7 | 1
ddrescue | 1
gzip-1.9 | 1
libcpprestsdk-v2.10.10 | 1
libssh-0.8.7 | 1
lynx-2.8.9rel.1 | 1
mutt-1.11.4 | 1
netsurf-3.8 | 1
qt5base-5.12.2 | 1
qt5webkit-5.9.1 | 1
samba4-4.9.6 | 1
swupdate-2018.11 | 1
wireshark-3.0.1 | 1
Detail of failures
------------------
microblazeel | brotli-1.0.7 | NOK | http://autobuild.buildroot.net/results/36069178f7e2b291cd7aadd11617697fb94f2bad |
powerpc | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/77370225a0eb6a462772ea07b5bb1329364f7925 |
microblazeel | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/0819d53f9080371be4db2e52a52ebc558678d779 |
powerpc | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/665c9134800d94f1235f0c5c0a387569a969e8a9 |
microblazeel | ddrescue | TIM | http://autobuild.buildroot.net/results/2af69401acb76be3d3fd427d1c58fed3af33bf9b |
x86_64 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/62df959193b7737d436162f93af6b89ea542f8f2 | ORPH
arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/b8cb056e43e0bbc00bdc0ee52f0acefae59ac0e2 | ORPH
arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/6cffc4bc289e0b0989421f2015ae010f9c7e1a43 | ORPH
microblazeel | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/5250d34482ac2c32ca8bef4e44c923c9fedfa65a | ORPH
arm | gzip-1.9 | NOK | http://autobuild.buildroot.net/results/65715e0e2da1c6da84e8c53109e014bc71e5aee4 | ORPH
x86_64 | host-efl-1.22.0 | NOK | http://autobuild.buildroot.net/results/9f8dd89ed5b8fdbe7015f1429f714910489d0521 |
arm | host-efl-1.22.0 | NOK | http://autobuild.buildroot.net/results/782ca4c3d2e5dd7a2eade4380d99c5bec3011d13 |
or1k | jemalloc-5.2.0 | NOK | http://autobuild.buildroot.net/results/8cb80bef5c60ac1e5f6507fbc68c21c32f4af84a |
or1k | jemalloc-5.2.0 | NOK | http://autobuild.buildroot.net/results/9148f9b82721d491a2cc643234e6e9962dd01440 |
microblazeel | libcpprestsdk-v2.10.10 | NOK | http://autobuild.buildroot.net/results/02d453aa6a53bfc460b08afa358bbf3b6c71be95 |
aarch64 | libcpprestsdk-v2.10.12 | NOK | http://autobuild.buildroot.net/results/721cd9f0a11ef468b518302650650f3a0185613e |
mips | libcpprestsdk-v2.10.12 | NOK | http://autobuild.buildroot.net/results/2a9c9224b28209534adc32c4128acddb6bb0ee32 |
x86_64 | libcpprestsdk-v2.10.12 | NOK | http://autobuild.buildroot.net/results/4de9900cfcdc56d172c62bb369004830119de58b |
sparc | libkrb5-1.16.2 | NOK | http://autobuild.buildroot.net/results/ee18d9b9aadb779527eaa09e6fb111109a2f0ae7 |
xtensa | libkrb5-1.16.2 | NOK | http://autobuild.buildroot.net/results/35b82b7c4f0a4f5538560d658b96710eb64ace64 |
xtensa | libssh-0.8.7 | NOK | http://autobuild.buildroot.net/results/a065a8e31363d664195294cf55c39e07ac4d5212 |
mips | linknx-0.0.1.37 | NOK | http://autobuild.buildroot.net/results/32d2a082698319d355d4c82b9fa8baee514a24b1 | ORPH
arm | linknx-0.0.1.37 | NOK | http://autobuild.buildroot.net/results/4b042b7e18425690ec26b4977865516bedcb9edb | ORPH
x86_64 | linknx-0.0.1.37 | NOK | http://autobuild.buildroot.net/results/13aaebfd038f60bab34023ad75b09ebe5bdb5580 | ORPH
arc | linknx-0.0.1.37 | NOK | http://autobuild.buildroot.net/results/58d81531fab8fc98a1d594d70d374cf30e4c5e97 | ORPH
sparc | lynx-2.8.9rel.1 | NOK | http://autobuild.buildroot.net/results/2c28426253014d93e86e3ba6ed578e84317a9f19 |
arm | mutt-1.11.4 | NOK | http://autobuild.buildroot.net/results/9f3dd4e81ba9e82db0e858f91de13ef23bc2bf14 |
arc | ncmpc-0.34 | NOK | http://autobuild.buildroot.net/results/d53978fb30d77cb4d10921bf721eff3d066567ce |
x86_64 | ncmpc-0.34 | NOK | http://autobuild.buildroot.net/results/dd1aa6fd657bab8fa9dba7f2bfb011b8d31355b8 |
arm | netsurf | TIM | http://autobuild.buildroot.net/results/a1025ee5fa35feea5840ac78cb6c39348ed41b9d |
sparc64 | netsurf | TIM | http://autobuild.buildroot.net/results/d354a1ba05d3870e340e7bce3be9b423f824952b |
microblazeel | netsurf | TIM | http://autobuild.buildroot.net/results/8ee91d9cb73ba6834e2a0c54fa0d3ce27e1a47a1 |
mipsel | netsurf-3.8 | NOK | http://autobuild.buildroot.net/results/9ff43426da5e353b1fcc0bc83256e0aba8f6575a |
aarch64_be | qt5base-5.12.2 | NOK | http://autobuild.buildroot.net/results/d676461a2bcc369de6ad0fc82bc2730d23c0f00c |
arm | qt5enginio-1.6.3 | NOK | http://autobuild.buildroot.net/results/a593a7898803dc35e582d01292de9e2151bafcef |
xtensa | qt5enginio-1.6.3 | NOK | http://autobuild.buildroot.net/results/36f88f5476cc4e0431981ef01469476839ca9ef3 |
mipsel | qt5webkit-5.9.1 | NOK | http://autobuild.buildroot.net/results/e5d40c0972a10cd6f3d7c9b226ea103984ecef00 |
powerpc | samba4-4.9.6 | NOK | http://autobuild.buildroot.net/results/52586a2b8680869fc904ffcac548cf0d683070a6 |
m68k | swupdate-2018.11 | NOK | http://autobuild.buildroot.net/results/17c33d5a90be506bb23cfd06f7d7d22a38b1a439 |
powerpc | wireshark-3.0.1 | NOK | http://autobuild.buildroot.net/results/edc1ddd54fb68b2f4262f61189851d795a99e72d | ORPH
Results for branch '2019.02.x'
==============================
Classification of failures by reason
------------------------------------
gnuchess-6.2.5 | 1
Detail of failures
------------------
arm | gnuchess-6.2.5 | NOK | http://autobuild.buildroot.net/results/4fc5671c069da25ceb5c3aaecd6869bd893b5d22 | ORPH
--
http://autobuild.buildroot.net
^ permalink raw reply
* [Buildroot] [PATCH 1/3] package/xorcurses: new package
From: Thomas Huth @ 2019-04-22 5:55 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAKcgs2wiC6CcCwqb04G-VqwxdRULhSeQbEXUW+aMwdfwNFz8pw@mail.gmail.com>
Am Sat, 16 Mar 2019 17:57:28 +0100
schrieb Gilles Talis <gilles.talis@gmail.com>:
> Hello Thomas,
>
> Thanks for your contribution. Please find some comments below.
Hi Gilles,
thanks a lot for your review! I finally found some spare time to look
into this again, but I have some questions below...
> Le sam. 23 f?vr. 2019 ? 21:57, Thomas Huth <huth@tuxfamily.org> a
> ?crit :
[...]
> > diff --git a/package/xorcurses/xorcurses.hash
> > b/package/xorcurses/xorcurses.hash new file mode 100644
> > index 0000000000..49d3a0c3b9
> > --- /dev/null
> > +++ b/package/xorcurses/xorcurses.hash
> > @@ -0,0 +1,2 @@
> > +# Locally calculated
> > +sha512
> > 1782ebf6ae8798b32e0a8e5e20e6d0b44eb619f6e7f015735c6e86205bd545da108c36bff1c9cfc9e9b44dee8f90bacb9df70436991f57f51c2c87e94b3a4725
> > XorCurses-0.2.2.tar.bz2
> You also need to provide the hash for the license file.
There does not seem to be a license file in the tarball here, they just
mention in the README that the game is licensed under the GPL. I guess
I can skip the hash for the license file in this case?
Thomas
^ permalink raw reply
* [Buildroot] [PATCH v4 3/3] .gitlab-ci.yml: add trigger per job
From: Ricardo Martincoski @ 2019-04-22 1:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <7fdd9d95-c147-d5bf-ca56-c0fef507f737@mind.be>
Hello,
On Sat, Apr 13, 2019 at 10:46 AM, Arnout Vandecappelle wrote:
> On 08/04/2019 05:22, Ricardo Martincoski wrote:
>> The check-* jobs are fast, so there is no need to add a per job trigger
>> for them.
>
> This bit is no longer true, right?
I still think:
- The check-* jobs are fast
- there is no *need* to add a per job trigger for them.
But with v4 of this series indeed it should be easy to add a per job trigger
for them too, for consistence or some other reason.
>
> I can fix that up while applying, no need to resend.
So feel free to add them *if* you keep current behavior. For example, now when
one pushes a branch to GitLab the 4 check-* jobs run.
I guess you would need to do this for each of the 4 jobs:
check-DEVELOPERS:
extends: .check_base
+ only:
+ - triggers
+ - tags
+ - branches
+ - /-check-DEVELOPERS$/
If you intend to change the current behavior, please do this in a follow up
patch so we can discuss a little more during its review.
>
> Also, I'll squash patches 2 and 3. Patch 2 is really not worth much on its own
> IMO. It would make more sense to introduce the _base keys in a separate patch
> (i.e. moving the artifacts to _base) and include the variable name in that
> patch. But I don't think it's worth the effort to try to split like that.
OK. Please feel free to squash them.
Regards,
Ricardo
^ permalink raw reply
* [Buildroot] [PATCH 11/12 v3] support/scripts: use show-info to extract dependency graph
From: Ricardo Martincoski @ 2019-04-22 0:14 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cd1c2cccd0a2d39ba4ab7277d09ae0364ffa17f8.1555357645.git.yann.morin.1998@free.fr>
Hello,
One question related to an output that changes with this patch and also some
nits.
On Mon, Apr 15, 2019 at 04:47 PM, Yann E. MORIN wrote:
> Currently, we extract the dependency graph from the aptly named but
> ad-hoc show-dependency-graph rule.
>
> We now have a better solution to report package information, with
> show-info.
>
> Since show-dependency-graph never went into a release so far, and
> show-info does provide the same (and more), swith to using show-info.
s/swith/switch/
>
> Thanks to Adam for suggesting the coding style to have a readable code
> that is not ugly but still pleases flake8. Thanks to Arnout for
> suggesting the use of dict.get() to further simplify the code.
>
> Note: we do not use th reverse_dependencies field because it only
s/th/the/
> contains those packages that have a kconfig option, so we'd miss most
> host packages.
When I do this before and after this patch:
$ make qemu_arm_versatile_defconfig
$ make graph-depends
The color for "rootfs-common" and "rootfs-ext2" changes.
Can you reproduce it?
Is this intended?
If not intended, do we care enough?
[snip]
> + versions[pkg] = \
> + None if pkg_list[pkg]["type"] == "rootfs" \
> + else "virtual" if pkg_list[pkg]["virtual"] \
> + else pkg_list[pkg]["version"]
Why not the straightforward version?
if pkg_list[pkg]["type"] == "rootfs":
versions[pkg] = None
elif pkg_list[pkg]["virtual"]:
versions[pkg] = "virtual"
else:
versions[pkg] = pkg_list[pkg]["version"]
Regards,
Ricardo
^ permalink raw reply
* [Buildroot] Qt5 parallel build of qmake
From: Giulio Benetti @ 2019-04-21 22:43 UTC (permalink / raw)
To: buildroot
In-Reply-To: <ab39fba8-d6b5-4dfc-3390-510bc7cf2bab@mind.be>
Hello Arnout, All,
Il 21/04/2019 09:08, Arnout Vandecappelle ha scritto:
>
>
> On 18/04/2019 00:53, Giulio Benetti wrote:
>> Hi Arnout, All,
>>
>> Il 18/04/2019 00:16, Arnout Vandecappelle ha scritto:
>>> ? Hi all,
>>>
>>> ? I've put a few people in Cc that seem to be active users of Qt5.
>>>
>>> ? I noticed during a test build that during the configure step, qmake is built
>>> but not in parallel. I think it should be possible to enable parallel build for
>>> qmake by passing MAKE="$(MAKE)" in the environment during configuration. Would
>>> someone be interested in checking that out?
I've found out which is the problem and where is its origin.
On qt5base(and every other package using MAKEFLAGS) this:
MAKEFLAGS="$(MAKEFLAGS) -j$(PARALLEL_JOBS)"
expands in this:
MAKEFLAGS=" --no-print-directory -- -j5"
so -j5 is ignored, then is not built in parallel.
In:
https://git.buildroot.net/buildroot/tree/support/scripts/mkmakefile#n33
basic Makefile is created with a dashed argument(-C to pass Buildroot
Root Makefile as argument), but then also O=... option is passed.
Here is a snippet of my Makefile file created by mkmakefile script:
...
MAKEARGS := -C /home/giuliobenetti/git/buildroot
MAKEARGS += O=$(if $(patsubst /%,,$(makedir)),$(CURDIR)/)$(patsubst
%/,%,$(makedir))
MAKEFLAGS += --no-print-directory
.PHONY: _all $(MAKECMDGOALS)
all := $(filter-out Makefile,$(MAKECMDGOALS))
_all:
echo Root MAKEARGS=$(MAKEARGS)
echo Root MAKEFLAGS=$(MAKEFLAGS)
$(Q)umask 0022 && $(MAKE) $(MAKEARGS) $(all)
...
Doing lot of tries I've found out(I didn't know) that "make", when
evaluates $(MAKEARGS) it works as expected and gives:
Root MAKEARGS=-C /home/giuliobenetti/git/buildroot
O=/home/giuliobenetti/git/build-br/.
BUT, when printing MAKEFLAGS with echo, it gives:
Root MAKEFLAGS= --no-print-directory --
qt5base and every other package using $(MAKEFLAGS) under a *recipe* only
will always evaluate $(MAKEFLAGS) as "--".
Indeed if you try to use $(info $(MAKEFLAGS)) it will be different,
without showing the 2 dashes.
Going deeper I've found that those 2 dashes are appended only if you
pass to MAKEARGS some variable like "O=/home/..."
I mean, if you remove "O=/home/..." then MAKEFLAGS is
"--no-print-directory" only.
The point is that MAKEARGS expects Makefile arguments only and not
Variable as I understand. When you add variables, a "--" is appended
between Make flags and Variables.
One possible solution I thought is cleaning MAKEFLAGS from those
isolated 2 dashes.
Before I thought to pass directly O=/home/.. when calling $(MAKE),
but the problems comes out again, since in sub-makefile, that will be a
MAKEARGS again.
I don't see any different way to deny Make to emit "--".
This impacts MAKEFLAGS variable everywhere when evaluated under recipe
like "echo $(MAKEFLAGS)" and it works in this way for both make-4.1 and
make-3.82 too.
What do you think?
Happy easter and kind regards!
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
>> I am interested. I'll try to have it working, let's see if I'm able.
>>
>>> ? Ideally, you should also test with different make versions because they
>>> sometimes throw other stuff in the MAKE variable which may screw things up.
>>
>> How much back should I go with make versions?
>> I mean, now I have 4.1, maybe back to 3.82?
>> Or more?
>
> Just 4.1 and 3.82 should be fine.
>
> Regards,
> Arnout
>
^ permalink raw reply
* [Buildroot] [PATCH 1/1] package/samba4: fix build with NLS
From: Fabrice Fontaine @ 2019-04-21 21:45 UTC (permalink / raw)
To: buildroot
Fixes:
- http://autobuild.buildroot.org/results/52586a2b8680869fc904ffcac548cf0d683070a6
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
package/samba4/samba4.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/samba4/samba4.mk b/package/samba4/samba4.mk
index 3f16b5be4a..f6dbda9dbb 100644
--- a/package/samba4/samba4.mk
+++ b/package/samba4/samba4.mk
@@ -18,7 +18,7 @@ SAMBA4_DEPENDENCIES = \
$(if $(BR2_PACKAGE_READLINE),readline) \
$(TARGET_NLS_DEPENDENCIES)
SAMBA4_CFLAGS = $(TARGET_CFLAGS)
-SAMBA4_LDFLAGS = $(TARGET_LDFLAGS)
+SAMBA4_LDFLAGS = $(TARGET_LDFLAGS) $(TARGET_NLS_LIBS)
SAMBA4_CONF_ENV = \
CFLAGS="$(SAMBA4_CFLAGS)" \
LDFLAGS="$(SAMBA4_LDFLAGS)"
--
2.20.1
^ permalink raw reply related
* [Buildroot] [PATCH 1/1] package/jemalloc: fix build on or1k with gcc < 6
From: Thomas Petazzoni @ 2019-04-21 20:32 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20190421170851.26397-1-fontaine.fabrice@gmail.com>
On Sun, 21 Apr 2019 19:08:51 +0200
Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote:
> Fixes:
> - http://autobuild.buildroot.org/results/8cb80bef5c60ac1e5f6507fbc68c21c32f4af84a
>
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> ---
> package/jemalloc/jemalloc.mk | 6 ++++++
> 1 file changed, 6 insertions(+)
Applied to master, thanks.
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [Buildroot] [git commit] package/jemalloc: fix build on or1k with gcc < 6
From: Thomas Petazzoni @ 2019-04-21 20:32 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=f243f57abcdb415b57b8b887e9cc35bf69163224
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Fixes:
- http://autobuild.buildroot.org/results/8cb80bef5c60ac1e5f6507fbc68c21c32f4af84a
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
package/jemalloc/jemalloc.mk | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/package/jemalloc/jemalloc.mk b/package/jemalloc/jemalloc.mk
index 1273f8a72a..f4d64851bf 100644
--- a/package/jemalloc/jemalloc.mk
+++ b/package/jemalloc/jemalloc.mk
@@ -11,5 +11,11 @@ JEMALLOC_LICENSE = BSD-2-Clause
JEMALLOC_LICENSE_FILES = COPYING
JEMALLOC_INSTALL_STAGING = YES
+# gcc bug internal compiler error: in merge_overlapping_regs, at
+# regrename.c:304. This bug is fixed since gcc 6.
+ifeq ($(BR2_or1k):$(BR2_TOOLCHAIN_GCC_AT_LEAST_6),y:)
+JEMALLOC_CONF_ENV += CFLAGS="$(TARGET_CFLAGS) -O0"
+endif
+
$(eval $(autotools-package))
$(eval $(host-autotools-package))
^ permalink raw reply related
* [Buildroot] [git commit] configs/pine64_sopine: U-Boot needs pylibfdt
From: Thomas Petazzoni @ 2019-04-21 20:06 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=778bdcc79dd2b88127c520915f4d0318bb7c74f7
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Since the bump of U-Boot to 2019.01, pylibfdt is needed to be able to
build the U-Boot image, so we need to enable
BR2_TARGET_UBOOT_NEEDS_PYLIBFDT.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/199339519
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
configs/pine64_sopine_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/pine64_sopine_defconfig b/configs/pine64_sopine_defconfig
index 3dcd907a7e..0e4ccbcb48 100644
--- a/configs/pine64_sopine_defconfig
+++ b/configs/pine64_sopine_defconfig
@@ -20,6 +20,7 @@ BR2_TARGET_UBOOT_CUSTOM_VERSION=y
BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2019.01"
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="sopine_baseboard"
BR2_TARGET_UBOOT_NEEDS_DTC=y
+BR2_TARGET_UBOOT_NEEDS_PYLIBFDT=y
BR2_TARGET_UBOOT_NEEDS_ATF_BL31=y
BR2_TARGET_UBOOT_FORMAT_CUSTOM=y
BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME="u-boot.itb"
^ permalink raw reply related
* [Buildroot] [git commit] configs/pine64: U-Boot needs pylibfdt
From: Thomas Petazzoni @ 2019-04-21 20:06 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=1cc7ab0eaf579e73f6e482a6cc04044d2c7b7f19
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Since the bump of U-Boot to 2019.01, pylibfdt is needed to be able to
build the U-Boot image, so we need to enable
BR2_TARGET_UBOOT_NEEDS_PYLIBFDT.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/199339518
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
configs/pine64_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/pine64_defconfig b/configs/pine64_defconfig
index 3c65ee03e6..dea9a1f5b4 100644
--- a/configs/pine64_defconfig
+++ b/configs/pine64_defconfig
@@ -20,6 +20,7 @@ BR2_TARGET_UBOOT_CUSTOM_VERSION=y
BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2019.01"
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="pine64_plus"
BR2_TARGET_UBOOT_NEEDS_DTC=y
+BR2_TARGET_UBOOT_NEEDS_PYLIBFDT=y
BR2_TARGET_UBOOT_NEEDS_ATF_BL31=y
BR2_TARGET_UBOOT_FORMAT_CUSTOM=y
BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME="u-boot.itb"
^ permalink raw reply related
* [Buildroot] [git commit] configs/orangepi_prime: U-Boot needs pylibfdt
From: Thomas Petazzoni @ 2019-04-21 20:05 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=716b1e3a9f2dc245d22464a47c927eb5b233e0c0
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Since the bump of U-Boot to 2019.01, pylibfdt is needed to be able to
build the U-Boot image, so we need to enable
BR2_TARGET_UBOOT_NEEDS_PYLIBFDT.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/199339510
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
configs/orangepi_prime_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/orangepi_prime_defconfig b/configs/orangepi_prime_defconfig
index 8117b40477..8703dccad5 100644
--- a/configs/orangepi_prime_defconfig
+++ b/configs/orangepi_prime_defconfig
@@ -20,6 +20,7 @@ BR2_TARGET_UBOOT_CUSTOM_VERSION=y
BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2019.01"
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="orangepi_prime"
BR2_TARGET_UBOOT_NEEDS_DTC=y
+BR2_TARGET_UBOOT_NEEDS_PYLIBFDT=y
BR2_TARGET_UBOOT_NEEDS_ATF_BL31=y
BR2_TARGET_UBOOT_FORMAT_CUSTOM=y
BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME="u-boot.itb"
^ permalink raw reply related
* [Buildroot] [git commit] configs/orangepi_plus: U-Boot needs pylibfdt
From: Thomas Petazzoni @ 2019-04-21 20:00 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=fdce55778b3e2109881dcedf6e1f2d7e553737f8
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Since the bump of U-Boot to 2019.01, pylibfdt is needed to be able to
build the U-Boot image, so we need to enable
BR2_TARGET_UBOOT_NEEDS_PYLIBFDT.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/199339509
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
configs/orangepi_plus_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/orangepi_plus_defconfig b/configs/orangepi_plus_defconfig
index a5ca6a8c5f..be3eba51fe 100644
--- a/configs/orangepi_plus_defconfig
+++ b/configs/orangepi_plus_defconfig
@@ -17,6 +17,7 @@ BR2_TARGET_UBOOT_CUSTOM_VERSION=y
BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2019.01"
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="orangepi_plus"
BR2_TARGET_UBOOT_NEEDS_DTC=y
+BR2_TARGET_UBOOT_NEEDS_PYLIBFDT=y
BR2_TARGET_UBOOT_FORMAT_CUSTOM=y
BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME="u-boot-sunxi-with-spl.bin"
^ permalink raw reply related
* [Buildroot] [git commit] configs/orangepi_pc2: U-Boot needs pylibfdt
From: Thomas Petazzoni @ 2019-04-21 19:44 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=9fbdd867483189c46127f18411aaef380fabc52f
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Since the bump of U-Boot to 2019.01, pylibfdt is needed to be able to
build the U-Boot image, so we need to enable
BR2_TARGET_UBOOT_NEEDS_PYLIBFDT.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/199339505
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
configs/orangepi_pc2_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/orangepi_pc2_defconfig b/configs/orangepi_pc2_defconfig
index 7114e62bdb..cd02b46e34 100644
--- a/configs/orangepi_pc2_defconfig
+++ b/configs/orangepi_pc2_defconfig
@@ -20,6 +20,7 @@ BR2_TARGET_UBOOT_CUSTOM_VERSION=y
BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2019.01"
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="orangepi_pc2"
BR2_TARGET_UBOOT_NEEDS_DTC=y
+BR2_TARGET_UBOOT_NEEDS_PYLIBFDT=y
BR2_TARGET_UBOOT_NEEDS_ATF_BL31=y
BR2_TARGET_UBOOT_FORMAT_CUSTOM=y
BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME="u-boot.itb"
^ permalink raw reply related
* [Buildroot] [git commit] configs/olimex_a64_olinuxino: U-Boot needs pylibfdt
From: Thomas Petazzoni @ 2019-04-21 19:44 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=ebf56d25b436fe1c00769b82f7f80516b02f4470
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Since the bump of U-Boot to 2019.01, pylibfdt is needed to be able to
build the U-Boot image, so we need to enable
BR2_TARGET_UBOOT_NEEDS_PYLIBFDT.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/199339498
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
configs/olimex_a64_olinuxino_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/olimex_a64_olinuxino_defconfig b/configs/olimex_a64_olinuxino_defconfig
index 6838be7203..c7bd514581 100644
--- a/configs/olimex_a64_olinuxino_defconfig
+++ b/configs/olimex_a64_olinuxino_defconfig
@@ -20,6 +20,7 @@ BR2_TARGET_UBOOT_CUSTOM_VERSION=y
BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2019.01"
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="a64-olinuxino"
BR2_TARGET_UBOOT_NEEDS_DTC=y
+BR2_TARGET_UBOOT_NEEDS_PYLIBFDT=y
BR2_TARGET_UBOOT_NEEDS_ATF_BL31=y
BR2_TARGET_UBOOT_FORMAT_CUSTOM=y
BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME="u-boot.itb"
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox