MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010056CMakeCMakepublic2009-12-15 17:492016-06-10 14:31
Reporterdwyatte 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0010056: Mac OS X: If symbolic links already exist in cmake install dir, command line tool installation fails
DescriptionWhen installing the cmake command line tools on Mac OS X, cmake creates links from /usr/bin to the cmake application in /Applications. If there are already symbolic links in /usr/bin, perhaps from a previous cmake installation, the installer cannot redirect the links to the new location and installation fails. To resolve, the user needs to manually remove old symbolic links in /usr/bin -- can this be included in the installer?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0011693closed Brad King On Mac OS X, the CMake .app filename should not contain the version number 
has duplicate 0010938closed David Cole Mac: dmg installer does not deal with previous install of cmake for symlinks in /usr/bin 
has duplicate 0012399closed David Cole cmake installer for Mac fails to create /usr/bin symlinks over previous version 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2009-12-15 17:49dwyatteNew Issue
2010-12-15 09:07David ColeAssigned To => David Cole
2010-12-15 09:07David ColeStatusnew => assigned
2010-12-15 10:16David ColeRelationship addedrelated to 0010938
2011-01-25 03:39Hartmut SeichterNote Added: 0025065
2011-07-29 13:42David ColeTarget Version => CMake 2.8.6
2011-07-29 15:41David ColeRelationship addedrelated to 0011693
2011-08-12 09:07David ColeRelationship addedhas duplicate 0012399
2011-09-06 16:19David ColeNote Added: 0027386
2011-09-06 16:19David ColeTarget VersionCMake 2.8.6 =>
2011-10-26 00:11David ColeRelationship replacedhas duplicate 0010938
2012-08-13 15:12David ColeStatusassigned => backlog
2012-08-13 15:12David ColeNote Added: 0030605
2012-08-13 15:19David ColeAssigned ToDavid Cole =>
2013-02-17 22:14Randy O'ReillyNote Added: 0032321
2013-02-18 10:51Sean McBrideNote Added: 0032329
2013-02-18 11:01Hartmut SeichterNote Added: 0032330
2013-02-18 11:07Sean McBrideNote Added: 0032331
2014-03-03 13:48Randy O'ReillyNote Added: 0035239
2014-03-03 13:49Randy O'ReillyNote Added: 0035240
2016-06-10 14:27Kitware RobotNote Added: 0041635
2016-06-10 14:27Kitware RobotStatusbacklog => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:27Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0025065)
Hartmut Seichter   
2011-01-25 03:39   
This is bothering me as well. Here a possible solution.

Problem
------
Tools > Install for Command Line Use executes this:

ln -s [/Applications/CMake 2.8-4.app/Contents/bin/ccmake] [/usr/bin/ccmake]

Hence, neither elevates privileges nor does -f to overwrite existing installation
 
Solution
------

it should execute something like this:

osascript -e 'do shell script "ln -sf \"/Applications/CMake 2.8-4.app/Contents/bin/cmake\" /usr/bin/cmake" with administrator privileges'

This will pop-up the password dialog and if successful execute the script with elevated privileges.
(0027386)
David Cole   
2011-09-06 16:19   
Not enough time left to address this issue before the 2.8.6 release. Deferred until a future release.
(0030605)
David Cole   
2012-08-13 15:12   
Sending old, not-recently-updated issues to the backlog.

(The age of the bug alone means that nobody is actively working on it...)

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0032321)
Randy O'Reilly   
2013-02-17 22:14   
This routinely causes problems for a number of users of our software package that uses cmake, and has a very simple fix that Hartmut Seichter posted -- would be great if this could be incorporated into an upcoming release! Thanks!
(0032329)
Sean McBride   
2013-02-18 10:51   
If bug 0011693 is fixed, this won't be a problem anymore, because the symlinks will still be valid.
(0032330)
Hartmut Seichter   
2013-02-18 11:01   
Though I agree it would be great to have that hideous versioning removed from the name it will not change the fact that CMake (and for that matter the CMake pkg installer) uses an outdated and non-functioning method to elevate user rights for installing the links.
(0032331)
Sean McBride   
2013-02-18 11:07   
Hartmut, sure, I just wanted to bring attention to the fact that these two issues are related.
(0035239)
Randy O'Reilly   
2014-03-03 13:48   
Just adding another plea for fixing this using Hartmut's suggestion -- this continues to be a problem for all of our users, and I would guess for a vast majority of cmake users on the mac, if they ever get around to upgrading. Presumably almost everyone uses cmake from the command line. I don't think this requires much "bandwidth" -- the fix is a one-liner. Just do it!! Thanks!!!
(0035240)
Randy O'Reilly   
2014-03-03 13:49   
Btw, the severity is not "minor" -- this bug prevents an upgraded version of the software from working. period. That is a complete fail.
(0041635)
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.