Skip to contentSkip to conversation

efibootmgr: build with uClibc

PATCH New Andy Shevchenko 3 participants 9 messages Nov 28, 2016 – Dec 13, 2016

lore
Share & tools
lore
#0 lore raw

cover efibootmgr: build with uClibc

These patches make possible to use efibootmgr with uClibc. All patches had been sent to upstream.

I have tested in my environment that doesn't use unicode characters. So, any additional tests are appreciated.

Andy Shevchenko (3):
efivar: bump to version 30
efivar: allow build with uClibc
efibootmrg: Allow build with uClibc

 .../efibootmgr/0001-Allow-build-with-uClibc.patch  | 38 ++++++++++++++++++++++
 package/efibootmgr/Config.in                       |  3 +-
 package/efibootmgr/efibootmgr.mk                   |  8 +++--
 ...fs-to-avoid-the-multiple-definitions-bug-.patch | 28 ++++++++++++++++
 package/efivar/0002-Allow-build-with-uClibc.patch  | 38 ++++++++++++++++++++++
 package/efivar/Config.in                           |  2 --
 package/efivar/efivar.hash                         |  2 +-
 package/efivar/efivar.mk                           |  2 +-
 8 files changed, 112 insertions(+), 9 deletions(-)
 create mode 100644 package/efibootmgr/0001-Allow-build-with-uClibc.patch
 create mode 100644 package/efivar/0001-Use-z-muldefs-to-avoid-the-multiple-definitions-bug-.patch
 create mode 100644 package/efivar/0002-Allow-build-with-uClibc.patch
Signature · 1 line
2.10.2
#1 lore raw

PATCH 1/3 efivar: bump to version 30

Use newest release.

---
 ...fs-to-avoid-the-multiple-definitions-bug-.patch | 28 ++++++++++++++++++++++
 package/efivar/efivar.hash                         |  2 +-
 package/efivar/efivar.mk                           |  2 +-
 3 files changed, 30 insertions(+), 2 deletions(-)
 create mode 100644 package/efivar/0001-Use-z-muldefs-to-avoid-the-multiple-definitions-bug-.patch
package/efivar/0001-Use-z-muldefs-to-avoid-the-multiple-definitions-bug-.patch new file +28 -0
new file mode 100644
index 0000000..2caed5e
@@ -0,0 +1,28 @@
+From 314eb67b239e60c2ed3700e2baf9cd0e590465f3 Mon Sep 17 00:00:00 2001
+From: Peter Jones <[email protected]>
+Date: Thu, 27 Oct 2016 09:19:18 -0400
+Subject: [PATCH 1/2] Use -z muldefs to avoid the multiple definitions bug
+ without -flto
+
+This fixes github issue #64
+
+Signed-off-by: Peter Jones <[email protected]>
+---
+ Make.defaults | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/Make.defaults b/Make.defaults
+index aa974d9..c9d599f 100644
+--- a/Make.defaults
++++ b/Make.defaults
+@@ -32,6 +32,7 @@ cflags	= $(CFLAGS) -I${TOPDIR}/src/include/efivar/ \
+ clang_ccldflags =
+ gcc_ccldflags =
+ ccldflags = $(cflags) -L. $(CCLDFLAGS) $(LDFLAGS) \
++	-Wl,-z,muldefs \
+ 	$(if $(findstring clang,$(CCLD)),$(clang_ccldflags),) \
+ 	$(if $(findstring gcc,$(CCLD)),$(gcc_ccldflags),) \
+ 	$(call pkg-config-ccldflags)
+-- 
+2.10.2
+
package/efivar/efivar.hash +1 -1
index 3671bbc..e337b96 100644
@@ -1,2 +1,2 @@
 # locally computed hash
-sha256 7fed0b31fe796d7dfef40cccb97b8bb0b806f16e568074ad2d456be30e195f5e efivar-28.tar.gz
+sha256 20709c76311f8eb8be92977b7ac008ce62501fa9f7fe885a784321540fc352f9 efivar-30.tar.gz
package/efivar/efivar.mk +1 -1
index cff3ac1..913322e 100644
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-EFIVAR_VERSION = 28
+EFIVAR_VERSION = 30
 EFIVAR_SITE = $(call github,rhinstaller,efivar,$(EFIVAR_VERSION))
 EFIVAR_LICENSE = LGPLv2.1
 EFIVAR_LICENSE_FILES = COPYING
