NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
5f832bb812
kumquat-buildroot/package/libunwind/Config.in

36 lines
1.5 KiB
Plaintext
Raw Normal View History

libunwind: fix C library dependency The libunwind package currently dependency on glibc *or* uclibc snapshot. However, we are going to remove the support for uclibc snapshot, and uClibc-ng has equivalent functionality as uclibc snapshot. Moreover, musl is also capable of building libunwind for certain architectures. Therefore, this commit reworks the architecture dependencies of libunwind, to make it available on all architectures for which it is supported, depending on the capabilities of the different C libraries, and the implementation of libunwind on each architecture. On some architectures, libunwind uses the C library *context() functions, which are not provided by musl at all, and not provided by uClibc on all architectures. But on some other architectures, libunwind does not use the C library *context() functions, which explains why it can be built with musl on such architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-27 22:25:23 +01:00
# libunwind is only available for a certain subset of the
# architectures (as visible in the list of architectures supported
# with the glibc C library below).
#
# In addition to this, on some architectures libunwind requires the
# *context() function from the C library, which are only available on
# certain architectures in uClibc, and not available at all on
# musl. But on some other architectures, libunwind works without using
# the *context() functions, which allows it to be built with musl.
config BR2_PACKAGE_LIBUNWIND_ARCH_SUPPORTS
bool
default y if BR2_TOOLCHAIN_USES_GLIBC && \
package/libunwind: simplify architecture dependencies BR2_ARM_CPU_HAS_ARM already embeddeds the fact that this is an ARM chip, so (BR2_arm || BR2_armeb) is forcibly true when BR2_ARM_CPU_HAS_ARM is. In other words, BR2_ARM_CPU_HAS_ARM can't be true unless either BR2_arm or BR2_armeb itslef is true. Simplify the logic accordingly. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Romain Naour <romain.naour@openwide.fr> Acked-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-04-17 18:44:01 +02:00
(BR2_ARM_CPU_HAS_ARM || BR2_mips || BR2_mipsel || BR2_mips64 || \
arch: remove support for sh64 It's been deprecated for quite some time now. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-08 20:38:57 +02:00
BR2_mips64el || BR2_powerpc || BR2_sh || BR2_i386 || BR2_x86_64)
libunwind: fix C library dependency The libunwind package currently dependency on glibc *or* uclibc snapshot. However, we are going to remove the support for uclibc snapshot, and uClibc-ng has equivalent functionality as uclibc snapshot. Moreover, musl is also capable of building libunwind for certain architectures. Therefore, this commit reworks the architecture dependencies of libunwind, to make it available on all architectures for which it is supported, depending on the capabilities of the different C libraries, and the implementation of libunwind on each architecture. On some architectures, libunwind uses the C library *context() functions, which are not provided by musl at all, and not provided by uClibc on all architectures. But on some other architectures, libunwind does not use the C library *context() functions, which explains why it can be built with musl on such architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-27 22:25:23 +01:00
default y if BR2_TOOLCHAIN_USES_UCLIBC && \
package/libunwind: simplify architecture dependencies BR2_ARM_CPU_HAS_ARM already embeddeds the fact that this is an ARM chip, so (BR2_arm || BR2_armeb) is forcibly true when BR2_ARM_CPU_HAS_ARM is. In other words, BR2_ARM_CPU_HAS_ARM can't be true unless either BR2_arm or BR2_armeb itslef is true. Simplify the logic accordingly. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Romain Naour <romain.naour@openwide.fr> Acked-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-04-17 18:44:01 +02:00
(BR2_ARM_CPU_HAS_ARM || BR2_mips || BR2_mipsel || \
libunwind: fix C library dependency The libunwind package currently dependency on glibc *or* uclibc snapshot. However, we are going to remove the support for uclibc snapshot, and uClibc-ng has equivalent functionality as uclibc snapshot. Moreover, musl is also capable of building libunwind for certain architectures. Therefore, this commit reworks the architecture dependencies of libunwind, to make it available on all architectures for which it is supported, depending on the capabilities of the different C libraries, and the implementation of libunwind on each architecture. On some architectures, libunwind uses the C library *context() functions, which are not provided by musl at all, and not provided by uClibc on all architectures. But on some other architectures, libunwind does not use the C library *context() functions, which explains why it can be built with musl on such architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-27 22:25:23 +01:00
BR2_mips64 || BR2_mips64el || BR2_x86_64)
default y if BR2_TOOLCHAIN_USES_MUSL && \
package/libunwind: disable for x86 with musl libunwind use sigreturn() and setcontext() while building for x86 [1] but this function is not available with musl [2]. This throw a warning during libunwind build: In file included from x86/Los-linux.c:4:0: x86/Gos-linux.c: In function ‘_ULx86_local_resume’: x86/Gos-linux.c:298:7: warning: implicit declaration of function ‘sigreturn’ [-Wimplicit-function-declaration] sigreturn (sc); ^ But any program trying to link against libunwind-generic.so or libunwind.so fail to build: [...]/usr/lib/libunwind-generic.so: undefined reference to `sigreturn' [...]/usr/lib/libunwind-generic.so: undefined reference to `setcontext' collect2: error: ld returned 1 exit status Disable libunwind for x86 target when musl is used. Reported upstream by Waldemar [3] [1] http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=blob;f=src/x86/Gos-linux.c;h=17aebc2974af50eb0bf8292689b2ed22a4c97866;hb=HEAD#l299 [2] http://openwall.com/lists/musl/2016/02/04/3 [3] http://lists.nongnu.org/archive/html/libunwind-devel/2017-04/msg00030.html Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Waldemar Brodkorb <wbx@openadk.org> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-04-17 19:37:22 +02:00
(BR2_ARM_CPU_HAS_ARM || BR2_x86_64)
libunwind: fix C library dependency The libunwind package currently dependency on glibc *or* uclibc snapshot. However, we are going to remove the support for uclibc snapshot, and uClibc-ng has equivalent functionality as uclibc snapshot. Moreover, musl is also capable of building libunwind for certain architectures. Therefore, this commit reworks the architecture dependencies of libunwind, to make it available on all architectures for which it is supported, depending on the capabilities of the different C libraries, and the implementation of libunwind on each architecture. On some architectures, libunwind uses the C library *context() functions, which are not provided by musl at all, and not provided by uClibc on all architectures. But on some other architectures, libunwind does not use the C library *context() functions, which explains why it can be built with musl on such architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-27 22:25:23 +01:00
libunwind: new package [Thomas: added patch to disable build of tests that fail on uClibc, added dependencies for architectures that are supported.] Signed-off-by: Andy Kennedy <andy.kennedy@adtran.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2013-06-25 23:41:44 +02:00
config BR2_PACKAGE_LIBUNWIND
bool "libunwind"
libunwind: needs threads Fixes: http://autobuild.buildroot.net/results/39a/39a32d323252e3d986fd9290108db7a496d429d9/ Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-09-10 20:17:41 +02:00
depends on BR2_TOOLCHAIN_HAS_THREADS
libunwind: fix C library dependency The libunwind package currently dependency on glibc *or* uclibc snapshot. However, we are going to remove the support for uclibc snapshot, and uClibc-ng has equivalent functionality as uclibc snapshot. Moreover, musl is also capable of building libunwind for certain architectures. Therefore, this commit reworks the architecture dependencies of libunwind, to make it available on all architectures for which it is supported, depending on the capabilities of the different C libraries, and the implementation of libunwind on each architecture. On some architectures, libunwind uses the C library *context() functions, which are not provided by musl at all, and not provided by uClibc on all architectures. But on some other architectures, libunwind does not use the C library *context() functions, which explains why it can be built with musl on such architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-27 22:25:23 +01:00
depends on BR2_PACKAGE_LIBUNWIND_ARCH_SUPPORTS
libunwind: needs dynamic library support libunwind configure script explicitly links libunwind against libgcc_s. libgcc_s is only guaranteed to be available for toolchains that supports dynamic linking: pure static linking toolchains only have libgcc.a, not libgcc_s.so. Therefore, let's make libunwind unavailable on toolchains that lack dynamic linking support. We could potentially support linking with libgcc, but switching to libgcc_s was done upstream because libgcc was lacking some symbols on ARM (https://lists.nongnu.org/archive/html/libunwind-devel/2014-06/msg00024.html). Even though recent gcc versions seem to provide such symbols in libgcc.a, having libunwind available on static linking configurations is not a useful enough use-case to do the necessary research to find when this issue was fixed in gcc. Since libunwind is not used as a mandatory dependency in any package, adding this !BR2_STATIC_LIBS dependency is trivial and nicely avoids the problematic situation. This fixes two different autobuilder failures: - Gstreamer 1.x programs failing to link, because libunwind links against libgcc_s that isn't available (static linking configuration): http://autobuild.buildroot.net/results/9d4fbf7167e9afce0eef5c9e0cfd42c966ecba36/ - Gmrender-resurrect, which fails to link, because GStreamer 1.x uses some libunwind functionality, but does not take into account the libunwind dependency in its .pc files (static linking configuration): http://autobuild.buildroot.net/results/0a3a2485c187a000482c178f1e9c64dd716a858f/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-08-20 23:01:51 +02:00
# forcefully links against libgcc_s, only available in dynamic
# linking configurations
depends on !BR2_STATIC_LIBS
libunwind: new package [Thomas: added patch to disable build of tests that fail on uClibc, added dependencies for architectures that are supported.] Signed-off-by: Andy Kennedy <andy.kennedy@adtran.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2013-06-25 23:41:44 +02:00
help
C API to determine the call-chain of a program.
http://www.nongnu.org/libunwind/index.html
libunwind: needs threads Fixes: http://autobuild.buildroot.net/results/39a/39a32d323252e3d986fd9290108db7a496d429d9/ Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-09-10 20:17:41 +02:00
libunwind: needs dynamic library support libunwind configure script explicitly links libunwind against libgcc_s. libgcc_s is only guaranteed to be available for toolchains that supports dynamic linking: pure static linking toolchains only have libgcc.a, not libgcc_s.so. Therefore, let's make libunwind unavailable on toolchains that lack dynamic linking support. We could potentially support linking with libgcc, but switching to libgcc_s was done upstream because libgcc was lacking some symbols on ARM (https://lists.nongnu.org/archive/html/libunwind-devel/2014-06/msg00024.html). Even though recent gcc versions seem to provide such symbols in libgcc.a, having libunwind available on static linking configurations is not a useful enough use-case to do the necessary research to find when this issue was fixed in gcc. Since libunwind is not used as a mandatory dependency in any package, adding this !BR2_STATIC_LIBS dependency is trivial and nicely avoids the problematic situation. This fixes two different autobuilder failures: - Gstreamer 1.x programs failing to link, because libunwind links against libgcc_s that isn't available (static linking configuration): http://autobuild.buildroot.net/results/9d4fbf7167e9afce0eef5c9e0cfd42c966ecba36/ - Gmrender-resurrect, which fails to link, because GStreamer 1.x uses some libunwind functionality, but does not take into account the libunwind dependency in its .pc files (static linking configuration): http://autobuild.buildroot.net/results/0a3a2485c187a000482c178f1e9c64dd716a858f/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-08-20 23:01:51 +02:00
comment "libunwind needs a toolchain w/ threads, dynamic library"
libunwind: fix C library dependency The libunwind package currently dependency on glibc *or* uclibc snapshot. However, we are going to remove the support for uclibc snapshot, and uClibc-ng has equivalent functionality as uclibc snapshot. Moreover, musl is also capable of building libunwind for certain architectures. Therefore, this commit reworks the architecture dependencies of libunwind, to make it available on all architectures for which it is supported, depending on the capabilities of the different C libraries, and the implementation of libunwind on each architecture. On some architectures, libunwind uses the C library *context() functions, which are not provided by musl at all, and not provided by uClibc on all architectures. But on some other architectures, libunwind does not use the C library *context() functions, which explains why it can be built with musl on such architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-27 22:25:23 +01:00
depends on BR2_PACKAGE_LIBUNWIND_ARCH_SUPPORTS
libunwind: needs dynamic library support libunwind configure script explicitly links libunwind against libgcc_s. libgcc_s is only guaranteed to be available for toolchains that supports dynamic linking: pure static linking toolchains only have libgcc.a, not libgcc_s.so. Therefore, let's make libunwind unavailable on toolchains that lack dynamic linking support. We could potentially support linking with libgcc, but switching to libgcc_s was done upstream because libgcc was lacking some symbols on ARM (https://lists.nongnu.org/archive/html/libunwind-devel/2014-06/msg00024.html). Even though recent gcc versions seem to provide such symbols in libgcc.a, having libunwind available on static linking configurations is not a useful enough use-case to do the necessary research to find when this issue was fixed in gcc. Since libunwind is not used as a mandatory dependency in any package, adding this !BR2_STATIC_LIBS dependency is trivial and nicely avoids the problematic situation. This fixes two different autobuilder failures: - Gstreamer 1.x programs failing to link, because libunwind links against libgcc_s that isn't available (static linking configuration): http://autobuild.buildroot.net/results/9d4fbf7167e9afce0eef5c9e0cfd42c966ecba36/ - Gmrender-resurrect, which fails to link, because GStreamer 1.x uses some libunwind functionality, but does not take into account the libunwind dependency in its .pc files (static linking configuration): http://autobuild.buildroot.net/results/0a3a2485c187a000482c178f1e9c64dd716a858f/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-08-20 23:01:51 +02:00
depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS
Reference in New Issue Copy Permalink