One thing I'd like to clarify: I wish people wouldn't be so quick to assume that Joe User is a non-programmer and/or an idiot.
I never said that, and I never meant to imply that. Let's suppose Joe has a PhD in biochemistry, and has written 100,000 lines of code in the last few years. There are *lots* of scenarios where Joe and other non-idiots might want to compile OSG from source. -- For starters, Joe might have access but *not* root access to a super-high-end graphics system. -- Maybe Joe has root access but doesn't want to use it for this purpose, for security reasons. -- Maybe Joe wants to install multiple versions, for comparison purposes. -- Maybe Joe's distro provides a slightly elderly version of OSG, not advanced enough for use with FG, and Joe doesn't want to upgrade his entire software base just so he can try out some game. One of the things I like about Linux is that it allows users to do things without requiring every user to be superuser. I emphasize yet again that messing with ld.so.conf is nowhere near being a solution (let alone a documented solution, much less an out-of-the-box solution) in use-case scenarios of this sort. The inappropriateness of messing with ld.so.conf is particularly obvious in scenarios where there are multiple installed versions. In such scenarios, appropriate solutions include passing LD_LIBRARY_PATH in the environment at runtime, or passing "rpath" options to the linker at link-time. I remain quite aware that there are ways of getting things to work in Joe's scenarios -- quite a few ways actually -- but they all involve doing something that the average biochemist will find non-obvious. The LIB_POSTFIX flag, for example, is a fine idea, but it is not mentioned anywhere in the OSG *or* FG documentation so far as I can tell. The claim that Joe User can install OSG and FG from source "out of the box" is untenable. ======= The claim that I wrongly specified putting OSG into lib64 is entirely baseless. None of my configuration options specify anything of the sort. The configuration flags specify a higher-level directory; OSG creates the lib64 directory all by itself. This is the OSG default behavior. More generally, I must disagree with the claims that the problems arise because OSG has been installed in a "wrong" place. The crux of the argument is that ./configure has two phases, one where it finds stuff to make sure all needed components have been installed, and another where it emits makefiles. Common sense suggests that the first phase and the second phase should play by the same rules. In particular, the first phase of ./configure operates by compiling tiny test programs. I'm still waiting for somebody to explain why the ./configure script knows how to compile these test programs just fine, but doesn't know how to compile SG and FG. ------------------------------------------------------------------------------ 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