Signature · 1 line
2.10.2
#3 lore raw

PATCH 1/3 efivar: bump to version 30

Hi Thomas, all,

Quoted 5 lines · Thomas Petazzoni

This update is causing a large number of build failures, see:

http://autobuild.buildroot.net/?reason=efivar-30

Could you have a look?

I took a look at them and it seems that there are two kinds of failures. The first is that efivar uses dynamic linking as it uses dlfcn.h and this has been exposed now that we no longer restrict to glibc, so we should probably restrict it in Config.in for non-static builds.
The other failures related to blackfin are weirder, I don't fully understand what is going on there yet, but I wonder if it makes sense to invest more effort in debugging that.
I think we could consider limiting efivar/efibootmgr to architectures that can actually run EFI. That is, x86_64, aarch64, x86, arm, possibly allow in a few other experimental ones (there is a summary at
https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Processor_compatibility
), and only allow little-endian variations as well. I would prefer if we didn't have to add architecture restrictions for building, however with this we are already maintaining a number of hacks in efivar for architectures that will probably never use it anytime soon.

By the way, there is a mention to "since we depend on glibc" in efivar.mk which was not removed when the uclibc compatibility patch was introduced, so we should update that as well.

If you agree with solving that by limiting architectures, I can submit these fixes.

Erico

#4 lore raw

PATCH 1/3 efivar: bump to version 30

Hello,

Quoted 5 lines · Erico Nunes

I took a look at them and it seems that there are two kinds of failures. The first is that efivar uses dynamic linking as it uses dlfcn.h and this has been exposed now that we no longer restrict to glibc, so we should probably restrict it in Config.in for non-static builds.

ACK.

Quoted 12 lines

The other failures related to blackfin are weirder, I don't fully understand what is going on there yet, but I wonder if it makes sense to invest more effort in debugging that.
I think we could consider limiting efivar/efibootmgr to architectures that can actually run EFI. That is, x86_64, aarch64, x86, arm, possibly allow in a few other experimental ones (there is a summary at
https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Processor_compatibility
), and only allow little-endian variations as well. I would prefer if we didn't have to add architecture restrictions for building, however with this we are already maintaining a number of hacks in efivar for architectures that will probably never use it anytime soon.

Quoted 3 lines

By the way, there is a mention to "since we depend on glibc" in efivar.mk which was not removed when the uclibc compatibility patch was introduced, so we should update that as well.

OK.

Quoted 2 lines

If you agree with solving that by limiting architectures, I can submit these fixes.

Limiting architectures is normally OK when there is a fundamental reason why it cannot be built/used on a given architecture, so I'm generally not too happy when we limit architectures just because we want to avoid build failures and not investigate the real reason.

But since I agree that EFI is very architecture specific, and most likely never used on Blackin/m68k/etc., I'm fine with a patch limiting the architectures.

Please introduce a BR2_PACKAGE_EFIVAR_ARCH_SUPPORTS hidden boolean, and use it in BR2_PACKAGE_EFIVAR, in the comment, in BR2_PACKAGE_EFIBOOTMGR and its comment.

Thanks a lot!

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
#5 lore raw

PATCH 2/3 efivar: allow build with uClibc

In reply to Andy Shevchenko

Details at https://github.com/rhinstaller/efivar/issues/76.

---
 package/efivar/0002-Allow-build-with-uClibc.patch | 38 +++++++++++++++++++++++
 package/efivar/Config.in                          |  2 --
 2 files changed, 38 insertions(+), 2 deletions(-)
 create mode 100644 package/efivar/0002-Allow-build-with-uClibc.patch
