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

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.

[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.

> Maybe I have overlooked a line in the book (12.2) but it seems that the
> instructions only _assume_ that the user is in $LFS when starting the
> for-loop but don't make sure that he actually is.
> 
> So, perhaps a  cd $LFS  after the mkdir-statement should be added to
> ensure that the links are set correctly.

-- 
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University

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