From: Shuah Khan <skhan@linuxfoundation.org>
To: Roman Storozhenko <romeusmeister@gmail.com>,
Thomas Renninger <trenn@suse.com>, Shuah Khan <shuah@kernel.org>
Cc: Javier Carrasco <javier.carrasco.cruz@gmail.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH v2] cpupower: fix lib default installation path
Date: Tue, 2 Jul 2024 15:34:05 -0600 [thread overview]
Message-ID: <753c55df-82d7-4756-861b-62e4e59c7615@linuxfoundation.org> (raw)
In-Reply-To: <20240702-fix-lib-install-v2-1-9b84dcd3c22b@gmail.com>
On 7/2/24 01:56, Roman Storozhenko wrote:
> Invocation the tool built with the default settings fails:
> $ cpupower
> cpupower: error while loading shared libraries: libcpupower.so.1: cannot
> open shared object file: No such file or directory
>
> The issue is that Makefile puts the library to "/usr/lib64" dir for a 64
> bit machine. This is wrong. According to the "File hierarchy standard
> specification:
> https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
> https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf
>
> "/usr/lib<qual>" dirs are intended for alternative-format libraries
> (e.g., "/usr/lib32" for 32-bit libraries on a 64-bit machine (optional)).
>
> The utility is built for the current machine and doesn't handle
> 'CROSS_COMPILE' and 'ARCH' env variables. It also doesn't change bit
> depth. So the result is always the same - binary for x86_64
> architecture. Therefore the library should be put in the '/usr/lib'
> dir regardless of the build options.
> This is the case for all the distros that comply with the
> 'File Hierarchy Standard 3.0" by Linux Foundation. Most of the distros
> comply with it. For example, one can check this by examining the
> "/usr/lb64" dir on debian-based distros and find that it contains only
> "/usr/lib64/ld-linux-x86-64.so.2". And examine that "/usr/lib" contains
> both 32 and 64 bit code:
> find /usr/lib -name "*.so*" -type f | xargs file | grep 32-bit
> find /usr/lib -name "*.so*" -type f | xargs file | grep 64-bit
>
> Fix the issue by changing library destination dir to "/usr/lib".
>
> Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com>
> ---
> Changes in v2:
> - Enchance changelog by providing more details
> - Link to v1: https://lore.kernel.org/r/20240623-fix-lib-install-v1-1-bcbd03b78d87@gmail.com
> ---
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux.git/?h=cpupower
thanks,
-- Shuah
prev parent reply other threads:[~2024-07-02 21:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-02 7:56 Roman Storozhenko
2024-07-02 21:34 ` Shuah Khan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=753c55df-82d7-4756-861b-62e4e59c7615@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=javier.carrasco.cruz@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=romeusmeister@gmail.com \
--cc=shuah@kernel.org \
--cc=trenn@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®