159
edits
No edit summary |
No edit summary |
||
Line 41: | Line 41: | ||
Yo Thorsten, stumbled on some cmake bugtracker: http://public.kitware.com/Bug/view.php?id=11964 But since I am not a developer, nor am I familiar with cmake, I don't completely understand what they are saying or what exactly the solution is. But it seems as there is a solution for cmake 2.8.5 (which is even available for Debian Stable via backports). hth | Yo Thorsten, stumbled on some cmake bugtracker: http://public.kitware.com/Bug/view.php?id=11964 But since I am not a developer, nor am I familiar with cmake, I don't completely understand what they are saying or what exactly the solution is. But it seems as there is a solution for cmake 2.8.5 (which is even available for Debian Stable via backports). hth | ||
--[[User:Flughund|Flughund]] 15:32, 20 November 2011 (EST) | --[[User:Flughund|Flughund]] 15:32, 20 November 2011 (EST) | ||
Ah, thanks, that's a very good link! Lots to read though. Newer CMake is going to have better support for auto-detecting the library paths. Also Debian/Ubtunu is a bit at fault - it's the X86-64 ABI which actually requires /lib vs /lib64 for 32/64bit. Isn't the work-around described there for Debian a better solution though, i.e. use symlinks mapping lib => lib64? That saves users from fiddling with changing a script? Long term, we should make sure that all CMake scripts use the new method to auto-detect the lib directory correctly. | |||
--[[User:ThorstenB|ThorstenB]] 16:07, 20 November 2011 (EST) |
edits