Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Difference between revisions of "Talk:OpenSceneGraph"

From FlightGear wiki
Jump to: navigation, search
Line 44: Line 44:
 
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.
 
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)
 
--[[User:ThorstenB|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. ;-) <BR>
 +
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
 +
 +
--[[User:Flughund|Flughund]] 17:06, 22 November 2011 (EST)

Revision as of 18:06, 22 November 2011

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)