Talk:OpenSceneGraph

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)

Even worse, it is Linux that is breaking the rules: "This chapter describes some details that are only relevant to GNU/Linux systems and the Linux kernel.", quote from the pdf-link below.

I would not use the word 'fiddling' here because it is a simple copy'n'paste sed command. Anyhow, as I am a user, too, my opinion is to preferable fiddle with build scripts, to have a 'proper' installation/file system, rather than symlinks. ;-)
The situation evolved from Debian where I tried to keep things simple and that most commands work by just copy'n'paste them. Also I tried to keep the if-then-else for the reader at minimum even if the article suits for Debian-Oldstable/-Stable/-Testing on i386/amd64 and FG-Stable/-GIT. At first there was the solution with the lib64-link but, as the article history shows, in detail this was not free of the possibility for issues. Not only from this I learned that extinguishing the cause is better than creating workarounds for it. Even if 'fiddling' with scripts seems to be much more complicated at first.

For the records: http://www.x86-64.org/documentation/abi.pdf page 124 vs. http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

--Flughund 17:06, 22 November 2011 (EST)

Well, let's not get into the discussion into who's fault it is - it's the way it is now (both, for the AMD64 platform ABI and for Debian) and we can't change it.

Sorry, I should have been more precise. My intention was to find the proper solution and _not_ to blame the rule breaker, ...)

Flughund 12:09, 26 February 2012 (EST)

Never mind the "fiddling" - but I used that, since the line will be complete magic to most users - they will have no idea what they are doing there. Also, this changes a released file permanently - which is why I wouldn't call the approach "clean" either ;-). That line will probably help Debain/Ubuntu users - but I may actually be an issue for other systems. The advantage of the symlink is that it doesn't change any file - and it's not doing any harm. Anyway, just go ahead and update the page - I think we've analyzed the issue fairly well now ;-).

--ThorstenB 17:50, 22 November 2011 (EST)

I had a closer look at the new CMake feature and implemented it for simgear (so simgear libraries are correctly installed in /lib64 for non-Debian distros). I'll also provide a patch to OSG which uses the new CMake auto-detection. However, OSG already provides a documented switch to specify whether "lib" or "lib64" shall be used:

   LIB_POSTFIX: suffix for 32/64 dir placement

So, just call:

   cmake ... -DLIB_POSTFIX=""

to install OSG in "lib" and override the current OSG default of using "lib64" on all 64bit CPUs. Please use this switch for the description in the Wiki. Later OSG versions may no longer need this switch to be configured manually - if my patch was accepted.

... which seems to be done now. Thanks!

Sorry Mark II: I really was short on time the past few months, please, excuse me for not answering yet.

In the upcoming days I will have the chance to compile FG on a freshly installed plain Debian Stable. During this process I will review the articles ([1][2]) and update them accordingly.

Flughund 12:09, 26 February 2012 (EST)

--ThorstenB 07:45, 25 November 2011 (EST)