package/efivar/0002-Allow-build-with-uClibc.patch new file +38 -0
new file mode 100644
index 0000000..7b62714
@@ -0,0 +1,38 @@
+From 2255601757a8a58baddad2d37d0bcc6b003a3732 Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <[email protected]>
+Date: Fri, 25 Nov 2016 19:42:27 +0200
+Subject: [PATCH 2/2] Allow build with uClibc
+
+Basically this replaces type definitions in <uchar.h>.
+
+Signed-off-by: Andy Shevchenko <[email protected]>
+---
+ src/export.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/src/export.c b/src/export.c
+index 7f2d4dd..72c02d1 100644
+--- a/src/export.c
++++ b/src/export.c
+@@ -21,11 +21,17 @@
+ #include <inttypes.h>
+ #include <stdint.h>
+ #include <stdlib.h>
+-#include <uchar.h>
+ 
+ #include <efivar.h>
+ #include "lib.h"
+ 
++#ifdef __UCLIBC__
++typedef int_least16_t char16_t;
++typedef int_least32_t char32_t;
++#else
++#include <uchar.h>
++#endif
++
+ #define EFIVAR_MAGIC 0xf3df1597
+ 
+ #define ATTRS_UNSET 0xa5a5a5a5a5a5a5a5
+-- 
+2.10.2
+
package/efivar/Config.in +0 -2
index 466a30a..5fd3360 100644
@@ -11,7 +11,6 @@ config BR2_PACKAGE_EFIVAR
 		!BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII
 	# doesn't build with uclibc due to lack of uchar.h
 	# doesn't build with musl due to lack of __bswap_constant_16
-	depends on BR2_TOOLCHAIN_USES_GLIBC
 	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
 	select BR2_PACKAGE_POPT
 	help
@@ -21,7 +20,6 @@ config BR2_PACKAGE_EFIVAR
 
 comment "efivar requires a glibc toolchain w/ headers >= 3.12, gcc >= 4.9"
 	depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12 || \
-		!BR2_TOOLCHAIN_USES_GLIBC || \
 		!BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
 	depends on !BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS && \
 		!BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII
Signature · 1 line
2.10.2
#6 lore raw

PATCH 3/3 efibootmrg: Allow build with uClibc

In reply to Andy Shevchenko

Details at https://github.com/rhinstaller/efibootmgr/issues/61.

---
 .../efibootmgr/0001-Allow-build-with-uClibc.patch  | 38 ++++++++++++++++++++++
 package/efibootmgr/Config.in                       |  3 +-
 package/efibootmgr/efibootmgr.mk                   |  8 +++--
 3 files changed, 44 insertions(+), 5 deletions(-)
 create mode 100644 package/efibootmgr/0001-Allow-build-with-uClibc.patch
package/efibootmgr/0001-Allow-build-with-uClibc.patch new file +38 -0
new file mode 100644
index 0000000..1e3f9ec
@@ -0,0 +1,38 @@
+From bbfcc60497c326576bb23cb01d90115ef3cf6947 Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <[email protected]>
+Date: Fri, 25 Nov 2016 20:26:52 +0200
+Subject: [PATCH 1/1] Allow build with uClibc
+
+Signed-off-by: Andy Shevchenko <[email protected]>
+---
+ src/efibootdump.c | 1 -
+ src/eficonman.c   | 1 -
+ 2 files changed, 2 deletions(-)
+
+diff --git a/src/efibootdump.c b/src/efibootdump.c
+index 6ff8360..7c5a1c5 100644
+--- a/src/efibootdump.c
++++ b/src/efibootdump.c
+@@ -19,7 +19,6 @@
+ #include <stdint.h>
+ #include <stdio.h>
+ #include <stdlib.h>
+-#include <uchar.h>
+ #include <unistd.h>
+ 
+ #include "error.h"
+diff --git a/src/eficonman.c b/src/eficonman.c
+index 2c2be38..9bfae79 100644
+--- a/src/eficonman.c
++++ b/src/eficonman.c
+@@ -17,7 +17,6 @@
+ #include <stdint.h>
+ #include <stdio.h>
+ #include <stdlib.h>
+-#include <uchar.h>
+ #include <unistd.h>
+ 
+ #define  _(String) gettext (String)
+-- 
+2.10.2
+
package/efibootmgr/Config.in +1 -2
index 988bf6d..8860e5d 100644
@@ -1,10 +1,10 @@
 config BR2_PACKAGE_EFIBOOTMGR
 	bool "efibootmgr"
 	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12 # efivar
