-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Robert,
Robert Osfield wrote: > Yes this is what I mean, and I agree /usr/local/lib64 "should" be > where such 64bit libraries should be installed. > > Almost all of other 3rd party libraries that I've built on my machine > install into /usr/local/lib rather than /usr/local/lib64, I presume > out of not knowing/caring about the /usr/local/lib64 convention for 64 > bit libs, or it's a pragmatic decision based on problems with Linux > distro's not including /usr/local/lib64 in there default search path. It is mostly ignorance, most open source developers do not think about making their project truly cross-platform and portable and assume it will be built on i586 and Linux only (or whatever their development machine runs) :( A sad truth - I had to fix my share of broken libs that assumed that sizeof(int) == 4, installed libs in lib instead of lib64 (and overwrote libs for the 32bit binaries) and such. The issue above is straight in the same vein. > Making the OSG compile, install and run out of the box with mods very > much my concern. Linux is one of most commonly used platforms so > making things as seamless as possible is important. If this means > being pragmatic about things then I'm prepared to be. I am a long time Linux developer and user too, and perpetuation of such kludges causes no end of trouble. Fighting brokenness with brokenness is a bad idea - then the issue will never get fixed because major software X relies on a bug Y and would break if it is fixed, so the kludge is carried on ... The LSB filesystem standard is there for a reason. The out-of-the-box experience is of little concern for me - OSG is not an end-user product but something used by developers who should know about library search path. Breaking a standard practice for a little convenience is a bad trade-off in my book. Do you still remember how it is on Windows? Every application drops files wherever it wants - in Windows, Windows\System32, overwriting other files, etc, resulting in issues like DLL hell. I would hate seeing something like that on Linux (or other Unix platforms). If you want to provide out-of-the-box working solution, I would really go for pre-built packages, at least for the stable releases. For development releases I do not think this is at all an issue. > This does sound a possible solution, but.. it would require building > of the packages and then installing, which is a two stage process > rather than a single stage. It also requires CPack to support rpms > and debians to be mature enough to do this. The build system could offer an option to invoke rpm or dpkg to install the packages after they are built. That is not really a big issue. I am not familiar with CPack, but in essence what you need is a SPEC file for RPM (which can be static - it doesn't really change unless you add/remove files and the file list could be perhaps generated by cmake) and then invoke rpmbuild -b foo.spec to assemble the package. It could be invoked as a custom command after the target is built. > Perhaps another solution would be to have Cmake's install scripts add > /usr/local/lib64 (or whatever the path is) to /etc/ld.so.conf > automatically if it's not already there. That is also an option, however, modifying system-wide config files (especially an important one like ld.so.conf) is generally a bad idea for a 3rd-party app. One bug in a script somewhere and your system is unusable. Also, only root can modify these files, so it would have to handle the case when the installation is done into a user-writable directory, not system-wide. I would leave modification of such files to rpm/dpkg or similar tools. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJfIeXn11XseNj94gRAhaCAJ43dW8bnzLX8h7WZNcItY1YzTVSAQCgl6lF 6fG2J3jND/Q+tLUP++1WRdg= =Y/LV -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
