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

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to