lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240702-fix-lib-install-v2-1-9b84dcd3c22b@gmail.com>
Date: Tue, 02 Jul 2024 09:56:25 +0200
From: Roman Storozhenko <romeusmeister@...il.com>
To: Thomas Renninger <trenn@...e.com>, Shuah Khan <shuah@...nel.org>
Cc: Javier Carrasco <javier.carrasco.cruz@...il.com>, 
 linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org, 
 Roman Storozhenko <romeusmeister@...il.com>
Subject: [PATCH v2] cpupower: fix lib default installation path

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@...il.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
---
 tools/power/cpupower/Makefile | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/tools/power/cpupower/Makefile b/tools/power/cpupower/Makefile
index cd0225a312b4..6c02f401069e 100644
--- a/tools/power/cpupower/Makefile
+++ b/tools/power/cpupower/Makefile
@@ -67,6 +67,7 @@ LANGUAGES = 			de fr it cs pt ka
 bindir ?=	/usr/bin
 sbindir ?=	/usr/sbin
 mandir ?=	/usr/man
+libdir ?=	/usr/lib
 includedir ?=	/usr/include
 localedir ?=	/usr/share/locale
 docdir ?=       /usr/share/doc/packages/cpupower
@@ -94,15 +95,6 @@ RANLIB = $(CROSS)ranlib
 HOSTCC = gcc
 MKDIR = mkdir
 
-# 64bit library detection
-include ../../scripts/Makefile.arch
-
-ifeq ($(IS_64_BIT), 1)
-libdir ?=	/usr/lib64
-else
-libdir ?=	/usr/lib
-endif
-
 # Now we set up the build system
 #
 

---
base-commit: f76698bd9a8ca01d3581236082d786e9a6b72bb7
change-id: 20240623-fix-lib-install-3b7dccdbdf45

Best regards,
-- 
Roman Storozhenko <romeusmeister@...il.com>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