Re: LFS build of File-5.45 problem stops on compilation of seccomp.c

Am 21.02.25 um 11:19 schrieb Xi Ruoyao ([email protected] via
lfs-support Mailing List):
> On Fri, 2025-02-21 at 11:11 +0100, Rainer Fiebig wrote:
>> Am 20.02.25 um 17:29 schrieb Xi Ruoyao ([email protected] via
>> lfs-support Mailing List):
>>> On Fri, 2025-02-21 at 00:22 +0800, Xi Ruoyao wrote:
>>>> On Thu, 2025-02-20 at 09:20 -0600, dave kohler wrote:
>>>>> attempt to open /mnt/lfs/lib/../lib/libseccomp.so succeeded
>>>>
>>>> So this means your symlink is indeed incorrect.  The symlink
>>>> /mnt/lfs/lib should points to the relative path usr/lib, not the
>>>> absolute path /usr/lib.
>>>>
>>>> The mistake also caused the command
>>>>
>>>> chown -v lfs $LFS/{usr{,/*},lib,var,etc,bin,sbin,tools}
>>>>
>>>> to change your /usr/lib to be owned by LFS, triggering the warning from
>>>> Arch package manager you've mentioned in another thread.
>>>>
>>>> Now you need to fix your host distro before another attempt of LFS
>>>> build.  First run "chown root /usr/lib /usr/bin" to fix the ownership.
>>>>
>>>> Then you need to check if there is any file/directory owned by the LFS
>>>> user in your /usr/lib and /usr/bin.  For each one, figure out which Arch
>>>> package should provide that file or directory, then reinstall the Arch
>>>> package.  If no Arch package should provide it, just remove it.
>>>>
>>>> After fixing Arch, start over building LFS and make sure typing correct
>>>> commands this time.
>>>>
>>>> I guess we should just remove $LFS/lib, $LFS/bin, and $LFS/sbin from the
>>>> chown command, so with an incorrect symlink the build will fail early at
>>>> Chapter 5 Glibc instead of silently breaking the host distro.  I'll do
>>>> it after the 12.3 release.
>>>
>>> https://wiki.linuxfromscratch.org/lfs/ticket/5655
>>
>> Maybe the problem is not the chown-statement but these two steps:
>>
>>
>> mkdir -pv $LFS/{etc,var} $LFS/usr/{bin,lib,sbin}
>>
>> for i in bin lib sbin; do
>>   ln -sv usr/$i $LFS/$i
>> done
>>
>>
>> While the mkdir-statement produces the intended results irrespective of
>> where it is issued, the for-loop only does so if the user is in
>> /mnt/lfs.  If he happens to be in / of the host-system, the results are
>> what we have seen in this case, even if he copied/pasted the
>> instructions, as the OP claims to have done.
> 
> No this is not true.  Even if you are in /, the symlinks are still
> created with relative paths.  This is a common misunderstanding about
> the ln command and the reason we have the infamous "the above command is
> correct" note in Chapter 5 Glibc.
Now contrast this with what's in "info ln":

When creating a relative symlink in a different location than the
current directory, the resolution of the symlink will be different than
the resolution of the same string from the current directory.
Therefore, many users prefer to first change directories to the location
where the relative symlink will be created, so that tab-completion or
other file resolution will find the same target as what will be placed
in the symlink.

No wonder that there's a "common misunderstanding about the ln command",
IMO. ;)

Anyway - thanks for the clarification.

> 
> [Ironically, if you are in / and you've added the "-r" option for
> "relative", things will indeed go wrong.  But we don't have -r here
> anyway and we never encouraged people to use it: I tried
> "grep -r 'ln.*-r'" in LFS and BLFS and there's no match.]
> 
> And I can tell he didn't copied the instructions because in his
> environment there was
> 
> CONFIG_SITE=/mnt/lfs/user/share/config.site
> 
> Note that "usr" was typed as "user" and this cannot happen with copy-n-
> paste.
Right.  Never trust a user on *-support. ;)

Rainer

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