-	depends on BR2_TOOLCHAIN_USES_GLIBC # efivar
 	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9 # efivar
 	depends on !BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS && \
 		!BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII # efivar
+	select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT
 	select BR2_PACKAGE_EFIVAR
 	help
 	  A Linux user-space application to modify the Intel Extensible
@@ -16,7 +16,6 @@ config BR2_PACKAGE_EFIBOOTMGR
 
 comment "efibootmgr requires a glibc toolchain w/ headers >= 3.12, gcc >= 4.9"
 	depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12 || \
-		!BR2_TOOLCHAIN_USES_GLIBC || \\
 		!BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
 	depends on !BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS && \
 		!BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII
package/efibootmgr/efibootmgr.mk +5 -3
index 731d6e9..487c8ca 100644
@@ -8,7 +8,8 @@ EFIBOOTMGR_VERSION = 14
 EFIBOOTMGR_SITE = $(call github,rhinstaller,efibootmgr,$(EFIBOOTMGR_VERSION))
 EFIBOOTMGR_LICENSE = GPLv2+
 EFIBOOTMGR_LICENSE_FILES = COPYING
-EFIBOOTMGR_DEPENDENCIES = efivar
+EFIBOOTMGR_DEPENDENCIES = efivar $(if $(BR2_NEEDS_GETTEXT),gettext)
+EFIBOOTMGR_LDFLAGS = $(TARGET_LDFLAGS) $(if $(BR2_NEEDS_GETTEXT),-lintl)
 
 define EFIBOOTMSR_PATCH_HEADER_PATH
 	$(SED) 's,-I/,-I$(STAGING_DIR)/,' $(@D)/Makefile
@@ -17,11 +18,12 @@ endef
 EFIBOOTMGR_POST_PATCH_HOOKS += EFIBOOTMSR_PATCH_HEADER_PATH
 
 define EFIBOOTMGR_BUILD_CMDS
-	$(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS) $(MAKE1) -C $(@D)
+	$(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS)			\
+		LDFLAGS="$(EFIBOOTMGR_LDFLAGS)" $(MAKE1) -C $(@D)
 endef
 
 define EFIBOOTMGR_INSTALL_TARGET_CMDS
-	$(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D) \
+	$(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D)	\
 		DESTDIR=$(TARGET_DIR) install
 endef
 
Signature · 1 line
2.10.2
#7 lore raw

cover efibootmgr: build with uClibc

In reply to Andy Shevchenko

Hello,

Quoted 10 lines · Andy Shevchenko

These patches make possible to use efibootmgr with uClibc. All patches had been sent to upstream.

I have tested in my environment that doesn't use unicode characters. So, any additional tests are appreciated.

Andy Shevchenko (3):
efivar: bump to version 30
efivar: allow build with uClibc
efibootmrg: Allow build with uClibc

Why did you resend those patches? You already sent them yesterday, and I already applied them to our next branch. I even made some comments, which are anyway not taken into account in this new iteration.

Thanks,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
#8 lore raw

cover efibootmgr: build with uClibc

Quoted 11 lines · Thomas Petazzoni

Hello,

Quoted 8 lines · Andy Shevchenko

These patches make possible to use efibootmgr with uClibc. All patches had been
sent to upstream.

I have tested in my environment that doesn't use unicode characters. So, any
additional tests are appreciated.

Quoted 8 lines
Quoted 4 lines

Andy Shevchenko (3):
? efivar: bump to version 30
? efivar: allow build with uClibc
? efibootmrg: Allow build with uClibc

Why did you resend those patches? You already sent them yesterday, and I already applied them to our next branch. I even made some comments, which are anyway not taken into account in this new iteration.

Sorry for a noise, I just now realized that mail infra on my side moved your messages to junk. That's why I resend since I didn't hear from anyone anything. Now I know the root cause.

Signature · 2 lines
Andy Shevchenko <[email protected]>
Intel Finland Oy