When writing a test for fusectl, I referred to this Makefile as a reference for creating a FUSE daemon in the selftests. While doing so, I noticed that there is a minor issue in the Makefile.
The fuse_mnt.c file is not actually compiled into fuse_mnt.o, and the code setting CFLAGS for it never takes effect. The reason fuse_mnt compiles successfully is because CFLAGS is set at the very beginning of the file.
Signed-off-by: Chen Linxuan chenlinxuan@uniontech.com --- tools/testing/selftests/memfd/Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/testing/selftests/memfd/Makefile b/tools/testing/selftests/memfd/Makefile index 163b6f68631c4..e9b886c65153d 100644 --- a/tools/testing/selftests/memfd/Makefile +++ b/tools/testing/selftests/memfd/Makefile @@ -1,5 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 -CFLAGS += -D_FILE_OFFSET_BITS=64 CFLAGS += $(KHDR_INCLUDES)
TEST_GEN_PROGS := memfd_test @@ -16,10 +15,9 @@ ifeq ($(VAR_LDLIBS),) VAR_LDLIBS := -lfuse -pthread endif
-fuse_mnt.o: CFLAGS += $(VAR_CFLAGS) - include ../lib.mk
+$(OUTPUT)/fuse_mnt: CFLAGS += $(VAR_CFLAGS) $(OUTPUT)/fuse_mnt: LDLIBS += $(VAR_LDLIBS)
$(OUTPUT)/memfd_test: memfd_test.c common.c
On 6/9/25 20:05, Chen Linxuan wrote:
When writing a test for fusectl, I referred to this Makefile as a reference for creating a FUSE daemon in the selftests. While doing so, I noticed that there is a minor issue in the Makefile.
What happens if this change isn't made?
The fuse_mnt.c file is not actually compiled into fuse_mnt.o, and the code setting CFLAGS for it never takes effect. The reason fuse_mnt compiles successfully is because CFLAGS is set at the very beginning of the file.
Signed-off-by: Chen Linxuan chenlinxuan@uniontech.com
tools/testing/selftests/memfd/Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/testing/selftests/memfd/Makefile b/tools/testing/selftests/memfd/Makefile index 163b6f68631c4..e9b886c65153d 100644 --- a/tools/testing/selftests/memfd/Makefile +++ b/tools/testing/selftests/memfd/Makefile @@ -1,5 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 -CFLAGS += -D_FILE_OFFSET_BITS=64
What's the reason for deleting the above?
CFLAGS += $(KHDR_INCLUDES) TEST_GEN_PROGS := memfd_test @@ -16,10 +15,9 @@ ifeq ($(VAR_LDLIBS),) VAR_LDLIBS := -lfuse -pthread endif -fuse_mnt.o: CFLAGS += $(VAR_CFLAGS)
- include ../lib.mk
+$(OUTPUT)/fuse_mnt: CFLAGS += $(VAR_CFLAGS) $(OUTPUT)/fuse_mnt: LDLIBS += $(VAR_LDLIBS) $(OUTPUT)/memfd_test: memfd_test.c common.c
thanks, -- Shuah
On Thu, Jun 19, 2025 at 5:21 AM Shuah Khan skhan@linuxfoundation.org wrote:
On 6/9/25 20:05, Chen Linxuan wrote:
When writing a test for fusectl, I referred to this Makefile as a reference for creating a FUSE daemon in the selftests. While doing so, I noticed that there is a minor issue in the Makefile.
What happens if this change isn't made?
Nothing will happen. When I was writing tests for the fusectl filesystem in the kernel repository, I came across this file as a reference. Then I found that the process of passing CFLAGS was not correct. So, for the reason of not wanting others to be misled again, I want to update the compilation process here.
The fuse_mnt.c file is not actually compiled into fuse_mnt.o, and the code setting CFLAGS for it never takes effect. The reason fuse_mnt compiles successfully is because CFLAGS is set at the very beginning of the file.
Signed-off-by: Chen Linxuan chenlinxuan@uniontech.com
tools/testing/selftests/memfd/Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/testing/selftests/memfd/Makefile b/tools/testing/selftests/memfd/Makefile index 163b6f68631c4..e9b886c65153d 100644 --- a/tools/testing/selftests/memfd/Makefile +++ b/tools/testing/selftests/memfd/Makefile @@ -1,5 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 -CFLAGS += -D_FILE_OFFSET_BITS=64
What's the reason for deleting the above?
The CFLAGS update here actually doesn't take effect. I believe it is the -D_FILE_OFFSET_BITS=64 in VAR_CFLAGS that truly takes effect.
CFLAGS += $(KHDR_INCLUDES)
TEST_GEN_PROGS := memfd_test @@ -16,10 +15,9 @@ ifeq ($(VAR_LDLIBS),) VAR_LDLIBS := -lfuse -pthread endif
-fuse_mnt.o: CFLAGS += $(VAR_CFLAGS)
- include ../lib.mk
+$(OUTPUT)/fuse_mnt: CFLAGS += $(VAR_CFLAGS) $(OUTPUT)/fuse_mnt: LDLIBS += $(VAR_LDLIBS)
$(OUTPUT)/memfd_test: memfd_test.c common.c
thanks, -- Shuah
On 6/19/25 01:43, Chen Linxuan wrote:
On Thu, Jun 19, 2025 at 5:21 AM Shuah Khan skhan@linuxfoundation.org wrote:
On 6/9/25 20:05, Chen Linxuan wrote:
When writing a test for fusectl, I referred to this Makefile as a reference for creating a FUSE daemon in the selftests. While doing so, I noticed that there is a minor issue in the Makefile.
What happens if this change isn't made?
Nothing will happen. When I was writing tests for the fusectl filesystem in the kernel repository, I came across this file as a reference. Then I found that the process of passing CFLAGS was not correct. So, for the reason of not wanting others to be misled again, I want to update the compilation process here.
If there is no obvious reason then let's not make this change.
thanks, -- Shuah
On Fri, Jun 20, 2025 at 1:02 AM Shuah Khan skhan@linuxfoundation.org wrote:
On 6/19/25 01:43, Chen Linxuan wrote:
On Thu, Jun 19, 2025 at 5:21 AM Shuah Khan skhan@linuxfoundation.org wrote:
On 6/9/25 20:05, Chen Linxuan wrote:
When writing a test for fusectl, I referred to this Makefile as a reference for creating a FUSE daemon in the selftests. While doing so, I noticed that there is a minor issue in the Makefile.
What happens if this change isn't made?
Nothing will happen. When I was writing tests for the fusectl filesystem in the kernel repository, I came across this file as a reference. Then I found that the process of passing CFLAGS was not correct. So, for the reason of not wanting others to be misled again, I want to update the compilation process here.
If there is no obvious reason then let's not make this change.
Once https://lore.kernel.org/all/20250612094033.2538122-2-chenlinxuan@uniontech.c... gets merged, there will be another example of compiling fuse in selftests in the kernel. So I think it's not a big problem if we don't make this change here.
thanks, Chen Linxuan
thanks, -- Shuah
linux-kselftest-mirror@lists.linaro.org
-
Chen Linxuan -
Shuah Khan