On Mon, 2010-02-08 at 10:30 +0100, Stefan Seifert wrote: > On Saturday 06 February 2010 21:29:23 Csaba Halász wrote: > > > Well, I still think the sensible thing is to expect *native* libraries > > in /lib, whatever native may be. If you are on 64 bit, that means 64 > > bit libraries go into /lib and not /lib64. The only situation I would > > expect /lib64 is if I am on a 32 bit system. If I am sitting on a 64 > > bit machine and I need 32 bit libraries, I put the 32 bit libraries > > elsewhere separated from my native libs (which is what debian does - > > you get /lib32). > > On x86_64, _both_ 32 and 64 bit are native. So it's a pretty arbitrary > choice, > which libraries you put in lib and if you have an accompanying lib32 or lib64 > directory. openSUSE for example puts 32 bit libs in lib and has lib64 > directories which has the nice advantage, that there has never been a > compatibility problem. Running 32 bit Java/Flash/wine/... on an otherwise 64 > bit system is a non-issue. No chroot or workarounds like that needed. I only > could wonder when I read about problems, why distributions would do that to > their users... > > Stefan
I think this touches the real question - what does 'native' mean? I do not particularly agree that on x86_64 _both_ 32 and 64 are 'native'. Native should mean 64-bits, in a 64-bit system, and thus /usr/lib should contain (only or at least mainly) 64-bit libraries. This seems how my Ubuntu 8.04 64-bits considers things, probably since it is 'debian' based, and thus also has a /usr/lib32, presumably for 32-bit backward compatible libraries. And in fact, perhaps really the problem is that the auto-tool macro AC_CHECK_LIB() has yet to catch up with this... Maybe it should first append 'lib' to the "$prefix", and check there, the 'native' place to look, and if the OS is 64-bit, also try appending 'lib64'... and then generate the appropriate /I path/lib[64] for the make files... or is that asking too much ;=)) But then that would also require the dynamic shared library loader to do likewise, but at least it can be helped through /etc/ld.so.conf... And maybe there is a way to tell the OSG cmake this fact so it would use /usr/lib or "$prefix/lib", in this all 64-bit system... and thus alleviate the 'link' step, but cmake is another world of 'options' I have yet to fully explore... And it only seems to use '$prefix/lib64' during the post build 'install' step, since it creates and uses just 'lib' in the source build folder ;=() Lots to 'understand' here... That is can we instruct cmake to go native ;=)) and thus on 64-bit system not generate yet 'another' folder name? 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
