Re: Dump commands

On Thu, Aug 13, 2026, 08:39 Rainer Fiebig <
[email protected]> wrote:

> Am 13.08.26 um 13:09 schrieb Pocket ([email protected] via
> lfs-support Mailing List):
> >
> >
> > On 8/13/26 06:58, Rainer Fiebig ([email protected] via lfs-support Mailing
> > List) wrote:
> >> Am 13.08.26 um 03:41 schrieb Bruce Dubbs ([email protected] via
> >> lfs-support Mailing List):
> >>> On 8/12/26 2:51 PM, Pocket ([email protected] via lfs-support
> >>> Mailing List) wrote:
> >>>>
> >>
> >> / snip /
> >>
> >>>> case $(uname -m) in
> >>>>     x86_64) chown -v lfs
> >>>>    $LFS/lib64 ;;
> >>>> esac
> >> / snip /
> >>
> >> Successful execution of
> >>
> >>     chown -v lfs $LFS/lib64
> >>
> >> does not depend on whether the machine is x86_64 or not but whether
> >> directory "$LFS/lib64" exists or not.  That directory was already
> >> created (or not) in ch. 4.2:
> >>
> >> case $(uname -m) in
> >>    x86_64) mkdir -pv $LFS/lib64 ;;
> >> esac
> >>
> >> So the test in ch. 4.3 should _not_ be
> >>
> >> case $(uname -m) in ...
> >>
> >> but rather
> >>
> >> if [[ -d $LFS/lib64 ]]; then
> >>     chown -v lfs $LFS/lib64
> >> fi
> >>
> >> Apart from that I'm not sure whether using multi-way decision-test
> >> "case" for a one-way test is really a good choice for an educational
> >> project.  At least not without a default case.
> >>
> >> BTW: I think that the dot after the last digit in chapter-headings like
> >>     4.3. Adding the LFS User
> >> is wrong or at least quite unusual.
> >>
> >>
> >> Rainer
> >>
> >>
> >
> > I have no idea how to grok what you posted.
>
> I didn't reply to your post.  I only quoted part of it to make aware of
> an inconsistency in the book's instructions.  Bruce will probably know
> what I mean.
>
> >
> > The segment I posted was to informational as it is missing the trailing
> '\'
> >
> > But since you brought it up....
> >
> > 4.2. Creating a Limited Directory Layout in the LFS Filesystem
> >
> >  Note
> >
> > The LFS editors have deliberately decided not to use a /usr/lib64
> > directory. Several steps are taken to be sure the toolchain will not use
> > it. If for any reason this directory appears (either because you made an
> > error in following the instructions, or because you installed a binary
> > package that created it after finishing LFS), it may break your system.
> > You should always be sure this directory does not exist.
> >
> >
> > But the book does create lib64 directories,  then tells you is will
> > break your system.
>
> Only /usr/lib64 will break the system.  It may be created by a package
> that you installed.  I once had this problem with (IIRC)
> "extra-cmake-modules".  Since then I have a guard in my build-system:
>
>         if [[ -d /usr/lib64 ]]; then
>                 sudo mv -vf /usr/lib64{,.NOUSE}
>         fi
>
> This is run before any package is being built.
>
> Rainer
>
> --
>

As a further little tidbit to the `/lib64` vs `/usr/lib64` question, they
are two separate directories for two separate purposes.

`/lib64` is where the x86-64 ELF ABI expects to find the dynamic linker.
LFS honors that requirement.

`/usr/lib64` is a distribution policy choice by some modern multibit
general purpose distributions. By default, LFS builds for a single bit
width (i.e. 32bit or 64bit), so there is no reason to use `/usr/lib64`, and
the book makes the policy decision that the default library path is
`/usr/lib` regardless of bit width, and a package finding and using
`/usr/lib64` indicates a broken system.

I hope that clears up some confusion on `/lib64` vs `/usr/lib64`.

- Eric

>

-- 
http://lists.linuxfromscratch.org/sympa/info/lfs-support
Unsubscribe: See the above information page