Re: [PATCH] scripts: Fix linking extract-cert against libcrypto

[Masahiro Yamada]

On Tue, Feb 9, 2021 at 2:01 PM Daniel Díaz <daniel.diaz@xxxxxxxxxx> wrote:
>
> When compiling under OpenEmbedded, the following error is seen
> as of recently:
>
>   /srv/oe/build/tmp/hosttools/ld: cannot find /lib/libc.so.6 inside /
>   /srv/oe/build/tmp/hosttools/ld: cannot find /usr/lib/libc_nonshared.a inside /
>   /srv/oe/build/tmp/hosttools/ld: cannot find /lib/ld-linux-x86-64.so.2 inside /
>   collect2: error: ld returned 1 exit status
>   make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1
>
> This is because 2cea4a7a1885 ("scripts: use pkg-config to
> locate libcrypto") now calls for `pkg-config --libs libcrypto`
> and inserts that into the Makefile rules as LDLIBS when
> building extract-cert.c.
>
> The problem is that --libs will include both -l and -L, which
> will be out of order when compiling/linking.
>
> This (very ugly) command is what's produced with OpenEmbedded:
>
>   gcc -Wp,-MMD,scripts/.extract-cert.d -Wall -Wmissing-prototypes -Wstrict-prototypes \
>     -O2 -fomit-frame-pointer -std=gnu89 \
>     -isystem/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/include \
>     -O2 -pipe -L/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/lib \
>     -L/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/lib \
>     -Wl,-rpath-link,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/lib \
>     -Wl,-rpath-link,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/lib \
>     -Wl,-rpath,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/lib \
>     -Wl,-rpath,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/lib \
>     -Wl,-O1 -I/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/include \
>     -I ./scripts -o scripts/extract-cert \
>     /oe/build/tmp/work-shared/intel-corei7-64/kernel-source/scripts/extract-cert.c \
>     -L/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot/usr//lib \
>     -lcrypto
>
> As per `make`'s documentation:
>
>   LDFLAGS
>     Extra flags to give to compilers when they are supposed to
>     invoke the linker, ‘ld’, such as -L. Libraries (-lfoo)
>     should be added to the LDLIBS variable instead.
>
>   LDLIBS
>     Library flags or names given to compilers when they are
>     supposed to invoke the linker, ‘ld’. LOADLIBES is a
>     deprecated (but still supported) alternative to LDLIBS.
>     Non-library linker flags, such as -L, should go in the
>     LDFLAGS variable.
>
> Fixes: 2cea4a7a1885 ("scripts: use pkg-config to locate libcrypto")
> Cc: stable@xxxxxxxxxxxxxxx # 5.6.x
> Reported-by: Naresh Kamboju <naresh.kamboju@xxxxxxxxxx>
> Signed-off-by: Daniel Díaz <daniel.diaz@xxxxxxxxxx>
> ---
>  scripts/Makefile | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/Makefile b/scripts/Makefile
> index 9de3c03b94aa..4b4e938b4ba7 100644
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -3,7 +3,8 @@
>  # scripts contains sources for various helper programs used throughout
>  # the kernel for the build process.
>
> -CRYPTO_LIBS = $(shell pkg-config --libs libcrypto 2> /dev/null || echo -lcrypto)
> +CRYPTO_LDFLAGS = $(shell pkg-config --libs-only-L libcrypto 2> /dev/null)
> +CRYPTO_LDLIBS = $(shell pkg-config --libs-only-l libcrypto 2> /dev/null || echo -lcrypto)
>  CRYPTO_CFLAGS = $(shell pkg-config --cflags libcrypto 2> /dev/null)
>
>  hostprogs-always-$(CONFIG_BUILD_BIN2C)                 += bin2c
> @@ -17,9 +18,11 @@ hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE)  += insert-sys-cert
>
>  HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include
>  HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
> -HOSTLDLIBS_sign-file = $(CRYPTO_LIBS)
> +HOSTLDFLAGS_sign-file = $(CRYPTO_LDFLAGS)
> +HOSTLDLIBS_sign-file = $(CRYPTO_LDLIBS)
>  HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS)
> -HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS)
> +HOSTLDFLAGS_extract-cert = $(CRYPTO_LDFLAGS)
> +HOSTLDLIBS_extract-cert = $(CRYPTO_LDLIBS)
>
>  ifdef CONFIG_UNWINDER_ORC
>  ifeq ($(ARCH),x86_64)
> --
> 2.25.1
>


I am wondering how "HOSTLDFLAGS_sign-file" and
"HOSTLDFLAGS_extract-cert" worked for you.


Kbuild supports HOSTLDLIBS_<target> syntax,
but not HOSTLDFLAGS_<target>.


I see $(HOSTLDLIBS_$(target-stem) in scripts/Makefile.host
but failed to find $(HOSTLDFLAGS_$(target-stem)).

So, presumably you will get the same result
(OE build error will be fixed)
even without HOSTLDFLAGS_sign-file
or HOSTLDFLAGS_extract-cert.



But, I am still wondering what the correct approach is.



Basically, there are two ways to link libraries
in non-standard paths.



[1] Give linker flags via HOSTLDFLAGS

   This is documented in Documentation/kbuild/kbuild.rst

   HOSTLDFLAGS
   -----------
   Additional flags to be passed when linking host programs.




[2] Use pkg-config






OE already adopted [1].

I think the following long lines came from HOSTLDFLAGS.

    -isystem/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/include
\
    -O2 -pipe -L/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/lib
\
    -L/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/lib
\
    -Wl,-rpath-link,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/lib
\
    -Wl,-rpath-link,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/lib
\
    -Wl,-rpath,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/lib
\
    -Wl,-rpath,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/lib
\
    -Wl,-O1 -I/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/include
\
    -I ./scripts -o scripts/extract-cert \




But, some people are not satisfied with [1] (or do not notice it)?


Then, 2cea4a7a1885 introduced the second one [2].

Mixing [1] and [2] perhaps confuses the build system somehow?




So, 2cea4a7a1885 was a problem, but
I do not think this patch is the right one either.

(At least, HOSTLDFLAGS_* additions are pointless)




-- 
Best Regards
Masahiro Yamada