On 02/06/2010 02:32 AM, Erik Hofman wrote: > As I see it this might actually be a problem for the Linux vendor. They > should have added /usr/lib64 to /etc/ld.so.conf
That does not fix the main problem. It does not fix the bug that I am reporting. ld.so.conf is meaningful at runtime. The problem is that the program never gets to runtime, because "make" fails at link-time. Also ./configure is documented to allow the libraries to be in places other than /usr/anything. It says the configuration is correct, but then emits buggy makefiles. > Another thing that has bugged me about osg though is that is places it's > plugins in /usr/(local/)lib/osgPlugins-<version-number> > This is very hard to catch in a configure script and is only solved by > adding that directory to ld.so.conf Messing with the system-wide /etc/ld.so.conf is not the "only" way of dealing with the libraries at runtime. In particular, it should be -- and is -- possible to compile, link, and run FG without having root access to the machine. See also important note below. Chez moi it suffices to add CXXFLAGS="$CXXFLAGS -Wl,-rpath=$parent/usr/lib64" to the environment of every ./configure invocation. Another way would be to use LD_LIBRARY_PATH in the runtime environment. This is all fine *provided* the user can get past the buggy "./configure ; make" step. In any case, these runtime problems (and solutions) are irrelevant to the bug I am reporting. ====================== Note: It is actually very important for me, and for other people I support, to have various versions of the libraries installed in various places other than default, global, system locations such as /usr/lib/. One reason is that I often need to run multiple different versions of FG. -- I need to run the _sport model_. Experience shows that most of the features of the sport model eventually get incorporated into the main line ... but it often takes months or years for this to happen. -- I need to run the stock version whenever I want to report a bug, to guard against the extremely remote possibility that there are bugs in the sport version that are not in the stock version. On 02/06/2010 04:15 AM, Jon Stockill wrote: >> Curtis Olson wrote: >>> I don't doubt that there could be some lib vs. lib64 inconsistencies, >>> but FilghtGear builds right out of the box for me on 64bit Fedora 12 ... >>> no hitches at all that I recall and it has done so for quite some time. >> >> Same for me on slackware64. Does that include downloading OSG from the OSG site and compiling it according to the instructions, on a machine where the "distro-package" version of OSG has not been installed? It would be odd if people were required to compile FG from source but forbidden to compile OSG from source. I would remind people that for much of the time in recent years, the required-for-FG version of OSG has been ahead of the distro-package version. So being able to compile OSG from OSG source (not distro source) is not a trivial or wacky idea. ------------------------------------------------------------------------------ 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
