Hi All, Wow, don't you love it when a topic generates real interest. I count over 30 posts on this so far... and I can not help but add one more ;=))
To try to directly address the problem as posted on - http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit the case of a 'missing' osgFX So the question is where is osgFX installed? And this, as others have pointed out, would depend on what was fed to cmake, if OSG is compiled from source, or where the package manager put it... I suspect it is in a 'lib64' folder, either /usr/lib64 or maybe /usr/local/lib64, or /games/orig/usr/lib64 Why OSG cmake does this I have no idea. Maybe cmake thinks it is being 'smart' ;=() If it is in /games/orig/usr/lib64, and there is no /games/orig/usr/lib, or it is empty, then creating a link lib -> lib64 with /games/orig/usr $ ln -s lib64 lib will get the compile/link to complete. If it is in /usr/lib64 or /usr/local/lib64, then we know there is already a /usr/lib and /usr/local/lib, so the 'link' solution can NOT be used. I guess the only solution for this would be to move everything out of the 'lib64' into lib... or indeed into somewhere like - /games/orig/usr/lib[64] And be aware, except for the /usr/lib move you will then have to add a 'fix' when ever you run 'fgfs', since now the dynamic shared runtime library loader will also not be able to find osgFX, and all the other OSG shared libraries... To run 'fgfs' you will have to do - export LD_LIBRARY_PATH=/games/orig/usr/lib64 or export LD_LIBRARY_PATH=/games/orig/usr/lib if you created the suggested 'link'. And this will also apply when you run say fgviewer, or others that depend on the OSG shared libraries, so can be a bit of a pain... Or this can be made 'permanent' by adding another say osg.conf to /etc/ld.so.conf.d since my /etc/ld.so.conf contains a line - include /etc/ld.so.conf.d/*.conf Something I think maybe cmake OSG should have done... Now whether or not this can be classified as a FG 'bug' is a mute point. As Lee and others have pointed out, I do think FG auto configuration could have a check for say osgFX, or osgDB, and politely exit with message before it is seen in the actual compile/link... I have NO problems compiling, linking, and running in my Ubuntu 64-bit, and to share how I get around all this - $someroot in my case is '/home/geoff/fg/fg7' but can be just about anything... 1. OSG - I use - cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_CXX_FLAGS=-O3 \ -D CMAKE_C_FLAGS=-O3 \ -D CMAKE_INSTALL_PREFIX:PATH=$someroot/install/OSG281 This installs the OSG libraries in $someroot/install/OSG281/lib64 And the OSG headers are thus installed in $someroot/install/OSG281/include and say osgviewer binary in $someroot/install/OSG281/bin Then in this folder $someroot/install/OSG281 I make a link lib -> lib64 2. PLIB ./configure --prefix=$someroot/install/plib \ --exec-prefix=$someroot/install/plib 3. SG ./configure --prefix=$someroot/install/simgear \ --exec-prefix=$someroot/install/simgear \ --with-osg=$someroot/install/OSG281 \ --with-plib=$someroot/install/plib \ --with-jpeg-factory \ --with-boost=$someroot/install/boost 4. FG ./configure --prefix=$someroot/install/fgfs \ --exec-prefix=$someroot/install/fgfs \ --with-osg=$someroot/install/OSG281 \ --with-simgear=$someroot/install/simgear \ --with-plib=$someroot/install/plib This is using OSG release 281, but this approach gives me the flexibility of using the later 282, of even the OSG svn trunk... likewise with various release versions, or svn, of plib... perhaps the only case for using non-standard directory installations... Of course, I have ALL this in a script - http://geoffair.net/tmp/makefg so I do NOT have to remember each time... and that script generates a run_fgfs.sh script, that does the export LD_LIBRARY_PATH thingy before running fgfs... And as you can read in that script, I have a 'switch' to install OSG in the 'standard' path, /usr/lib etc, but never got that working ;=() I will add and test a few additions to configure.ac to 'search' for the OSG libraries, like we do for most others, and present it shortly... and maybe others, like Erik says, have ideas on this... maybe it would also be possible to ferret out even a 'lib64' installation... HTH, Regards, Geoff. ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
