summaryrefslogtreecommitdiff
path: root/package/efivar
AgeCommit message (Collapse)Author
2016-12-07efivar: introduce BR2_PACKAGE_EFIVAR_ARCH_SUPPORTSErico Nunes
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-07efivar: fix comment after uClibc compatibility patchErico Nunes
uClibc support was recently added to efivar through a small compatibility patch. This commit updates a comment in the efivar recipe to reflect this, as we no longer have glibc as the only supported C library. 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-05efivar: not available for static buildsRahul Bedarkar
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-11-27efivar: allow build with uClibcAndy Shevchenko
Details at https://github.com/rhinstaller/efivar/issues/76. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> [Thomas: tweak the dependency, efivar still doesn't build with musl.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-27efivar: bump to version 30Andy Shevchenko
Use newest release. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-02efivar: bump to version 28Erico Nunes
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-07-03efivar: disable for some incompatible Sourcery CodeBench toolchainsVicente Olivert Riera
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-01efivar: depends on target gcc >= 4.7Erico Nunes
The efivar internal build system uses flags such as -std=gnu11 , -Wmaybe-uninitialized , -flto which are available in gcc >= 4.7 only. These flags are passed both to target build and to build a host tool. For the host part, this has been worked around by overriding 'gcc_flags', but doing that for the target would remove all flags that upstream intended for the target build. Buildroot doesn't support building gcc 4.6 in its own toolchain anymore but it's possible to use an external toolchain with gcc 4.6 which would be unable to build this package. This patch adds a limitation on toolchains with target gcc >= 4.7 to make sure that the flags are available in the chosen toolchain. Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-01efivar: force shared libgcc for Nios IIErico Nunes
efivar for Nios II also has to be linked with shared libgcc to avoid an error due to FDE encoding in static libgcc when linking libefiboot.so. Fixes: http://autobuild.buildroot.net/results/0c9/0c90e3e7ad41d21dd832f6f266af35fc19185170/ Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-28Replace (e)glibc by glibcThomas Petazzoni
Following the removal of eglibc support, this commit replaces all occurences of "(e)glibc" by just "glibc". Most of the occurences are in package Config.in comments. In addition, when the form "an (e)glibc ..." was used, it is replaced by "a glibc ...". [Peter: add new efi* packages, s/uclibc/uClibc as suggested by Romain, systemd / liquid-dsp tweaks as suggested by Yann] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-06-25efivar: fix build with old gcc versionsThomas Petazzoni
The efivar build process starts by building one tool for the host, which is needed for the rest of the build. This tool currently fails to build with old gcc versions because the gcc.specs used by efivar specifies -std=gnu11. To address this, this patch: - passes 'gcc_flags=' to the host build, so that the custom gcc specs are not passed. They are in practice not needed for the build of the simple makeguids host utility. - passes -std=gnu99 instead of -std=c99 in the build of host makeguids, because the source code uses anonymous structs and unions, which requires std=gnu99 and not just std=c99 In addition, the build by default assumes that the target toolchain is LTO capable, and that therefore you can call gcc-ar, gcc-nm and gcc-ranlib. This fails short when the target toolchain is for example gcc 4.7. To address this, we explicitly specify AR, NM and RANLIB to be used, but pass them as make options instead of in the environment, in order to override the values specified in the package Makefile. Fixes: http://autobuild.buildroot.net/results/fe40c1d139ba8ddeef3dafd5c1818a946f014d7c/ Cc: Erico Nunes <nunes.erico@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-12efivar: new packageErico Nunes
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>