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

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.

Note the caution in Section 2.6. Setting the $LFS Variable and the Umask.

   -- Bruce

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