Message ID | 20160315172001.GA14803@datura.dylex.net |
---|---|
State | New |
Headers | show |
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
diff -u math/Makefile --- a/math/Makefile 2016/02/18 17:54:00 1.1 +++ b/math/Makefile 2016/03/11 01:31:41 @@ -100,7 +100,8 @@ cat $<; \ echo 'GROUP ( $(slibdir)/libm.so$(libm.so-version) ' \ 'AS_NEEDED ( $(libdir)/libmvec_nonshared.a $(slibdir)/libmvec.so$(libmvec.so-version) ) )' \ - ) > $@ + ) > $@.new + mv -f $@.new $@ endif # Rules for the test suite.