Talk:OpenSceneGraph

From FlightGear wiki
Revision as of 21:07, 20 November 2011 by ThorstenB (talk | contribs)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Cause of the argument

On UNIX-like 64bit operating systems OpenSceneGraph does install into $prefix/lib64 by default. If you are using an operating system that sticks to the Filesystem Hierarchy Standard and therefore doesn't have lib64 directories, you probably want to get rid of that behaviour.

To do so run following command inside OSG's source directory or manually edit the file CMakeLists.txt accordingly:

sed 's|SET(LIB_POSTFIX "64" CACHE|SET(LIB_POSTFIX "" CACHE|' -i CMakeLists.txt

Another, not so clean, way would be to create a link lib64 that points to lib before running OSG's make install:

ln -s lib $prefix/lib64


Hi Thorsten,

to my knowledge the native libs should go into lib. Therefore, on a 64bit system, the self compiled 64bit libraries should be installed to lib and not lib64. Non-native libraries, like 32bit ones for compatibility reasons, should go into lib32. This impression of mine seems to be supported by the Filesystem Hierarchy Standard, if I understand it correctly:

   /lib : Essential shared libraries and kernel modules

       Purpose
       Requirements
       Specific Options

   /lib<qual> : Alternate format essential shared libraries (optional)

On Debian it is handled the same way, there is no lib64 anywhere on amd64.

Anyhow, this doesn't cover Windows systems, I have no idea how it is handled there. I will edit the text respectively.

--Flughund 21:46, 17 November 2011 (EST)

Hi Flughund, I'm mainly using OpenSuSE, which never had lib32 folders. OpenSuSE has 64bit and 32bit RPMs and it's allowed to mix such rpms on a single system. All 32bit libraries go into /lib - the same as they did traditionally - this avoid compatibility issues with old 32bit software. When 64bit was introduced, a new folder was created - so all 64bit libraries definitely go into /lib64 on SuSE - and new 64bit software had to be adapted (when they accessed folders directly). It may be different for Debian of course. Not sure of other distributions - it would be good if s.o. would check that. --ThorstenB 00:49, 18 November 2011 (EST)


A quick look at some distros showed a muddled situation. I changed the text accordingly, is it ok that way? --Flughund 03:08, 20 November 2011 (EST)

Looks ok. Maybe we could also name the specific Linux distros that need this change to the OSG script - i.e. Debian, ... Of course the optimal solution would be to check how the correct lib directory can be detected automatically (I'm sure there has to be a way to do that). We could then adapt the CMake script and submit a patch to OSG, which would solve the root issue - so we won't need this hack for ever. Another option with minimum effort: post to the OSG-devel list, that there is this issue with Debian - and see what people come up with. --ThorstenB 10:59, 20 November 2011 (EST)

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 --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. --ThorstenB 16:07, 20 November 2011 (EST)