Is it just me, or does anybody else who builds kernels for multilib
get really pissed off with /lib64/modules ? The first time you
follow the book, it's just another sed to put the modules into
/lib64. But after that, you have to remember to change the Makefile
before compiling a new kernel. And if you are running a git bisect,
you have to do it every £ß!# time.
As far as I can make out, the distros who provide multilib systems
all put the kernel modules in /lib. Perhaps their argument is that
they are independent of the libraries in /lib{,64}, or maybe they
just go with what the kernel sets out. As far as I can see, clfs is
out on a limb here in using /lib64/modules and I don't see any
benefit from it, only aggravation.
Looking at http://www.pathname.com/fhs/pub/fhs-2.3.html, all I can
see is
>/lib<qual> : Alternate format essential shared libraries (optional)
>
>Purpose
>There may be one or more variants of the /lib directory on systems
>which support more than one binary format requiring separate
>libraries. [14]
>
and the note says
>[14] This is commonly used for 64-bit or 32-bit support on systems
>which support multiple binary formats, but require libraries of the
>same name. In this case, /lib32 and /lib64 might be the library
>directories, and /lib a symlink to one of them.
As far as I can see, We only ever have one 'modules' directory
(whether that is /lib64/modules or /lib/modules) on a multilib
system because it cannot run 32-bit kernels with 64-bit system
libraries. Also, note that the description for '/lib' itself is
>/lib : Essential shared libraries and kernel modules
so even fhs thinks that kernel modules belong in /lib, and only
shared libraries belong in /lib64.
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
