Skip to content

make -e discards src/Makefile's -fsigned-char, breaking the aarch64 Linux build #59

Description

@BenjaminDEMAILLE

Building v2.03 on ARM Linux (aarch64, Ubuntu 22.04, gcc 11.4) fails in chain.c:

g++ -c  -g -Wall -O2 -DHAVE_KALLOC -fopenmp -std=c++11 -Wno-sign-compare -Wno-write-strings -Wno-unused-but-set-variable -fno-tree-vectorize -Isse2neon chain.c -o chain.o
chain.c:13:1: error: narrowing conversion of '-1' from 'int' to 'char' [-Wnarrowing]
   13 | };
      | ^
make[1]: *** [Makefile:35: chain.o] Error 1
make: *** [Makefile:8: winnowmap] Error 2

Reproduced with:

make arm_neon=1 aarch64=1

src/Makefile already anticipates this and adds -fsigned-char for aarch64:

ifeq ($(aarch64),)	#if aarch64 is not defined
	CPPFLAGS+=-D_FILE_OFFSET_BITS=64 -mfpu=neon -fsigned-char
else				#if aarch64 is defined
	CPPFLAGS+=-D_FILE_OFFSET_BITS=64 -fsigned-char
endif

However that append never reaches the compiler. The top-level Makefile exports CPPFLAGS and invokes the sub-make with -e:

export CPPFLAGS= -g -Wall -O2 -DHAVE_KALLOC -fopenmp -std=c++11 ...
winnowmap: MAKE_DIRS
	+$(MAKE) -e -C src

-e (--environment-overrides) gives environment variables precedence over makefile assignments, so the exported CPPFLAGS wins and every CPPFLAGS+= in src/Makefile is discarded. INCLUDES+=-Isse2neon from the same block does apply, because INCLUDES is not exported. That is why the failing compile line above carries -Isse2neon but neither -fsigned-char nor -D_FILE_OFFSET_BITS=64.

This is only visible where char is unsigned by default, i.e. ARM Linux. On arm64 macOS and on x86 char is signed, so the missing flag goes unnoticed there.

Dropping -e is sufficient: without it, CPPFLAGS+= appends to the exported value as intended.

 winnowmap: MAKE_DIRS
-	+$(MAKE) -e -C src
+	+$(MAKE) -C src

With that one-line change on aarch64 Linux, -fsigned-char appears on the chain.c compile line, the build completes, and the result works:

$ winnowmap -ax map-ont ref.fa reads.fq
r1	0	ref	41	60	120M	...

The same change is a no-op on x86_64 Linux and on macOS, where both builds still complete and run correctly.

Found while packaging Winnowmap for Homebrew, where the ARM Linux build is a supported target. Happy to open a PR if the fix looks right to you.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions