tools/perf/tests/make | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
The existing Makefile logic for determining library paths was
hardcoded for x86 architectures, causing incorrect behavior
on other platforms. This patch implements a portable solution
using system bit detection.
Signed-off-by: Suchit Karunakaran <suchitkarunakaran@gmail.com>
---
tools/perf/tests/make | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tools/perf/tests/make b/tools/perf/tests/make
index 0ee94caf9ec1..565522408f99 100644
--- a/tools/perf/tests/make
+++ b/tools/perf/tests/make
@@ -53,9 +53,12 @@ endif
include $(srctree)/tools/scripts/Makefile.arch
-# FIXME looks like x86 is the only arch running tests ;-)
-# we need some IS_(32/64) flag to make this generic
-ifeq ($(ARCH)$(IS_64_BIT), x861)
+BITS := $(shell getconf LONG_BIT)
+IS_64_BIT ?= 1
+ifeq ($(BITS), 32)
+IS_64_BIT = 0
+endif
+ifeq ($(IS_64_BIT), 1)
lib = lib64
else
lib = lib
--
2.50.1
On Sun, Jul 20, 2025 at 02:29:05PM +0530, Suchit Karunakaran wrote: > The existing Makefile logic for determining library paths was > hardcoded for x86 architectures, causing incorrect behavior > on other platforms. This patch implements a portable solution > using system bit detection. > > Signed-off-by: Suchit Karunakaran <suchitkarunakaran@gmail.com> > --- > tools/perf/tests/make | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/tools/perf/tests/make b/tools/perf/tests/make > index 0ee94caf9ec1..565522408f99 100644 > --- a/tools/perf/tests/make > +++ b/tools/perf/tests/make > @@ -53,9 +53,12 @@ endif > > include $(srctree)/tools/scripts/Makefile.arch > > -# FIXME looks like x86 is the only arch running tests ;-) > -# we need some IS_(32/64) flag to make this generic > -ifeq ($(ARCH)$(IS_64_BIT), x861) > +BITS := $(shell getconf LONG_BIT) > +IS_64_BIT ?= 1 > +ifeq ($(BITS), 32) > +IS_64_BIT = 0 > +endif > +ifeq ($(IS_64_BIT), 1) > lib = lib64 > else > lib = lib A dummy question: Does all other architectures have lib64 vs lib separation? Thanks, Namhyung > -- > 2.50.1 >
> > A dummy question: Does all other architectures have lib64 vs lib > separation? > I had assumed there would always be symlinks, but thanks for pointing that out. After your question, I checked various architectures like x86, ARM, SPARC, s390x, etc and only x86 had both lib and lib64 (with symlinks). On the others, even for 64-bit systems, only a lib directory existed. I also realized this behavior seems to depend on the distro. For example, multiarch distros like Debian use separate directories for lib32 and lib64, and a lib symlink pointing to /usr/lib. On the other hand, Arch Linux has both lib and lib64 as symlinks to /usr/lib. Would it be reasonable if we create a symlink named lib64 for non-x86 architectures? I'd appreciate your thoughts on this. Thanks!
On Mon, Jul 21, 2025 at 11:10:18AM +0530, Suchit K wrote: > > > > A dummy question: Does all other architectures have lib64 vs lib > > separation? > > > > I had assumed there would always be symlinks, but thanks for pointing > that out. After your question, I checked various architectures like > x86, ARM, SPARC, s390x, etc and only x86 had both lib and lib64 (with > symlinks). On the others, even for 64-bit systems, only a lib > directory existed. I also realized this behavior seems to depend on > the distro. For example, multiarch distros like Debian use separate > directories for lib32 and lib64, and a lib symlink pointing to > /usr/lib. On the other hand, Arch Linux has both lib and lib64 as > symlinks to /usr/lib. Would it be reasonable if we create a symlink > named lib64 for non-x86 architectures? I'd appreciate your thoughts on > this. Thanks! I'd be intrusive if we create a new symlink. Probably we need to check if there's lib64 directory first and use it for 64 bit build. But I feel like this needs more testing. Can you share what's the problem exactly? Thanks, Namhyung
> > I'd be intrusive if we create a new symlink. Probably we need to check > if there's lib64 directory first and use it for 64 bit build. But I > feel like this needs more testing. > > Can you share what's the problem exactly? > > Thanks, > Namhyung > Yeah I agree it needs more testing. And yes we can check if the lib64 folder exists and then create a symlink. If there's no lib64 folder, we can create a symlink named lib64 to the lib folder. I assume this will cover most of the architectures since the lib folder existed in almost all the architectures that I tested.
© 2016 - 2025 Red Hat, Inc.