This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 795542 - CMAKE_INSTALL_LIBDIR is usually a relative path but is absolute path on Fedora
CMAKE_INSTALL_LIBDIR is usually a relative path but is absolute path on Fedora
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: cmake (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Orion Poplawski
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-20 14:57 EST by Mads Kiilerich
Modified: 2012-08-03 12:01 EDT (History)
7 users (show)

See Also:
Fixed In Version: 2.8.7-6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-03 12:01:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mads Kiilerich 2012-02-20 14:57:41 EST
/usr/share/cmake/Modules/GNUInstallDirs.cmake and http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=126c993d031f6f7be4970a67621da92f580d4e5a hints that CMAKE_INSTALL_LIBDIR should be "lib" or "lib64", but /etc/rpm/macros.cmake ends up setting it to "/usr/lib" .

A relative cmake path will automatically be relative to ${CMAKE_INSTALL_PREFIX} and it will thus often not make any difference in the build process. It do however become a problem when the build system needs to know the absolute path and do something like ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR} and ends up with /usr/usr/lib.

Patching the upstream build system just to be able to build on Fedora doesn't seem like the best solution. It seems to me like macros.cmake should use
  -DCMAKE_INSTALL_LIBDIR:PATH=%{_lib}

As a workaround I can use
  %cmake -DCMAKE_INSTALL_LIBDIR:PATH=%{_lib} .


cmake-2.8.7-4.fc16.i686
rpm-4.9.1.2-5.fc16.i686
Comment 1 Rex Dieter 2012-02-20 15:34:20 EST
That's... unfortunate.  *lots* of projects in the wild already assume this is absolute.
Comment 2 Rex Dieter 2012-02-20 15:35:50 EST
I guess I'll have to review a sample of our cmake-based packages, and see how bad this could be.  (any other ideas?)
Comment 3 Orion Poplawski 2012-02-20 16:02:02 EST
Rex -

  This setting was influenced by some relatively early cmake adopters like plplot.  I've found at least one other project (tkimg) which seems to use the relative path convention.  I've posted to the cmake list for some more discussion.  It would be good to know what projects in fedora use what.
Comment 4 Rex Dieter 2012-02-20 16:19:16 EST
Agreed, I'll follow-up soon (sometime tomorrow hopefully) with my findings
Comment 5 Kevin Kofler 2012-02-20 17:27:05 EST
Yeah, I suspect there are some projects assuming this is absolute, though I also had to patch some CMake files of projects which assume it's relative (and some other maintainers use other workarounds, like redefining the setting on the command line, or even calling cmake directly instead of %cmake or %cmake_kde4 (against the guidelines)). It's an unfortunate mess. (I'd say this is a case of CMake being too smart and lenient. If it required either an absolute path (only, banning relative ones) or a relative path (only, banning absolute ones) in every command rather than accepting either, we probably wouldn't have ended up with this confusion. But of course this cannot be changed for obvious compatibility reasons.)
Comment 6 Orion Poplawski 2012-02-21 17:18:23 EST
My current plan is to strip the %cmake macro options down to:

        -DCMAKE_VERBOSE_MAKEFILE=ON \\\
        -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \\\
        -DBUILD_SHARED_LIBS:BOOL=ON

and build that for rawhide.

kde packages seem to use the %cmake_kde4 macro and that does not have CMAKE_INSTALL_LIBDIR defined.
Comment 7 Kevin Kofler 2012-02-21 17:32:57 EST
Uhm:
* Please leave the %{?_cmake_lib_suffix64} in!
* We probably need LIB_INSTALL_DIR set one way or the other.
Otherwise, many packages will be broken for multilib.
Comment 8 Orion Poplawski 2012-02-21 17:41:19 EST
(In reply to comment #7)
> * Please leave the %{?_cmake_lib_suffix64} in!

It's still in %cmake_kde4 which is what seems to use it.  Also, those projects should probably migrate the the GNUInstallDirs convention if needed.

> * We probably need LIB_INSTALL_DIR set one way or the other.
> Otherwise, many packages will be broken for multilib.

We'll see.  Packagers can always add defines they need for their packages.
Comment 9 Kevin Kofler 2012-02-21 17:46:56 EST
> It's still in %cmake_kde4 which is what seems to use it.

Several non-KDE projects also need LIB_SUFFIX. Some of them are part of e.g. kdesupport, some are just completely non-KDE projects which just happen to also need this feature.

> Packagers can always add defines they need for their packages.

Sure, but what does removing the setting of LIB_SUFFIX achieve? That define isn't breaking anything (unlike CMAKE_INSTALL_LIBDIR). All it's going to achieve is a bunch of pointless FTBFS issues.
Comment 10 Kevin Kofler 2012-02-21 17:49:14 EST
Oh, and the *_INSTALL_DIR convention is also used by many projects, not just KDE. (Some use only LIB_SUFFIX, some only *_INSTALL_DIR (especially LIB_INSTALL_DIR), some use both, i.e. they use ${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX} if LIB_INSTALL_DIR is not set.)
Comment 11 Bartosz Brachaczek 2012-08-02 21:35:10 EDT
Reading GNUInstallDirs.cmake convinces me that this bug in invalid. CMAKE_INSTALL_LIBDIR isn't guaranteed to be relative, they just say you can use it in the install() CMake command, which is true for both relative and absolute path. And GNUInstallDirs.cmake defines CMAKE_INSTALL_FULL_LIBDIR variable which is guaranteed to be absolute. So packages using ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR} just need to be fixed and I see no bug here in Fedora/CMake.

FWIW, Gentoo also defines CMAKE_INSTALL_LIBDIR to an absolute path. And Gentoo being a source-based distribution would be especially vulnerable to problems with packages assuming the path to be relative. And they handle it.
Comment 12 Mads Kiilerich 2012-08-03 07:43:30 EDT
Yes, it is "spec bug" that it is unspecified whether CMAKE_INSTALL_LIBDIR is absolute or relative. It might also be a bug in apps if they assume one of them.

But if CMAKE_INSTALL_LIBDIR can be either absolute or relative then I don't see why it would be a problem to make it relative.

When CMAKE_INSTALL_FULL_LIBDIR is absolute then it would make a lot of sense if CMAKE_INSTALL_LIBDIR was relative.

Pushing in the direction of standardizing on CMAKE_INSTALL_LIBDIR being relative seems like the best way forward.


What fix would you recommend for packages using ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}?
Comment 13 Bartosz Brachaczek 2012-08-03 08:07:34 EDT
(In reply to comment #12)
> What fix would you recommend for packages using
> ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}?

Using ${CMAKE_INSTALL_FULL_LIBDIR}. If GNUInstallDirs is included, it resolves to either ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR} is CMAKE_INSTALL_LIBDIR relative, and to ${CMAKE_INSTALL_LIBDIR} otherwise.

And if someone really needs a relative path, the only portable way I know to achieve it until all parties are convinced that CMAKE_INSTALL_LIBDIR should be always relative, is:

file (RELATIVE_PATH CMAKE_INSTALL_RELATIVE_LIBDIR "${CMAKE_INSTALL_PREFIX}" "${CMAKE_INSTALL_FULL_LIBDIR}")

...which puts the relative path into CMAKE_INSTALL_RELATIVE_LIBDIR variable.
Comment 14 Orion Poplawski 2012-08-03 12:01:41 EDT
As of 2.8.7-6, CMAKE_INSTALL_LIBDIR is no longer set in the %cmake macro.  Use whatever your project needs.

Note You need to log in before you can comment on or make changes to this bug.