-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert Osfield wrote:
> Hi Jan,
>
> The FHS docs talk about /usr/lib64 for 64bit, but in all it's
> discussion of /usr/local it only discusses /usr/local/lib there is
> absolutely no mention of /use/local/lib64. So rather than ambiguous
> it just doesn't say anything other than /usr/local/lib for locally
> installed libs.
>
> The LSB discussions are also just about /usr/lib and /usr/lib64. I
> haven't spotted anything about /usr/local/lib or /usr/local/lib yet.
> Debian/Ubuntu do now use /usr/local/lib64, but with a with the
> symbolic link to from /usr/lib to /usr/lib64 I presume for package
> compatibility.
The snippet I have quoted says that anything lib<qual> where <qual> is
any kind of qualifier (32, 64, arm, whatever - there is not only 64-bit
Linux out there and FHS doesn't explicitly enumerate them, because they
cannot anticipate all architectures that may appear) should be used for
the alternative libraries. It doesn't speak explicitly about lib64,
because FHS is generic.
They do not talk explicitly about /usr/local/lib, with the exception
that if alternatives are in /usr/lib<qual>, then corresponding
/usr/local/lib<qual> has to exist too. It is because it is assumed that
same rules as for /usr/lib apply, only for locally installed software.
This is inherited from UNIX. E.g. IRIX has /usr/local/libn32
/usr/local/libo32 and /usr/local/lib64 due to its three ABIs ("old"
32bit, "new" 32bit and 64bit one, binaries for all three can run on the
same system) if I recall correctly.
Re Debian/Ubuntu link - yes, that is likely the reason, however it also
makes a peaceful coexistence of both 32 and 64 bit binaries impossible.
You may want to compile OSG for both architectures for e.g. debugging or
development reasons (you can run them both on 64bit system if you have
the 32bit dependencies installed), but they would overwrite each other
or the dynamic linker will attempt to load libs for the wrong arch
thanks to this "compatibility" kludge.
>
> As general principle I believe putting 64bit libs in /usr/local/lib64
> is more consistent than putting them in /usr/local/lib, but as yet
> I've seen no evidence that the LSB or other docs say that the standard
> for locally installed 64 bit libs is /usr/local/lib64, asserting that
> /usr/local/lib64 is an official standard for 64 doesn't look to be
> substantiated.
I think the FHS specification is quite clear on this. Why would they
mandate the existence of the qualified directories under /usr/local if
they were not to be used or the use was optional??
Of course, you will not find a lot of software installed there in an
out-of-the-box situation, because it is intended for local installs.
However, googling for /usr/local/lib64 will bring up a lot of posts
describing software compilation/installation using that directory.
Strictly speaking, you can put the libraries wherever you want, it will
work with sufficient changes to the system config. However, it is good
to stay with the conventions others are using - it prevents a lot of
headaches.
>
> The only concrete info I have so far is that (K)Ubuntu (and probably
> debian) only add /usr/local to the ld.so.conf setup even for 64bit
> builds. What do other distribution do?
I checked on my Mandriva. I have only 32bit version available at the
moment, but it doesn't put even /usr/local/lib in the search path by
default. I have it defined in the LD_LIBRARY_PATH variable in my login
script. I think the idea has to do with security, so that if you want to
load some strange libraries, you need to enable it explicitly, but I may
be wrong there.
Regarding the existence of the /usr/local/lib64 folder:
- - I have checked the existence of the folder and 64 bit Mandriva creates
the /usr/local/lib64 by default (as required by FHS) using the
filesystem package (e.g. filesystem-2.1.9-5mdv2009.0.x86_64.rpm on 2009,
you can see its content here:
http://sophie.zarb.org/viewrpm/1cae9ecefab5fd458f0703f8523a07d5/files)
- - Also RedHat/Fedora seems to provide the /usr/local/lib64 directory by
default, as seen here:
http://rpmfind.net//linux/RPM/fedora/devel/x86_64/filesystem-2.4.19-1.fc10.x86_64.html
(you need to download the package to inspect it)
- - Suse has the directory as well:
http://rpmfind.net/linux/RPM/suse/updates/10.0/i386/rpm/x86_64/filesystem-10.0-4.2.x86_64.html
(you need to download the package to inspect it)
None of the above creates it as a symlink, that seems to be
Debian(Ubuntu)-specific issue.
> W.r.t practicality of copying a openscenegraph.conf, this would
> require a /etc/ld.so.conf.d directory to exist and /etc/ld.so.conf
> that includes all entries in this directory. I only have Kubuntu
> boxes here so can only check locally what these use, I need feedback
> from others that what there systems use.
Mandriva has this at least since 2006 or so, most likely RedHat and
PCLinuxOS (Mandriva derivative) too. Other reasonably modern distros
probably as well, but I have no means to check it. Unfortunately, it is
not required by FHS, so there will be some systems that do not have it.
>
> As a change to our build system, and to what we install, copying such
> a file is more of intrusive a change than installing to /usr/local/lib
> rather than /usr/local/lib64.
Except that it will probably not change anything - at least on Mandriva
I still have to put the directory in the search path by hand, regardless
of where you install, unless you put the files into /usr/lib or /lib
(which shouldn't be done). Most likely Mandriva is not the only such
system, but I do not have other distros on hand to test that.
> Moving to using rpm or debian for install is an even bigger step, as
> it would no longer be about a local install of the software into
> /usr/local but a full install into system directories, and is
> conceptually different from a conventional make install that
> developers will be used to. The is also a big question of how mature
> the debian/rpm support is in CPack. I'm all for creating such
> packaging when CPack is ready, but I believe this type of install is
> quite distinct from a developer installing libs s/he builds.
Agreed. However this wouldn't be something people will do regularly. It
shouldn't be a replacement for regular "make install".
The packages for stable releases will be provided either by the distros
themselves (e.g. Mandriva has OSG in the repositories like that, but an
ancient version - having a working upstream spec file would ease the
maintenance load) or somewhere online for download, as you have for the
Windows version. If, as a developer, you require the convenience of not
having to deal with things like LD_LIBRARY_PATH, you are most likely not
going to build the SVN trunk neither and will get the pre-built binaries
for your distro instead.
Regards,
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJfZSUn11XseNj94gRAnvjAKCQKdWj4HxbTE9sOpqrQYwdFsUWQwCgxuLs
wYkb6enrprsJQmceEfpTjaE=
=3GS2
-----END PGP SIGNATURE-----
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
