Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
src/Makefile: do not override LIBS and CFLAGS for prerequisites
Without the change `make --shuffle` build occasionally fails as: $ gcc -Og -g3 -Wall -Wextra -Werror -std=gnu11 -funsigned-char -fvisibility=hidden -specs=/build/source/src/include/gcc.specs -fno-merge-constants -L. -Wl,--build-id -Wl,--no-allow-shlib-undefined -Wl,--no-undefined-version -Wl,-z,now -Wl,-z,muldefs -Wl,-z,relro -Wl,--fatal-warnings -DLIBEFIVAR_VERSION=38 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I/build/source/src/include/ -shared -Wl,-soname,libefisec.so.1 -Wl,--version-script=libefisec.map -o libefisec.so sec.o secdb.o esl-iter.o util.o -lefivar -lefisec -ldl /nix/store/zwqkxpi1iz66mix0kirdaq2ps6a9g9cg-binutils-2.41/bin/ld: cannot find -lefivar: No such file or directory collect2: error: ld returned 1 exit status make[1]: *** [/build/source/src/include/rules.mk:38: libefisec.so] Error 1 shuffle=721268944 Before the change 2-3 rebuild attemts were enough to trigger build failure. After the change `evivar` survived 100 rebuilds. Artem Klimov noticed that it happens because LIBS gets overridden (or not overridden) based on the traversal order `make` takes to build the prerequisites. If the order is: all -> libefivar.so then LIBS is taken from libefivar.so target, which is libefivar.so : LIBS=dl There are no prerequisites and all is fine. But if the build order starts from `efisecdb`, then: efisecdb -> libefisec.so then LIBS is taken from `efisecdb`, this is: efisecdb : $(EFISECDB_OBJECTS) | libefisec.so efisecdb : private LIBS=efivar efisec dl When these `LIBS` are propagated to `libefisec.so` we get a linking failure. Thus the fix is to mark all `LIBS` instances as `private` to make sure `LIBS` never gets leaked into prerequisites' `LIBS` use. And while at it do the same for local `MAP` and local `CFLAGS` for consistency. Signed-off-by: Sergei Trofimovich <[email protected]>
- Loading branch information