math/Makefile: don't clobber old libm.so on install [BZ #19822]

When installing glibc >= 2.22 in-place on a x86_64-pc-linux system with glibc
<= 2.21, the install will clobber the existing libm.so (e.g.,
/lib64/libm-2.21.so) with a linker script.  As a result, anything depending on
libm will fail to run (and running processes will segfault) and the install
fails.  This is because the makefile writes the linker script directly to
/lib64/libm.so.6, which is a symlink.

The simple patch below to math/Makefile fixes this.  It is based on the nptl
Makefile, which does exactly the same thing in a safer way.

I can confirm that without this patch a glibc 2.22 or 2.23 "make install"
renders my system unusable, but with it 2.23 installs just fine.  (I note that
by the time the install is finished, libm.so.6 is a symlink again, presumably
from ldconfig, so I'm not exactly sure why it's making a linker script.)

---

On 15 Mar 2016 13:20, Dylan Alex Simon wrote:
> When installing glibc >= 2.22 in-place on a x86_64-pc-linux system with glibc
> <= 2.21, the install will clobber the existing libm.so (e.g.,
> /lib64/libm-2.21.so) with a linker script.  As a result, anything depending on
> libm will fail to run (and running processes will segfault) and the install
> fails.  This is because the makefile writes the linker script directly to
> /lib64/libm.so.6, which is a symlink.

i guess the issue comes up when you are moving from a non-mathvec setup
to having mathvec installed.  non-mathvec doesn't use ldscripts, but the
matchvec code does.

> The simple patch below to math/Makefile fixes this.  It is based on the nptl
> Makefile, which does exactly the same thing in a safer way.

patch looks fine

> I can confirm that without this patch a glibc 2.22 or 2.23 "make install"
> renders my system unusable, but with it 2.23 installs just fine.  (I note that
> by the time the install is finished, libm.so.6 is a symlink again, presumably
> from ldconfig, so I'm not exactly sure why it's making a linker script.)

libm.so.6 isn't supposed to be a linker script, libm.so is.
that's what this rule is installing -- libm.so.
-mike

On Tue, 15 Mar 2016, Mike Frysinger wrote:

> > The simple patch below to math/Makefile fixes this.  It is based on the nptl
> > Makefile, which does exactly the same thing in a safer way.
> 
> patch looks fine

So you should commit it, since the submitter doesn't have commit access.

On 15 Mar 2016 18:33, Joseph Myers wrote:
> On Tue, 15 Mar 2016, Mike Frysinger wrote:
> > > The simple patch below to math/Makefile fixes this.  It is based on the nptl
> > > Makefile, which does exactly the same thing in a safer way.
> > 
> > patch looks fine
> 
> So you should commit it, since the submitter doesn't have commit access.

i'm aware.  i wanted to wait to see if anyone else had feedback first.
-mike

The change makes it consistent with how the $(inst_libdir)/libc.so
target in Makerules works, so that's fine for now (with ChangeLog
entry, of course).

In the long run, I think we probably want to change things so that
nothing is constructed in place in the installation directories like
that.  They should be created locally somewhere and then installed
using a normal $(INSTALL_DATA) command.


Thanks,
Roland