[Buildroot] [PATCH] package/numactl: point to target libs via LDFLAGS

From: Alexey Brodkin via buildroot <buildroot@buildroot.org>
To: buildroot@buildroot.org
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
	Fabrice Fontaine <fontaine.fabrice@gmail.com>
Subject: [Buildroot] [PATCH] package/numactl: point to target libs via LDFLAGS
Date: Mon, 24 Oct 2022 19:49:11 +0200	[thread overview]
Message-ID: <20221024174911.75444-1-abrodkin@synopsys.com> (raw)

In the commit a699a667bd64 ("package/numactl: add -latomic to numa.pc")
we opted-out from unconditional linking with "-latomic" and made it
a conditional based on real availability of __atomic_fetch_and_1()
in the toolchain. I.e. for many targets "-latomic" was not used
any longer.

And in those supposedly rare cases when libatomic was required it was
all OK until there's a LD_LIBRARY_PATH set with something where yet
another libatomic.so instance exists, especially if that's the one from
host (in my case I used a separately built host toolchain). Then we see:
---------------------->8-----------------------
/bin/sh ./libtool  --tag=CC   --mode=link .../buildroot/output/host/bin/arc32-buildroot-linux-uclibc-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os -g0  -Wl,-z,max-page-size=4096 -fPIC -std=gnu99    -o numastat numastat-numastat.o  -latomic

libtool: link: .../buildroot/output/host/bin/arc32-buildroot-linux-uclibc-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g0 -Wl,-z -Wl,max-page-size=4096 -fPIC -std=gnu99 -o numastat numastat-numastat.o  .../gcc-5.2.0/lib/../lib64/libatomic.so -pthread -Wl,-rpath -Wl,.../gcc-5.2.0/lib/../lib64 -Wl,-rpath -Wl,.../gcc-5.2.0/lib/../lib64
.../buildroot/output/host/lib/gcc/arc32-buildroot-linux-uclibc/12.2.1/../../../../arc32-buildroot-linux-uclibc/bin/ld: .../gcc-5.2.0/lib/../lib64/libatomic.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
---------------------->8-----------------------

That happens because libtool of numactl adds contents of the aforementioned
LD_LIBRARY_PATH to its "$searchdirs" and then the first libatomic.so it
finds becomes the one used for linking. What's more our precios cross-built
libatomic.so never even gets considered because that first found libatomic.so
is used with full path, not as "-latomic" as otherwise it would have been used
without helpful libtool.

But with paths pointing to the staging location, these paths get added to
"$searchdirs" and so the right libatomic.so gets found, which solves our problem.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
---
 package/numactl/numactl.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/numactl/numactl.mk b/package/numactl/numactl.mk
index cf9c759693..58b304d6e1 100644
--- a/package/numactl/numactl.mk
+++ b/package/numactl/numactl.mk
@@ -10,6 +10,7 @@ NUMACTL_LICENSE = LGPL-2.1 (libnuma), GPL-2.0 (programs)
 NUMACTL_LICENSE_FILES = README.md
 NUMACTL_INSTALL_STAGING = YES
 NUMACTL_AUTORECONF = YES
-NUMACTL_CONF_ENV = CFLAGS="$(TARGET_CFLAGS) -fPIC"
+NUMACTL_CONF_ENV = CFLAGS="$(TARGET_CFLAGS) -fPIC" \
+		   LDFLAGS="$(TARGET_LDFLAGS) -L$(STAGING_DIR)/lib"
 
 $(eval $(autotools-package))
-- 
2.16.2

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
