Issue 592 in webp: CMake: can't install shared libs with empty rpath since 1.2.3

[ant.c… via monorail]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 592 by ant.c...@gmail.com: CMake: can't install shared libs with empty rpath since 1.2.3
https://bugs.chromium.org/p/webp/issues/detail?id=592

Since 1.3.0, CMakeLits hardcodes `CMAKE_INSTALL_RPATH` with an absolute path if it's empty. In package manager expecting neat relocatable shared libs (like conan), rpath should be empty or set with a relative path, not an absolute path.
There is not need to hardcode such mechanism in CMake. It can be injected externally during CMake configuration, so that everybody is happy and can customize its binaries.

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

[jz… via monorail]

Updates:
Status: Accepted

Comment #1 on issue 592 by jz...@google.com: CMake: can't install shared libs with empty rpath since 1.2.3
https://bugs.chromium.org/p/webp/issues/detail?id=592#c1

I think you're referring to this change [1] which was done to match the behavior of autoconf and ensure the correct library was loaded (e.g., from /usr/local/lib rather than /usr/lib).
If you're explicitly setting it to an empty value we can amend the check.

Can you try changing CMakeLists.txt line 104 from:
if(BUILD_SHARED_LIBS AND NOT CMAKE_INSTALL_RPATH)
to
if(BUILD_SHARED_LIBS AND NOT DEFINED CMAKE_INSTALL_RPATH)

To see if it works in your case?

[1] https://chromium-review.googlesource.com/c/webm/libwebp/+/3787313
b4994eaa CMake: set rpath for shared objects

[ant.c… via monorail]

Comment #2 on issue 592 by ant.c...@gmail.com: CMake: can't install shared libs with empty rpath since 1.2.3
https://bugs.chromium.org/p/webp/issues/detail?id=592#c2

Not tested yet but I guess it would probably work. But why changing default behavior of CMake while CMAKE_INSTALL_RPATH can be externally injected for specific install needs? It makes packaging harder when libraries hardcode another behavior than the default one of build systems.
I've also seen that a lib prefix has been added to all libs for msvc to follow filenames of NMake build, which is a breakage change in a sense (I don't think anybody was using NMake to build on Windows, but I may be wrong). lib prefix for msvc is very unusual.

[Git Watcher via monorail]

Updates:
Status: Fixed

Comment #3 on issue 592 by Git Watcher: CMake: can't install shared libs with empty rpath since 1.2.3
https://bugs.chromium.org/p/webp/issues/detail?id=592#c3

The following revision refers to this bug:
https://chromium.googlesource.com/webm/libwebp/+/d9a505ffb6b4c98677ea30803f17cad6ec1395ce

commit d9a505ffb6b4c98677ea30803f17cad6ec1395ce
Author: James Zern <jz...@google.com>
Date: Wed Jan 18 02:22:47 2023

CMakeLists.txt: allow CMAKE_INSTALL_RPATH to be set empty

this allows the user to override the default non-empty value added in:

b4994eaa CMake: set rpath for shared objects

Bug: webp:592
Change-Id: I069dcbcd8c2f1e8654d9bc98149139f398ac2c93
Fixed: webp:592

[modify] https://crrev.com/d9a505ffb6b4c98677ea30803f17cad6ec1395ce/CMakeLists.txt

[jz… via monorail]

Comment #4 on issue 592 by jz...@google.com: CMake: can't install shared libs with empty rpath since 1.2.3
https://bugs.chromium.org/p/webp/issues/detail?id=592#c4

CMake came much later than the autoconf and nmake based solutions, which we view as the canonical build files. I agree it's somewhat unfortunate, but for compatibility with those systems I decided to make CMake match rather than the other way around.