kbuild: Make --build-id linker flag configurable
Subsystems (6)
RFC PATCH 1/1 kbuild: Make --build-id linker flag configurable
Build ID hashes include file paths, so building the same source from different directories produces different binaries. This breaks reproducible builds.
Add KBUILD_BUILD_ID variable (default: sha1) to allow overriding:
make KBUILD_BUILD_ID=none
The variable is exported to VDSO Makefiles which also include a fallback default for standalone invocation.
---
Hi,
Sending this change for RFC, as it is quite possible that this is a generic problem and I may be missing something.
I am trying to implement reproducible builds for one of my product kernel. I referred https://reproducible-builds.org/docs/build-path/
and tried to use both -fdebug-prefix-map=OLD=NEW and -fmacro-prefix-map=OLD=NEW, but still could not achieve bit by bit binary reproducibility without overwriting build-id to none. If I move the kernel to same path in other setup, I was able to create same binary hash, however, without it, there is some difference in build-id hash values.
Reproducibility wiki says "In most cases however, post-processing is required to either remove the build path or to normalize it to a predefined value.". I have tried that, and it works, but wanted to conclude if that is my last option here.
Thanks.
--- Makefile | 8 ++++++-- arch/arm64/kernel/vdso/Makefile | 5 ++++- arch/arm64/kernel/vdso32/Makefile | 5 ++++- arch/x86/entry/vdso/Makefile | 5 ++++- 4 files changed, 18 insertions(+), 5 deletions(-)
Makefile +6 -2
@@ -1132,8 +1132,12 @@ KBUILD_AFLAGS += $(KAFLAGS) KBUILD_CFLAGS += $(KCFLAGS) KBUILD_RUSTFLAGS += $(KRUSTFLAGS) -KBUILD_LDFLAGS_MODULE += --build-id=sha1 -LDFLAGS_vmlinux += --build-id=sha1 +# Can be overridden for reproducible builds by using "make KBUILD_BUILD_ID=none" +KBUILD_BUILD_ID ?= sha1 +export KBUILD_BUILD_ID + +KBUILD_LDFLAGS_MODULE += --build-id=$(KBUILD_BUILD_ID) +LDFLAGS_vmlinux += --build-id=$(KBUILD_BUILD_ID) KBUILD_LDFLAGS += -z noexecstack ifeq ($(CONFIG_LD_IS_BFD),y)
arch/arm64/kernel/vdso/Makefile +4 -1
@@ -9,6 +9,9 @@ # Include the generic Makefile to check the built vdso. include $(srctree)/lib/vdso/Makefile.include +# Fallback for standalone builds, normally inherited from top-level Makefile +KBUILD_BUILD_ID ?= sha1 + obj-vdso := vgettimeofday.o note.o sigreturn.o vgetrandom.o vgetrandom-chacha.o # Build rules
@@ -22,7 +25,7 @@ btildflags-$(CONFIG_ARM64_BTI_KERNEL) += -z force-bti # routines, as x86 does (see 6f121e548f83 ("x86, vdso: Reimplement vdso.so # preparation in build-time C")). ldflags-y := -shared -soname=linux-vdso.so.1 \ - -Bsymbolic --build-id=sha1 -n $(btildflags-y) + -Bsymbolic --build-id=$(KBUILD_BUILD_ID) -n $(btildflags-y) ifdef CONFIG_LD_ORPHAN_WARN ldflags-y += --orphan-handling=$(CONFIG_LD_ORPHAN_WARN_LEVEL)
arch/arm64/kernel/vdso32/Makefile +4 -1
@@ -5,6 +5,9 @@ include $(srctree)/lib/vdso/Makefile.include +# Fallback for standalone builds, normally inherited from top-level Makefile +KBUILD_BUILD_ID ?= sha1 + # Same as cc-*option, but using CC_COMPAT instead of CC ifeq ($(CONFIG_CC_IS_CLANG), y) CC_COMPAT ?= $(CC)
@@ -87,7 +90,7 @@ VDSO_AFLAGS += -D__ASSEMBLY__ # From arm vDSO Makefile VDSO_LDFLAGS += -Bsymbolic --no-undefined -soname=linux-vdso.so.1 VDSO_LDFLAGS += -z max-page-size=4096 -z common-page-size=4096 -VDSO_LDFLAGS += -shared --build-id=sha1 +VDSO_LDFLAGS += -shared --build-id=$(KBUILD_BUILD_ID) VDSO_LDFLAGS += --orphan-handling=$(CONFIG_LD_ORPHAN_WARN_LEVEL)
arch/x86/entry/vdso/Makefile +4 -1
@@ -6,6 +6,9 @@ # Include the generic Makefile to check the built vDSO: include $(srctree)/lib/vdso/Makefile.include +# Fallback for standalone builds, normally inherited from top-level Makefile +KBUILD_BUILD_ID ?= sha1 + # Files to link into the vDSO: vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vgetrandom.o vgetrandom-chacha.o vobjs32-y := vdso32/note.o vdso32/system_call.o vdso32/sigreturn.o
@@ -155,7 +158,7 @@ quiet_cmd_vdso = VDSO $@ $(VDSO_LDFLAGS) $(VDSO_LDFLAGS_$(filter %.lds,$(^F))) \ -T $(filter %.lds,$^) $(filter %.o,$^) -VDSO_LDFLAGS = -shared --hash-style=both --build-id=sha1 --no-undefined \ +VDSO_LDFLAGS = -shared --hash-style=both --build-id=$(KBUILD_BUILD_ID) --no-undefined \ $(call ld-option, --eh-frame-hdr) -Bsymbolic -z noexecstack quiet_cmd_vdso_and_check = VDSO $@
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
Signature · 1 line
2.43.0
Hi Naman,
Quoted 17 lines · Naman Jain
Build ID hashes include file paths, so building the same source from different directories produces different binaries. This breaks reproducible builds.
Add
KBUILD_BUILD_IDvariable (default: sha1) to allow overriding:make KBUILD_BUILD_ID=none
The variable is exported to VDSO Makefiles which also include a fallback default for standalone invocation.
Signed-off-by Naman Jain <[email protected]>---
Hi,
Sending this change for RFC, as it is quite possible that this is a generic problem and I may be missing something.
Quoted 8 lines
I am trying to implement reproducible builds for one of my product kernel. I referred https://reproducible-builds.org/docs/build-path/
and tried to use both -fdebug-prefix-map=OLD=NEW and -fmacro-prefix-map=OLD=NEW, but still could not achieve bit by bit binary reproducibility without overwriting build-id to none. If I move the kernel to same path in other setup, I was able to create same binary hash, however, without it, there is some difference in build-id hash values.
Can you force the same build path during package building? That should avoid this issue.
Quoted 4 lines
Reproducibility wiki says "In most cases however, post-processing is required to either remove the build path or to normalize it to a predefined value.". I have tried that, and it works, but wanted to conclude if that is my last option here.
I am not a fan of this aproach. The build id should stay usable. Can you figure out where the build paths are used?
You may need to also compare the debug symbols.
Quoted 33 lines
Thanks.
--- Makefile | 8 ++++++-- arch/arm64/kernel/vdso/Makefile | 5 ++++- arch/arm64/kernel/vdso32/Makefile | 5 ++++- arch/x86/entry/vdso/Makefile | 5 ++++- 4 files changed, 18 insertions(+), 5 deletions(-)Makefile +6
-2@@ -1132,8 +1132,12 @@ KBUILD_AFLAGS += $(KAFLAGS) KBUILD_CFLAGS += $(KCFLAGS) KBUILD_RUSTFLAGS += $(KRUSTFLAGS) -KBUILD_LDFLAGS_MODULE += --build-id=sha1 -LDFLAGS_vmlinux += --build-id=sha1 +# Can be overridden for reproducible builds by using "make KBUILD_BUILD_ID=none" +KBUILD_BUILD_ID ?= sha1 +export KBUILD_BUILD_ID + +KBUILD_LDFLAGS_MODULE += --build-id=$(KBUILD_BUILD_ID) +LDFLAGS_vmlinux += --build-id=$(KBUILD_BUILD_ID) KBUILD_LDFLAGS += -z noexecstack ifeq ($(CONFIG_LD_IS_BFD),y)arch/arm64/kernel/vdso/Makefile +0
-0
arch/arm64/kernel/vdso/Makefile line 14
Quoted 6 lines
arch/arm64/kernel/vdso/Makefile +3
-0@@ -9,6 +9,9 @@ # Include the generic Makefile to check the built vdso. include $(srctree)/lib/vdso/Makefile.include +# Fallback for standalone builds, normally inherited from top-level Makefile +KBUILD_BUILD_ID ?= sha1 +
What kind of standalone builds?
This doesn't look like it belongs into this patch.
(...)
Nathan Chancellor
maintainerQuoted 10 lines · Thomas Weißschuh
Quoted 8 lines · Naman Jain
I am trying to implement reproducible builds for one of my product kernel. I referred https://reproducible-builds.org/docs/build-path/
and tried to use both -fdebug-prefix-map=OLD=NEW and -fmacro-prefix-map=OLD=NEW, but still could not achieve bit by bit binary reproducibility without overwriting build-id to none. If I move the kernel to same path in other setup, I was able to create same binary hash, however, without it, there is some difference in build-id hash values.
Quoted 2 lines
Can you force the same build path during package building? That should avoid this issue.
Yeah, I think that it would be better to document this in Documentation/kbuild/reproducible-builds.rst, as opposed to adding a hack to disable the build ID altogether. It seems easy enough to make the paths consistent between machines and environments by using a container or such. The new scripts/container in -next could help there.
Cheers,
Nathan
Quoted 14 lines · Nathan Chancellor
Quoted 10 lines · Thomas Weißschuh
Quoted 8 lines · Naman Jain
I am trying to implement reproducible builds for one of my product kernel. I referred https://reproducible-builds.org/docs/build-path/
and tried to use both -fdebug-prefix-map=OLD=NEW and -fmacro-prefix-map=OLD=NEW, but still could not achieve bit by bit binary reproducibility without overwriting build-id to none. If I move the kernel to same path in other setup, I was able to create same binary hash, however, without it, there is some difference in build-id hash values.Quoted 2 lines
Can you force the same build path during package building? That should avoid this issue.
Quoted 8 lines
Yeah, I think that it would be better to document this in
Documentation/kbuild/reproducible-builds.rst, as opposed to adding a hack to disable the build ID altogether. It seems easy enough to make the paths consistent between machines and environments by using a container or such. The newscripts/containerin -next could help there.Cheers,
Nathan
Thank you Nathan for your inputs.
I'll plan to ensure same path for my kernel build, and send a patch to add this in reproducible builds documentation.
Documentation/kbuild/reproducible-builds.rst +3 -0
@@ -58,6 +58,9 @@ to an absolute filename in an out-of-tree build. Kbuild automatically uses the ``-fmacro-prefix-map`` option to prevent this, if it is supported. +If it still does not work, ensure that the kernel is built in the same +directory, using containers or such. + The Reproducible Builds web site has more information about these `prefix-map options`_.
Regards,
Naman
Quoted 29 lines · Thomas Weißschuh
Hi Naman,
Quoted 25 lines · Naman Jain
Build ID hashes include file paths, so building the same source from different directories produces different binaries. This breaks reproducible builds.
Add
KBUILD_BUILD_IDvariable (default: sha1) to allow overriding:make KBUILD_BUILD_ID=none
The variable is exported to VDSO Makefiles which also include a fallback default for standalone invocation.
Signed-off-by Naman Jain <[email protected]>---
Hi,
Sending this change for RFC, as it is quite possible that this is a generic problem and I may be missing something.I am trying to implement reproducible builds for one of my product kernel. I referred https://reproducible-builds.org/docs/build-path/
and tried to use both -fdebug-prefix-map=OLD=NEW and -fmacro-prefix-map=OLD=NEW, but still could not achieve bit by bit binary reproducibility without overwriting build-id to none. If I move the kernel to same path in other setup, I was able to create same binary hash, however, without it, there is some difference in build-id hash values.
Hi Thomas,
Thanks for looking into this and sharing your inputs.
Quoted 2 lines
Can you force the same build path during package building? That should avoid this issue.
Since we can't control where the user would clone their kernel, I was initially skeptical to copy the kernel to a same build path like /tmp/kernel/src directory due to uncertainties related to free space, permissions, but I tried it now and it works fine. It should be OK for my use-case.
I am currently using NixOS for reproducible build environment.
Quoted 11 lines
Quoted 5 lines
Reproducibility wiki says "In most cases however, post-processing is required to either remove the build path or to normalize it to a predefined value.". I have tried that, and it works, but wanted to conclude if that is my last option here.
I am not a fan of this aproach. The build id should stay usable. Can you figure out where the build paths are used?
You may need to also compare the debug symbols.Quoted 1 line
Thanks.
I agree.
We did not have any use of these build paths, but some vendors may be using it to fetch the build information from the binaries. If your comment was about in-kernel usage of these build paths, I'll look into it.
Quoted 35 lines
Quoted 35 lines
--- Makefile | 8 ++++++-- arch/arm64/kernel/vdso/Makefile | 5 ++++- arch/arm64/kernel/vdso32/Makefile | 5 ++++- arch/x86/entry/vdso/Makefile | 5 ++++- 4 files changed, 18 insertions(+), 5 deletions(-)Makefile +6
-2@@ -1132,8 +1132,12 @@ KBUILD_AFLAGS += $(KAFLAGS) KBUILD_CFLAGS += $(KCFLAGS) KBUILD_RUSTFLAGS += $(KRUSTFLAGS) -KBUILD_LDFLAGS_MODULE += --build-id=sha1 -LDFLAGS_vmlinux += --build-id=sha1 +# Can be overridden for reproducible builds by using "make KBUILD_BUILD_ID=none" +KBUILD_BUILD_ID ?= sha1 +export KBUILD_BUILD_ID + +KBUILD_LDFLAGS_MODULE += --build-id=$(KBUILD_BUILD_ID) +LDFLAGS_vmlinux += --build-id=$(KBUILD_BUILD_ID) KBUILD_LDFLAGS += -z noexecstack ifeq ($(CONFIG_LD_IS_BFD),y)arch/arm64/kernel/vdso/Makefile +0
-0@@ -9,6 +9,9 @@ # Include the generic Makefile to check the built vdso. include $(srctree)/lib/vdso/Makefile.include
Quoted 8 lines
arch/arm64/kernel/vdso/Makefile line 14
Quoted 3 lines
arch/arm64/kernel/vdso/Makefile +3
-0+# Fallback for standalone builds, normally inherited from top-level Makefile +KBUILD_BUILD_ID ?= sha1 +What kind of standalone builds?
This doesn't look like it belongs into this patch.(...)
The case I was trying to cover here was when we try to compile arch/x86/entry/vdso/ separately, without the KBUILD_BUILD_ID coming from main build scripts, "--build-id=" would be left empty, while we may want to retain original value i.e. sha1.
make ARCH=x86_64 arch/x86/entry/vdso/
arch/x86/entry/vdso/Makefile:
-VDSO_LDFLAGS = -shared --hash-style=both --build-id=sha1 --no-undefined \
+VDSO_LDFLAGS = -shared --hash-style=both --build-id=$(KBUILD_BUILD_ID) --no-undefined \
Anyways, this may not be required now.
Regards,
Naman
Quoted 38 lines · Naman Jain
Quoted 29 lines · Thomas Weißschuh
Hi Naman,
Quoted 25 lines · Naman Jain
Build ID hashes include file paths, so building the same source from different directories produces different binaries. This breaks reproducible builds.
Add
KBUILD_BUILD_IDvariable (default: sha1) to allow overriding:make KBUILD_BUILD_ID=none
The variable is exported to VDSO Makefiles which also include a fallback default for standalone invocation.
Signed-off-by Naman Jain <[email protected]>---
Hi,
Sending this change for RFC, as it is quite possible that this is a generic problem and I may be missing something.I am trying to implement reproducible builds for one of my product kernel. I referred https://reproducible-builds.org/docs/build-path/
and tried to use both -fdebug-prefix-map=OLD=NEW and -fmacro-prefix-map=OLD=NEW, but still could not achieve bit by bit binary reproducibility without overwriting build-id to none. If I move the kernel to same path in other setup, I was able to create same binary hash, however, without it, there is some difference in build-id hash values.Hi Thomas,
Thanks for looking into this and sharing your inputs.Quoted 2 lines
Can you force the same build path during package building? That should avoid this issue.
Quoted 7 lines
Since we can't control where the user would clone their kernel, I was initially skeptical to copy the kernel to a same build path like
/tmp/kernel/srcdirectory due to uncertainties related to free space, permissions, but I tried it now and it works fine. It should be OK for my use-case.I am currently using NixOS for reproducible build environment.
So users are already forced to use a specific distribution for rebuilding. Also requiring a specific build path doesn't look like a big step then.
Quoted 9 lines
Quoted 9 lines
Quoted 4 lines
Reproducibility wiki says "In most cases however, post-processing is required to either remove the build path or to normalize it to a predefined value.". I have tried that, and it works, but wanted to conclude if that is my last option here.
I am not a fan of this aproach. The build id should stay usable. Can you figure out where the build paths are used?
You may need to also compare the debug symbols.
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Thanks.
I agree.
We did not have any use of these build paths, but some vendors may be using it to fetch the build information from the binaries.
If your comment was about in-kernel usage of these build paths, I'll look into it.
I'd like to know where the build paths in the binary are coming from. So we can fix the issue properly instead of working around it.
You said you are using -fmacro-prefix-map and -fdebug-prefix-map to avoid them. (There is also -ffile-prefix-map which should be more robust and easy to use)
Quoted 38 lines
Quoted 38 lines
Quoted 29 lines
--- Makefile | 8 ++++++-- arch/arm64/kernel/vdso/Makefile | 5 ++++- arch/arm64/kernel/vdso32/Makefile | 5 ++++- arch/x86/entry/vdso/Makefile | 5 ++++- 4 files changed, 18 insertions(+), 5 deletions(-)Makefile +6
-2@@ -1132,8 +1132,12 @@ KBUILD_AFLAGS += $(KAFLAGS) KBUILD_CFLAGS += $(KCFLAGS) KBUILD_RUSTFLAGS += $(KRUSTFLAGS) -KBUILD_LDFLAGS_MODULE += --build-id=sha1 -LDFLAGS_vmlinux += --build-id=sha1 +# Can be overridden for reproducible builds by using "make KBUILD_BUILD_ID=none" +KBUILD_BUILD_ID ?= sha1 +export KBUILD_BUILD_ID + +KBUILD_LDFLAGS_MODULE += --build-id=$(KBUILD_BUILD_ID) +LDFLAGS_vmlinux += --build-id=$(KBUILD_BUILD_ID) KBUILD_LDFLAGS += -z noexecstack ifeq ($(CONFIG_LD_IS_BFD),y)arch/arm64/kernel/vdso/Makefile +0
-0arch/arm64/kernel/vdso/Makefile line 13
Quoted 5 lines
arch/arm64/kernel/vdso/Makefile +3
-0@@ -9,6 +9,9 @@ # Include the generic Makefile to check the built vdso. include $(srctree)/lib/vdso/Makefile.include +# Fallback for standalone builds, normally inherited from top-level Makefile +KBUILD_BUILD_ID ?= sha1 +What kind of standalone builds?
This doesn't look like it belongs into this patch.
Quoted 8 lines
Quoted 1 line
(...)
The case I was trying to cover here was when we try to compile
arch/x86/entry/vdso/separately, without theKBUILD_BUILD_IDcoming from main build scripts, "--build-id=" would be left empty, while we may want to retain original value i.e. sha1.make ARCH=x86_64 arch/x86/entry/vdso/
I don't think this is or should be supported.
Quoted 6 lines
arch/x86/entry/vdso/Makefile:(quoted diff) +1
-2-VDSO_LDFLAGS = -shared --hash-style=both --build-id=sha1 --no-undefined \ +VDSO_LDFLAGS = -shared --hash-style=both --build-id=$(KBUILD_BUILD_ID) --no-undefined \Anyways, this may not be required now.
Thomas
Quoted 45 lines · Thomas Weißschuh
Quoted 44 lines · Naman Jain
Quoted 29 lines · Thomas Weißschuh
Hi Naman,
Quoted 25 lines · Naman Jain
Build ID hashes include file paths, so building the same source from different directories produces different binaries. This breaks reproducible builds.
Add
KBUILD_BUILD_IDvariable (default: sha1) to allow overriding:make KBUILD_BUILD_ID=none
The variable is exported to VDSO Makefiles which also include a fallback default for standalone invocation.
Signed-off-by Naman Jain <[email protected]>---
Hi,
Sending this change for RFC, as it is quite possible that this is a generic problem and I may be missing something.I am trying to implement reproducible builds for one of my product kernel. I referred https://reproducible-builds.org/docs/build-path/
and tried to use both -fdebug-prefix-map=OLD=NEW and -fmacro-prefix-map=OLD=NEW, but still could not achieve bit by bit binary reproducibility without overwriting build-id to none. If I move the kernel to same path in other setup, I was able to create same binary hash, however, without it, there is some difference in build-id hash values.Hi Thomas,
Thanks for looking into this and sharing your inputs.Quoted 2 lines
Can you force the same build path during package building? That should avoid this issue.
Since we can't control where the user would clone their kernel, I was initially skeptical to copy the kernel to a same build path like
/tmp/kernel/srcdirectory due to uncertainties related to free space, permissions, but I tried it now and it works fine. It should be OK for my use-case.
Quoted 4 lines
Quoted 1 line
I am currently using NixOS for reproducible build environment.
So users are already forced to use a specific distribution for rebuilding. Also requiring a specific build path doesn't look like a big step then.
Ack.
Quoted 18 lines
Quoted 10 lines
Quoted 10 lines
Quoted 5 lines
Reproducibility wiki says "In most cases however, post-processing is required to either remove the build path or to normalize it to a predefined value.". I have tried that, and it works, but wanted to conclude if that is my last option here.
I am not a fan of this aproach. The build id should stay usable. Can you figure out where the build paths are used?
You may need to also compare the debug symbols.Quoted 7 lines
Quoted 1 line
Quoted 1 line
Thanks.
I agree.
We did not have any use of these build paths, but some vendors may be using it to fetch the build information from the binaries.
If your comment was about in-kernel usage of these build paths, I'll look into it.
Quoted 4 lines
I'd like to know where the build paths in the binary are coming from. So we can fix the issue properly instead of working around it.
You said you are using -fmacro-prefix-map and -fdebug-prefix-map to avoid them. (There is also -ffile-prefix-map which should be more robust and easy to use)
I was suspecting these are coming from linker scripts, in VDSO compilation but I could not pin-point to the real issue here. I will check more to find out what exactly is missing here.
Quoted 41 lines
Quoted 41 lines
Quoted 40 lines
Quoted 30 lines
--- Makefile | 8 ++++++-- arch/arm64/kernel/vdso/Makefile | 5 ++++- arch/arm64/kernel/vdso32/Makefile | 5 ++++- arch/x86/entry/vdso/Makefile | 5 ++++- 4 files changed, 18 insertions(+), 5 deletions(-)Makefile +6
-2@@ -1132,8 +1132,12 @@ KBUILD_AFLAGS += $(KAFLAGS) KBUILD_CFLAGS += $(KCFLAGS) KBUILD_RUSTFLAGS += $(KRUSTFLAGS) -KBUILD_LDFLAGS_MODULE += --build-id=sha1 -LDFLAGS_vmlinux += --build-id=sha1 +# Can be overridden for reproducible builds by using "make KBUILD_BUILD_ID=none" +KBUILD_BUILD_ID ?= sha1 +export KBUILD_BUILD_ID + +KBUILD_LDFLAGS_MODULE += --build-id=$(KBUILD_BUILD_ID) +LDFLAGS_vmlinux += --build-id=$(KBUILD_BUILD_ID) KBUILD_LDFLAGS += -z noexecstack ifeq ($(CONFIG_LD_IS_BFD),y)arch/arm64/kernel/vdso/Makefile +0
-0arch/arm64/kernel/vdso/Makefile line 13
Quoted 5 lines
arch/arm64/kernel/vdso/Makefile +3
-0@@ -9,6 +9,9 @@ # Include the generic Makefile to check the built vdso. include $(srctree)/lib/vdso/Makefile.include +# Fallback for standalone builds, normally inherited from top-level Makefile +KBUILD_BUILD_ID ?= sha1 +What kind of standalone builds?
This doesn't look like it belongs into this patch.(...)
Quoted 8 lines
Quoted 6 lines
The case I was trying to cover here was when we try to compile
arch/x86/entry/vdso/separately, without theKBUILD_BUILD_IDcoming from main build scripts, "--build-id=" would be left empty, while we may want to retain original value i.e. sha1.make ARCH=x86_64 arch/x86/entry/vdso/I don't think this is or should be supported.
Ack.
Quoted 10 lines
Quoted 7 lines
arch/x86/entry/vdso/Makefile:(quoted diff) +1
-2-VDSO_LDFLAGS = -shared --hash-style=both --build-id=sha1 --no-undefined \ +VDSO_LDFLAGS = -shared --hash-style=both --build-id=$(KBUILD_BUILD_ID) --no-undefined \Anyways, this may not be required now.
Thomas
Regards,
Naman