* [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
* [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 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] 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] 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] 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] [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 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 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 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 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 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 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] 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 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 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 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] 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] [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] [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] 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] 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] [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] 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] [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
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