Re: [lfs-dev] Possible binutils-2.36 problems
On Mon, 2021-02-08 at 19:36 +0100, Pierre Labastie via lfs-dev wrote: > On Fri, 2021-02-05 at 17:40 +, 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
Re: [lfs-dev] Possible binutils-2.36 problems
On Fri, 2021-02-05 at 17:40 +, 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 Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Possible binutils-2.36 problems
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 root39440 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 root18776 Feb 2 17:44 libcom_err.so.2.1 > -rwxr-xr-x 1 root root43288 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. ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Possible binutils-2.36 problems
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 root39440 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 root18776 Feb 2 17:44 libcom_err.so.2.1 -rwxr-xr-x 1 root root43288 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 -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
