| Newsgroups |
gmane.linux.lfs.support |
| Message-ID |
<[email protected]> |
Am 13.08.26 um 14:58 schrieb Eric Clothier ([email protected] via
lfs-support Mailing List):
> 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.
At the time (almost 5 years ago) /usr/lib64 was indeed created by
(faulty) extra-cmake-modules-5.89.0. The following package was
libdrm-2.4.107 which then installed its libraries in /usr/X11/lib64
instead of /usr/X11/lib. According to Xi Ruoyao, meson uses "lib64" as
the default "--libdir" if it finds a /usr/lib64.
The build of mesa-21.3.1 then failed because of this. It took me a
while to figure out that a stealthily created /usr/lib64 was behind this
but after removing it and also /usr/X11/lib64 and rebuilding libdrm, the
system was healthy again and the build of mesa succeeded.
Hence the guard in my build-system. ;)
Rainer
--
http://lists.linuxfromscratch.org/sympa/info/lfs-support
Unsubscribe: See the above information page