[Clfs-dev] /lib64/modules considered harmful

Ken Moffat zarniwhoop at ntlworld.com
Thu Nov 22 16:02:20 PST 2007


 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



More information about the Clfs-dev mailing list