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

31 lines
1.2 KiB
Plaintext
Raw Normal View History

efivar: introduce BR2_PACKAGE_EFIVAR_ARCH_SUPPORTS efivar only makes sense on platforms that support UEFI. UEFI is only supported by some architectures at the moment, being mostly employed on platforms such as x86, x86_64 and aarch64. Some other platforms such as MIPS and PowerPC may have some unofficial UEFI support. UEFI is also limited to little endian architectures. efivar was being supported in Buildroot without architecture restrictions so far, however this has led to the creation of a number of hacks in the recipes, mostly for architectures that are not supported by UEFI. In order to avoid spending more time to debug these failures and maintaining more hacks for unsupported architectures, efivar can be restricted to that platforms where it makes sense and where it is more likely to receive some testing and actual usage. The existing hacks for the now unsupported architectures are removed, and the dependency is propagated to efibootmgr as it depends on efivar. Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-06 00:07:17 +01:00
config BR2_PACKAGE_EFIVAR_ARCH_SUPPORTS
bool
package/e*/Config.in: fix ordering of statements The check-package script when ran gives warnings on ordering issues on all of these Config files. This patch cleans up all warnings related to the ordering in the Config files for packages starting with the letter e in the package directory. The appropriate ordering is: type, default, depends on, select, help See http://nightly.buildroot.org/#_config_files for more information. Signed-off-by: Adam Duskett <Adamduskett@outlook.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-04-22 19:17:52 +02:00
default y
efivar: introduce BR2_PACKAGE_EFIVAR_ARCH_SUPPORTS efivar only makes sense on platforms that support UEFI. UEFI is only supported by some architectures at the moment, being mostly employed on platforms such as x86, x86_64 and aarch64. Some other platforms such as MIPS and PowerPC may have some unofficial UEFI support. UEFI is also limited to little endian architectures. efivar was being supported in Buildroot without architecture restrictions so far, however this has led to the creation of a number of hacks in the recipes, mostly for architectures that are not supported by UEFI. In order to avoid spending more time to debug these failures and maintaining more hacks for unsupported architectures, efivar can be restricted to that platforms where it makes sense and where it is more likely to receive some testing and actual usage. The existing hacks for the now unsupported architectures are removed, and the dependency is propagated to efibootmgr as it depends on efivar. Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-06 00:07:17 +01:00
depends on BR2_arm || BR2_aarch64 || BR2_i386 || BR2_x86_64 \
|| BR2_powerpc64le || BR2_mipsel || BR2_mips64el
efivar: new package efivar contains tools and libraries to manipulate EFI variables. This package has some restrictions to build. It needs uchar.h which apparently does not come in uClibc, and it also needs __bswap_constant_*() definitions which are only present in glibc. So, this package was limited to build with glibc toolchains. Although it probably makes sense mostly on x86, x86-64 and aarch64 architectures, there are no architecture specific limitations which would prevent it to build for other architectures, so this restriction was not imposed. This package has been build-tested additionaly on many architectures which support glibc, such as mips, MicroBlaze, sparc64, ppc64. There were some build flag issues found when building to some of these some architectures, although the flags can be also added in the general case, so they were added by default. It has also been found that in some host systems it failed to build due to not generating the .pc files. This has been tracked to the use of make 3.81, so a patch was prepared for it and was submitted upstream. There's also a dependency on the linux/nvme.h header, which is somewhat conturbed, as it has appeared in user space linux headers 3.12 and in 4.4 it was renamed. This has been solved by restricting it to build with linux headers >= 3.12 and a patch from upstream was picked which fixes it for linux headers >= 4.4. Signed-off-by: Erico Nunes <nunes.erico@gmail.com> [Thomas: - Pass TARGET_LDFLAGS in LDFLAGS. - Pass -shared-libgcc only on Microblaze.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-21 03:23:55 +02:00
config BR2_PACKAGE_EFIVAR
bool "efivar"
efivar: introduce BR2_PACKAGE_EFIVAR_ARCH_SUPPORTS efivar only makes sense on platforms that support UEFI. UEFI is only supported by some architectures at the moment, being mostly employed on platforms such as x86, x86_64 and aarch64. Some other platforms such as MIPS and PowerPC may have some unofficial UEFI support. UEFI is also limited to little endian architectures. efivar was being supported in Buildroot without architecture restrictions so far, however this has led to the creation of a number of hacks in the recipes, mostly for architectures that are not supported by UEFI. In order to avoid spending more time to debug these failures and maintaining more hacks for unsupported architectures, efivar can be restricted to that platforms where it makes sense and where it is more likely to receive some testing and actual usage. The existing hacks for the now unsupported architectures are removed, and the dependency is propagated to efibootmgr as it depends on efivar. Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-06 00:07:17 +01:00
depends on BR2_PACKAGE_EFIVAR_ARCH_SUPPORTS
efivar: not available for static builds efivar uses dlfcn.h which is not available in static builds configuration. Also propagate dependency to efibootmgr. This commit also does s/requires/needs/ in comment while at it. Fixes: http://autobuild.buildroot.net/results/ab3/ab32ccacfac2e65e1fcb307058d06c3d0122979d/ Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 17:08:22 +01:00
depends on !BR2_STATIC_LIBS # dlfcn.h
efivar: new package efivar contains tools and libraries to manipulate EFI variables. This package has some restrictions to build. It needs uchar.h which apparently does not come in uClibc, and it also needs __bswap_constant_*() definitions which are only present in glibc. So, this package was limited to build with glibc toolchains. Although it probably makes sense mostly on x86, x86-64 and aarch64 architectures, there are no architecture specific limitations which would prevent it to build for other architectures, so this restriction was not imposed. This package has been build-tested additionaly on many architectures which support glibc, such as mips, MicroBlaze, sparc64, ppc64. There were some build flag issues found when building to some of these some architectures, although the flags can be also added in the general case, so they were added by default. It has also been found that in some host systems it failed to build due to not generating the .pc files. This has been tracked to the use of make 3.81, so a patch was prepared for it and was submitted upstream. There's also a dependency on the linux/nvme.h header, which is somewhat conturbed, as it has appeared in user space linux headers 3.12 and in 4.4 it was renamed. This has been solved by restricting it to build with linux headers >= 3.12 and a patch from upstream was picked which fixes it for linux headers >= 4.4. Signed-off-by: Erico Nunes <nunes.erico@gmail.com> [Thomas: - Pass TARGET_LDFLAGS in LDFLAGS. - Pass -shared-libgcc only on Microblaze.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-21 03:23:55 +02:00
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12 # linux/nvme.h
efivar: disable for some incompatible Sourcery CodeBench toolchains linux/nvme.h has been renamed to linux/nvme_ioctl.h since 4.4, and we have a patch to handle that situation. However, some Sourcery CodeBench toolchains use 4.4 kernel headers but don't have that header file renamed, and that is causing build failures. So, prevent this package to be built using those toolchains. Fixes: http://autobuild.buildroot.net/results/66c/66cf68261fa73c2366610f8d14bd02180ba7cd2d/ http://autobuild.buildroot.net/results/54c/54cc7d4e3b284b35931e08f9c7f0f902df96a989/ Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> [Romain: - add back slash on line breaks - propagate efivar dependencies to efibootmgr - add comments dependencies] Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03 16:20:36 +02:00
# linux/nvme.h has been renamed to linux/nvme_ioctl.h since 4.4,
efivar: bump to version 28 Upstream has changed version numbering scheme since version 25, which came after version 0.24. The two patches that we had in package/efivar/ were backports and so can be dropped with this bump. This new version also fixes the build failure with gcc 6.x, so: Fixes: http://autobuild.buildroot.net/results/ea6/ea6968d5d0fd0d8ee64e045e2aa56c8e8a0b7b14 [Peter: require GCC 4.9+, adjust Config.in nvme.h comment] Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-30 16:46:43 +02:00
# and the efivar source handles that situation. However, some
efivar: disable for some incompatible Sourcery CodeBench toolchains linux/nvme.h has been renamed to linux/nvme_ioctl.h since 4.4, and we have a patch to handle that situation. However, some Sourcery CodeBench toolchains use 4.4 kernel headers but don't have that header file renamed, and that is causing build failures. So, prevent this package to be built using those toolchains. Fixes: http://autobuild.buildroot.net/results/66c/66cf68261fa73c2366610f8d14bd02180ba7cd2d/ http://autobuild.buildroot.net/results/54c/54cc7d4e3b284b35931e08f9c7f0f902df96a989/ Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> [Romain: - add back slash on line breaks - propagate efivar dependencies to efibootmgr - add comments dependencies] Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03 16:20:36 +02:00
# Sourcery CodeBench toolchains use 4.4 kernel headers but they
# don't have that header file renamed, and that is causing build
# failures. So, prevent this package to be built using those
# toolchains.
efivar: introduce BR2_PACKAGE_EFIVAR_ARCH_SUPPORTS efivar only makes sense on platforms that support UEFI. UEFI is only supported by some architectures at the moment, being mostly employed on platforms such as x86, x86_64 and aarch64. Some other platforms such as MIPS and PowerPC may have some unofficial UEFI support. UEFI is also limited to little endian architectures. efivar was being supported in Buildroot without architecture restrictions so far, however this has led to the creation of a number of hacks in the recipes, mostly for architectures that are not supported by UEFI. In order to avoid spending more time to debug these failures and maintaining more hacks for unsupported architectures, efivar can be restricted to that platforms where it makes sense and where it is more likely to receive some testing and actual usage. The existing hacks for the now unsupported architectures are removed, and the dependency is propagated to efibootmgr as it depends on efivar. Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-06 00:07:17 +01:00
depends on !BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS
efivar: bump to version 28 Upstream has changed version numbering scheme since version 25, which came after version 0.24. The two patches that we had in package/efivar/ were backports and so can be dropped with this bump. This new version also fixes the build failure with gcc 6.x, so: Fixes: http://autobuild.buildroot.net/results/ea6/ea6968d5d0fd0d8ee64e045e2aa56c8e8a0b7b14 [Peter: require GCC 4.9+, adjust Config.in nvme.h comment] Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-30 16:46:43 +02:00
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
efivar: new package efivar contains tools and libraries to manipulate EFI variables. This package has some restrictions to build. It needs uchar.h which apparently does not come in uClibc, and it also needs __bswap_constant_*() definitions which are only present in glibc. So, this package was limited to build with glibc toolchains. Although it probably makes sense mostly on x86, x86-64 and aarch64 architectures, there are no architecture specific limitations which would prevent it to build for other architectures, so this restriction was not imposed. This package has been build-tested additionaly on many architectures which support glibc, such as mips, MicroBlaze, sparc64, ppc64. There were some build flag issues found when building to some of these some architectures, although the flags can be also added in the general case, so they were added by default. It has also been found that in some host systems it failed to build due to not generating the .pc files. This has been tracked to the use of make 3.81, so a patch was prepared for it and was submitted upstream. There's also a dependency on the linux/nvme.h header, which is somewhat conturbed, as it has appeared in user space linux headers 3.12 and in 4.4 it was renamed. This has been solved by restricting it to build with linux headers >= 3.12 and a patch from upstream was picked which fixes it for linux headers >= 4.4. Signed-off-by: Erico Nunes <nunes.erico@gmail.com> [Thomas: - Pass TARGET_LDFLAGS in LDFLAGS. - Pass -shared-libgcc only on Microblaze.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-21 03:23:55 +02:00
help
Tools and libraries to manipulate EFI variables
efivar: bump version Drop 0001-Use-z-muldefs-to-avoid-the-multiple-definitions-bug-.patch and 0003-Remove-some-extra-const-that-gcc-complains-about.patch as they are now upstream. The upstream repo moved to the 'rhboot' github project, so adjust upstream URL in .mk and help text to match. Drop dependency on !musl as it is now support since e04281e60cf0d (makeguids: Ensure compatibility with other libcs). Drop BINTARGETS workaround as this is fixed since 6c674283697 (Don't build static by default). Drop popt dependency as it is no longer needed since 1aec5e7891 (Replace popt usage with getopt_long in efivar.c). While we are at it, also add a hash for the license file. Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-03-23 10:57:41 +01:00
https://github.com/rhboot/efivar
efivar: new package efivar contains tools and libraries to manipulate EFI variables. This package has some restrictions to build. It needs uchar.h which apparently does not come in uClibc, and it also needs __bswap_constant_*() definitions which are only present in glibc. So, this package was limited to build with glibc toolchains. Although it probably makes sense mostly on x86, x86-64 and aarch64 architectures, there are no architecture specific limitations which would prevent it to build for other architectures, so this restriction was not imposed. This package has been build-tested additionaly on many architectures which support glibc, such as mips, MicroBlaze, sparc64, ppc64. There were some build flag issues found when building to some of these some architectures, although the flags can be also added in the general case, so they were added by default. It has also been found that in some host systems it failed to build due to not generating the .pc files. This has been tracked to the use of make 3.81, so a patch was prepared for it and was submitted upstream. There's also a dependency on the linux/nvme.h header, which is somewhat conturbed, as it has appeared in user space linux headers 3.12 and in 4.4 it was renamed. This has been solved by restricting it to build with linux headers >= 3.12 and a patch from upstream was picked which fixes it for linux headers >= 4.4. Signed-off-by: Erico Nunes <nunes.erico@gmail.com> [Thomas: - Pass TARGET_LDFLAGS in LDFLAGS. - Pass -shared-libgcc only on Microblaze.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-21 03:23:55 +02:00
packages: host gcc >= 4.8 is now guaranteed ... so we can drop all config options about it and previous versions. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Romain Naour <romain.naour@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-10-26 16:53:24 +02:00
comment "efivar needs a toolchain w/ dynamic library, headers >= 3.12, gcc >= 4.9"
efivar: introduce BR2_PACKAGE_EFIVAR_ARCH_SUPPORTS efivar only makes sense on platforms that support UEFI. UEFI is only supported by some architectures at the moment, being mostly employed on platforms such as x86, x86_64 and aarch64. Some other platforms such as MIPS and PowerPC may have some unofficial UEFI support. UEFI is also limited to little endian architectures. efivar was being supported in Buildroot without architecture restrictions so far, however this has led to the creation of a number of hacks in the recipes, mostly for architectures that are not supported by UEFI. In order to avoid spending more time to debug these failures and maintaining more hacks for unsupported architectures, efivar can be restricted to that platforms where it makes sense and where it is more likely to receive some testing and actual usage. The existing hacks for the now unsupported architectures are removed, and the dependency is propagated to efibootmgr as it depends on efivar. Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-06 00:07:17 +01:00
depends on BR2_PACKAGE_EFIVAR_ARCH_SUPPORTS
efivar: not available for static builds efivar uses dlfcn.h which is not available in static builds configuration. Also propagate dependency to efibootmgr. This commit also does s/requires/needs/ in comment while at it. Fixes: http://autobuild.buildroot.net/results/ab3/ab32ccacfac2e65e1fcb307058d06c3d0122979d/ Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 17:08:22 +01:00
depends on BR2_STATIC_LIBS || \
!BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12 || \
packages: host gcc >= 4.8 is now guaranteed ... so we can drop all config options about it and previous versions. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Romain Naour <romain.naour@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-10-26 16:53:24 +02:00
!BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
efivar: introduce BR2_PACKAGE_EFIVAR_ARCH_SUPPORTS efivar only makes sense on platforms that support UEFI. UEFI is only supported by some architectures at the moment, being mostly employed on platforms such as x86, x86_64 and aarch64. Some other platforms such as MIPS and PowerPC may have some unofficial UEFI support. UEFI is also limited to little endian architectures. efivar was being supported in Buildroot without architecture restrictions so far, however this has led to the creation of a number of hacks in the recipes, mostly for architectures that are not supported by UEFI. In order to avoid spending more time to debug these failures and maintaining more hacks for unsupported architectures, efivar can be restricted to that platforms where it makes sense and where it is more likely to receive some testing and actual usage. The existing hacks for the now unsupported architectures are removed, and the dependency is propagated to efibootmgr as it depends on efivar. Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-06 00:07:17 +01:00
depends on !BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS
Reference in New Issue Copy Permalink