You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Building and installing libhsplasma on 64bit linux distros will always put the modules in the prefix/lib directory regardless of the conventions of the distribution, which may want 64bit libraries installed in prefix/lib64. To fix this, some cmake files need to be manually adapted, a better option would be to use ${LIB_INSTALL_DIR} and make it configurable. Find two patches attached to fix this problem. This way, libhsplasma can be built with
cmake -DCMAKE_INSTALL_PREFIX:PATH= -DLIB_INSTALL_DIR=< libdir > .
to respect the filesystem conventions.
I will point out that if your distro is 64-bit and using /usr/lib for 32-bit files, it's breaking the linux Filesystem Heirarchy Standard which while non-normative (like most linux standards) is followed by most distros.
That aside, I really have no idea why this was hardcoded to lib instead of ${LIB_INSTALL_DIR}. I don't see why we can't fix it.
Comment 2:
From what I know all Red Hat based systems, and also Fedora, use lib for 32bit libraries and lib64 for 64bit ones, while Debian based distros use lib32 for 32bit ones and lib with a lib64 symlink pointing to lib for 64bit ones.
Comment 3:
LIB_INSTALL_DIR isn't predefined by CMake (although on Fedora, you probably wouldn't notice that since Fedora hacks their CMake to include it).
On Ubuntu this causes errors when running cmake.
There's a SetPaths.cmake file in the Google result for "LIB_INSTALL_DIR" that we might be able to pull in, but it seems a bit overkill IMO.
The text was updated successfully, but these errors were encountered:
I will point out that if your distro is 64-bit and using /usr/lib for 32-bit files, it's breaking the linux Filesystem Heirarchy
Standard which while non-normative (like most linux standards) is followed by most distros.
Actually, it's the other way around... Debian is breaking the FHS and even the psABI by putting 64bit libraries into /usr/lib.
Building and installing libhsplasma on 64bit linux distros will always put the modules in the prefix/lib directory regardless of the conventions of the distribution, which may want 64bit libraries installed in prefix/lib64. To fix this, some cmake files need to be manually adapted, a better option would be to use ${LIB_INSTALL_DIR} and make it configurable. Find two patches attached to fix this problem. This way, libhsplasma can be built with
cmake -DCMAKE_INSTALL_PREFIX:PATH= -DLIB_INSTALL_DIR=< libdir > .
to respect the filesystem conventions.
(from https://code.google.com/p/libhsplasma/issues/detail?id=73)
Comment 1:
I will point out that if your distro is 64-bit and using /usr/lib for 32-bit files, it's breaking the linux Filesystem Heirarchy Standard which while non-normative (like most linux standards) is followed by most distros.
That aside, I really have no idea why this was hardcoded to lib instead of ${LIB_INSTALL_DIR}. I don't see why we can't fix it.
Comment 2:
From what I know all Red Hat based systems, and also Fedora, use lib for 32bit libraries and lib64 for 64bit ones, while Debian based distros use lib32 for 32bit ones and lib with a lib64 symlink pointing to lib for 64bit ones.
Comment 3:
LIB_INSTALL_DIR isn't predefined by CMake (although on Fedora, you probably wouldn't notice that since Fedora hacks their CMake to include it).
On Ubuntu this causes errors when running cmake.
There's a SetPaths.cmake file in the Google result for "LIB_INSTALL_DIR" that we might be able to pull in, but it seems a bit overkill IMO.
The text was updated successfully, but these errors were encountered: