[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aIA3JQWNs-0Jsla4@google.com>
Date: Tue, 22 Jul 2025 18:13:09 -0700
From: Namhyung Kim <namhyung@...nel.org>
To: Suchit K <suchitkarunakaran@...il.com>
Cc: peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
mark.rutland@....com, alexander.shishkin@...ux.intel.com,
jolsa@...nel.org, irogers@...gle.com, adrian.hunter@...el.com,
kan.liang@...ux.intel.com, linux-perf-users@...r.kernel.org,
sesse@...gle.com, charlie@...osinc.com,
linux-kernel@...r.kernel.org, linux-kernel-mentees@...ts.linux.dev,
skhan@...uxfoundation.org
Subject: Re: [PATCH] perf tests: Fix lib path detection for non-x86
architectures
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
Powered by blists - more mailing lists