Update cmake to >= 2.8.9 in openSUSE-12.2-Update

I’m looking to post this for the openSUSE administrators, please move the thread it it’s in the wrong section. I wish to request updating cmake (currently at version 2.8.8) to 2.8.9 or later in the openSUSE-12.2-Update repository. That’s because 2.8.9 introduced a compile flag which some projects are already using, called SONAME_FLAG. Without it, cmake will generate an incorrect linker setup, and gcc will fail to link libraries upon compile. I was told the openSUSE policy is to update package versions when a critical change is out, which this is probably the case. I posted about the issue here: 0013884: SONAME_FLAG incorrectly prefixed to libraries in link.txt & relink.txt, causes linker to fail - MantisBT Here’s a quote of my original bug report and the reply I got from one of the cmake devs:

I discovered a major problem while configuring two C++ projects with cmake. When Generating the configuration, cmake adds the word SONAME_FLAG before the name of each library in link.txt and relink.txt once. This causes the linker to fail when compiling with make. Here’s the error I get with the OGRE engine:

c++: error: SONAME_FLAGlibOgreMain.so.1.9.0: No such file or directory
make[2]: *** [lib/libOgreMain.so.1.9.0] Error 1
make[1]: *** [OgreMain/CMakeFiles/OgreMain.dir/all] Error 2
make: *** [all] Error 2

After hours of digging into the issue, I found where it happens and what goes wrong. Here’s the OGRE and libOgreMain example, but the problem happens with each library of projects that are affected:

  • After you generate your cmake configuration, open the file …/OGRE/build/OgreMain/CMakeFiles/OgreMain.dir/link.txt
  • Somewhere within this file, you will find the following part: -shared SONAME_FLAGlibOgreMain.so.1.9.0
  • To fix it, you must manually change that to: -shared -Wl,-soname,libOgreMain.so.1.9.0

To reproduce the issue:

  • Get the source of one of the projects affected by the issue. I only noticed it with OGRE and PolyVox, other C++ codes work fine.
  • Unpack it and run cmake (in my case I use cmake-gui). Specify “Unix makefiles” with “Default native compilers”. If the main folder is OGRE set the build folder to OGRE/build. Leave all cmake options to their defaults and Configure then Generate. Normally you should see no errors or warnings.
  • Now go to OGRE/build and run “make”. It will start to compile, but when it gets to linking the first library you get the error: c++: error: SONAME_FLAGlibWhatever.so.1.2.3: No such file or directory

Experienced with cmake 2.8.8. Operating system is Linux openSUSE 12.2 KDE 4.9.5.

The SONAME_FLAG rule variable placeholder was added in CMake 2.8.9 here:

cmake.org Git - cmake.git/commitdiff ^]

and is not available in 2.8.8. Since the source code to CMake 2.8.8 doesn’t even mention it the string must be coming from the project itself. I suspect these projects are trying to use custom link rule variables without updating their minimum required version of CMake to a sufficiently new version to have the features they use.

Hi
Since your running KDE 4.9 it’s in the repository…

https://build.opensuse.org/package/show?project=KDE%3ARelease%3A49&package=cmake

So that would sort of make it moot, unless your wanting to downgrade your LDE?

It’s still at 2.8.8 for Factory as well. There are a few options, either raise a bug, talk to the cmake maintainer or branch and do your own maintenance update on OBS…

I just looked and the cmake package is indeed 2.8.9. cmake GUI however is still at 2.8.8. I was confused because if I select Help in cmake-gui it says “Cmake 2.8.8”… but that’s probably because of the -gui.

Still, that’s from the KDE 4.9 repository. The openSUSE repository itself doesn’t have either cmake or cmake-gui 2.8.9. So I’d still suggest updating them, since 2.8.8 is unable to configure and generate some projects.

On 2013-01-30 15:16, MirceaKitsune wrote:
> Still, that’s from the KDE 4.9 repository. The openSUSE repository
> itself doesn’t have either cmake or cmake-gui 2.8.9. So I’d still
> suggest updating them, since 2.8.8 is unable to configure and generate
> some projects.

Such a suggestion you can make in a bugzilla. Here we are just users
helping users.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

Hi,

  1. It is possible to update it for openSUSE_Factory (which will not be included in 12.3), but it’s not possible to update it for 12.2 + 12.3.

I know it’s sad, but here’s our maintenance policy:

https://en.opensuse.org/openSUSE:Maintenance_policy

Generally, only bugfixes can trigger an update stack. such infrastructure things can’t be updated to a completely new version, because it will trigger rebuild of all relevant packages (and may cause potential build failures to make us take efforts no less than building a completely new distribution, considering there’re so many packages using cmake build system). such deals can’t keep our system’s consistency.

  1. It is upstream’s responsibility to keep their tarballs build with older version of cmake, unless it’s a completely new written software. So in this case, I suggest you open a bug report for them, instead for openSUSE. I know it’s sad, but we are distribution developers instead of a specific software developers, we can’t take over everything to make our hands dirty.

  2. You can still find many cmake that can be used on 12.2 at software.opensuse.org:

There’re even 2.8.10 versions available. Although not default, these repositories except the home:* ones are still openSUSE official repositories, which means we actually have provided build capability…

Greetings,

Marguerite

I understand, thank you for clarifying. It is indeed problematic, since such a policy means that if something stops working it stays that way unless it’s specifically a bug. Can’t say that for cmake this situation is a bug… more like an important update so it can keep working. 2.8.9 introduced a new flag which projects that rely on cmake started using, so one needs this version or higher to configure them.

I hoped at least 12.3 would have the newer version of cmake though. If not that’s problematic, and I’ll have to find a way to upgrade it from somewhere else. But it’s understandable… will probably find a way to get around the issue then.

MirceaKitsune wrote:
> I understand, thank you for clarifying. It is indeed problematic, since
> such a policy means that if something stops working it stays that way
> unless it’s specifically a bug. Can’t say that for cmake this situation
> is a bug… more like an important update so it can keep working. 2.8.9
> introduced a new flag which projects that rely on cmake started using,
> so one needs this version or higher to configure them.

The point is that not only is it not a bug, but cmake hasn’t stopped
working either! It still works just fine.

The problem only arises for projects that themselves have made changes
(i.e. decided to move to a new version of cmake). So the correct fix is
for those projects to back out the changes they have made. They have
introduced regression bugs into their projects.

Or do as KDE has apparently done and provide a private build environment
that is compatible with the changes the project has made.

As Marguerite says, open bug reports in the broken projects.

It would be correct to also poke the project admins and tell them to filter the usage of that flag by cmake version. I shall do that as well.