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

On Thu, 2025-02-20 at 10:36 -0600, Bruce Dubbs wrote:
> On 2/20/25 10:22 AM, Xi Ruoyao ([email protected] via lfs-support Mailing List) 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.
> 
> It sounds like the original mistake was running the chown command above as root, but 
> $LFS was not defined for the root user.

But it cannot explain why $LFS_TGT-ld can find host libseccomp, and a
wrong symlink explains both phenomena perfectly.

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