On Mon, 2021-02-08 at 19:36 +0100, Pierre Labastie via lfs-dev wrote: > On Fri, 2021-02-05 at 17:40 +0000, Ken Moffat via lfs-dev wrote: > > On Fri, Feb 05, 2021 at 10:39:08AM -0600, Bruce Dubbs via lfs-dev > > wrote: > > > On 2/5/21 6:48 AM, Ken Moffat via lfs-dev wrote: > > > > While replying to Frans on -support re his inability to build > > > > glibc-2.33, I glanced at the binutils bugs > > > > https://www.mail-archive.com/bug-binutils@gnu.org/ and said > > > > that > > > > 2.36 might be buggy. At that time I hadn't read all the links > > > > gurgle found for me. One of them is > > > > https://www.linuxquestions.org/questions/linux-from-scratch-13/binutils-2-36-strip-4175689760/ > > > > which looks *really* annoying. > > > > > > I took a look at the above link, but I cannot reproduce the > > > problem > > > with LFS > > > instructions. In my test build in /mnt/lfs/lib I have: > > > > > > > > > [ /mnt/lfs/lib ]$ ll libc* > > > lrwxrwxrwx 1 root root 14 Feb 2 16:20 libcap.so.2 -> > > > libcap.so.2.47 > > > -rwxr-xr-x 1 root root 39440 Feb 2 17:44 libcap.so.2.47 > > > lrwxrwxrwx 1 root root 17 Feb 2 17:44 libcom_err.so.2 -> > > > libcom_err.so.2.1 > > > -rwxr-xr-x 1 root root 18776 Feb 2 17:44 libcom_err.so.2.1 > > > -rwxr-xr-x 1 root root 43288 Feb 2 17:44 libcrypt-2.33.so > > > lrwxrwxrwx 1 root root 16 Feb 2 16:10 libcrypt.so.1 -> > > > libcrypt-2.33.so > > > -rwxr-xr-x 1 root root 1835448 Feb 2 17:44 libc-2.33.so > > > -rwxrwxr-x 1 root root 11946280 Feb 2 17:44 libc-2.33.so.dbg > > > lrwxrwxrwx 1 root root 12 Feb 2 16:10 libc.so.6 -> libc- > > > 2.33.so > > > > > > [ /mnt/lfs/lib ]$ file libc-2.33.so > > > libc-2.33.so: ELF 64-bit LSB shared object, x86-64, version 1 > > > (GNU/Linux), > > > dynamically linked, interpreter /lib/ld-linux-x86-64.so.2, for > > > GNU/Linux > > > 3.2.0, stripped > > > > > > [ /mnt/lfs/lib ]$ file libcap.so.2.47 > > > libcap.so.2.47: ELF 64-bit LSB shared object, x86-64, version 1 > > > (SYSV), > > > dynamically linked, stripped > > > > > > So the book does what we want. On the other hand, we do not do > > > an > > > unconditional strip on anything. We start with find /lib > > > /usr/lib > > > -type f > > > -name \*.so* ... so that would skip symlinks. > > > > > > We use the same structure in BLFS Section "Notes on Building > > > Software". > > > > > > On the other hand, doing an explicit strip on a symlink does > > > replace the > > > symlink with the stripped version of the link's resolved file. > > > > > > I can confirm that running strip against a symlink on a system > > > with > > > binutils-2,25 does not affect the symlink. > > > > > > -- Bruce > > > > > Hi Bruce, > > > > thanks for looking at this. At the moment I don't have 2.36, I'm > > just warning that some people are reporting enough > > changed/unexpected behaviour that this might cause problems. > > > > good to know that we are not directly affected by the stripping > > change. > > > > Huh, As I read above "doing an explicit strip on a symlink does > replace the symlink with the stripped version of the link's resolved > file", while for 2.35: > "binutils-2,25 does not affect the symlink" (guess Bruce meant 2.35) > > Another report of a similar problem (maybe more annoying): > https://bugs.archlinux.org/task/69584 > > strip seems to change the ownership of a file to that of the user > running strip. > > Also (maybe a fakeroot problem): > https://sourceware.org/pipermail/binutils/2021-February/115241.html >
The issue with ownership seems to be a fakeroot problem (when compiled with glibc-2.33 and binutils-2.36), sorry for the noise. And the book itself is immune to the symlink problem since we use "find -type f". Looks like upstream has fixed some CVE by changing the behavior, so we'll have to live with it. Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
