memusagestat: use local glibc when linking [BZ #18465]

  The memusagestat is the only binary that has its own link line which
causes it to be linked against the existing installed C library.  It
has been this way since it was originally committed in 1999, but I
don't see any reason as to why.  Since we want all the programs we
build locally to be against the new copy of glibc, change the build
to be like all other programs.

2015-03-31  Mike Frysinger  <vapier@gentoo.org>

	[BZ #18465]
	* malloc/Makefile (others): Add memusagestat.
	($(objpfx)memusagestat): Delete rule.
	(LDLIBS-memusagestat): New variable.
---
 malloc/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
  

Mike Frysinger <vapier@gentoo.org> writes:

> The memusagestat is the only binary that has its own link line which
> causes it to be linked against the existing installed C library.  It
> has been this way since it was originally committed in 1999, but I
> don't see any reason as to why.

Probably because $(objpfx)memusagestat.o is compiled specially.

Andreas.
  

On 30 May 2015 22:20, Andreas Schwab wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> 
> > The memusagestat is the only binary that has its own link line which
> > causes it to be linked against the existing installed C library.  It
> > has been this way since it was originally committed in 1999, but I
> > don't see any reason as to why.
> 
> Probably because $(objpfx)memusagestat.o is compiled specially.

how so ?  looks normal to me:
gcc memusagestat.c -c -std=gnu99 -fgnu89-inline -fno-stack-protector -O2 -Wall 
-Werror -Wno-error=undef -Wundef -Wwrite-strings -fmerge-all-constants 
-frounding-math -g -Wstrict-prototypes       -U_FORTIFY_SOURCE   -I../include 
-I/usr/local/src/gnu/glibc/build/x86_64/malloc  
-I/usr/local/src/gnu/glibc/build/x86_64  -I../sysdeps/unix/sysv/linux/x86_64/64  
-I../sysdeps/unix/sysv/linux/x86_64  -I../sysdeps/unix/sysv/linux/x86  
-I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl  
-I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  
-I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  
-I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/x86_64  
-I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/x86_64/64  
-I../sysdeps/x86_64/fpu/multiarch  -I../sysdeps/x86_64/fpu  
-I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu  -I../sysdeps/x86_64/multiarch  
-I../sysdeps/x86_64  -I../sysdeps/x86  -I../sysdeps/ieee754/ldbl-96  
-I../sysdeps/ieee754/dbl-64/wordsize-64  -I../sysdeps/ieee754/dbl-64  
-I../sysdeps/ieee754/flt-32  -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  
-I../sysdeps/generic  -I.. -I../libio -I.   -D_LIBC_REENTRANT -include 
/usr/local/src/gnu/glibc/build/x86_64/libc-modules.h -DMODULE_NAME=memusagestat 
-include ../include/libc-symbols.h       -o 
/usr/local/src/gnu/glibc/build/x86_64/malloc/memusagestat.o -MD -MP -MF 
/usr/local/src/gnu/glibc/build/x86_64/malloc/memusagestat.o.dt -MT 
/usr/local/src/gnu/glibc/build/x86_64/malloc/memusagestat.o
-mike
  

Mike Frysinger <vapier@gentoo.org> writes:

> On 30 May 2015 22:20, Andreas Schwab wrote:
>> Mike Frysinger <vapier@gentoo.org> writes:
>> 
>> > The memusagestat is the only binary that has its own link line which
>> > causes it to be linked against the existing installed C library.  It
>> > has been this way since it was originally committed in 1999, but I
>> > don't see any reason as to why.
>> 
>> Probably because $(objpfx)memusagestat.o is compiled specially.
>
> how so ?

# The configure.ac check for libgd and its headers did not use $SYSINCLUDES.
# The directory specified by --with-headers usually contains only the basic
# kernel interface headers, not something like libgd.  So the simplest thing
# is to presume that the standard system headers will be ok for this file.
$(objpfx)memusagestat.o: sysincludes = # nothing

Andreas.
  

On 31 May 2015 11:40, Andreas Schwab wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > On 30 May 2015 22:20, Andreas Schwab wrote:
> >> Mike Frysinger <vapier@gentoo.org> writes:
> >> > The memusagestat is the only binary that has its own link line which
> >> > causes it to be linked against the existing installed C library.  It
> >> > has been this way since it was originally committed in 1999, but I
> >> > don't see any reason as to why.
> >> 
> >> Probably because $(objpfx)memusagestat.o is compiled specially.
> >
> > how so ?
> 
> # The configure.ac check for libgd and its headers did not use $SYSINCLUDES.
> # The directory specified by --with-headers usually contains only the basic
> # kernel interface headers, not something like libgd.  So the simplest thing
> # is to presume that the standard system headers will be ok for this file.
> $(objpfx)memusagestat.o: sysincludes = # nothing

i'm not sure how that is relevant to the linking phase.  if anything, the 
snippets i posted suggest we should be linking against the local glibc and
linking against the installed C is broken.  after all, it's using headers
from the local glibc, not the system.  there's no guarantee that the two
are compatible.  it seemingly works because people rarely run a host C lib
that isn't glibc while compiling glibc.
-mike
  

On Sun, 31 May 2015, Andreas Schwab wrote:

> Mike Frysinger <vapier@gentoo.org> writes:
> 
> > On 30 May 2015 22:20, Andreas Schwab wrote:
> >> Mike Frysinger <vapier@gentoo.org> writes:
> >> 
> >> > The memusagestat is the only binary that has its own link line which
> >> > causes it to be linked against the existing installed C library.  It
> >> > has been this way since it was originally committed in 1999, but I
> >> > don't see any reason as to why.
> >> 
> >> Probably because $(objpfx)memusagestat.o is compiled specially.
> >
> > how so ?
> 
> # The configure.ac check for libgd and its headers did not use $SYSINCLUDES.
> # The directory specified by --with-headers usually contains only the basic
> # kernel interface headers, not something like libgd.  So the simplest thing
> # is to presume that the standard system headers will be ok for this file.
> $(objpfx)memusagestat.o: sysincludes = # nothing

One option is splitting out memusagestat and other installed executables 
not depending on glibc internals or required by the glibc testsuite into a 
separate package, built using an installed C library, as I suggested in 
<https://sourceware.org/ml/libc-alpha/2012-05/msg00682.html> and 
<https://sourceware.org/ml/libc-alpha/2012-11/msg00367.html>.
  

On Mon, Jun 01, 2015 at 02:39:19PM +0000, Joseph Myers wrote:
> One option is splitting out memusagestat and other installed executables 
> not depending on glibc internals or required by the glibc testsuite into a 
> separate package, built using an installed C library, as I suggested in 
> <https://sourceware.org/ml/libc-alpha/2012-05/msg00682.html> and 
> <https://sourceware.org/ml/libc-alpha/2012-11/msg00367.html>.

+1 for making a separate glibc-utils project.

Siddhesh
  

On 01 Jun 2015 14:39, Joseph Myers wrote:
> On Sun, 31 May 2015, Andreas Schwab wrote:
> > Mike Frysinger <vapier@gentoo.org> writes:
> > > On 30 May 2015 22:20, Andreas Schwab wrote:
> > >> Mike Frysinger <vapier@gentoo.org> writes:
> > >> > The memusagestat is the only binary that has its own link line which
> > >> > causes it to be linked against the existing installed C library.  It
> > >> > has been this way since it was originally committed in 1999, but I
> > >> > don't see any reason as to why.
> > >> 
> > >> Probably because $(objpfx)memusagestat.o is compiled specially.
> > >
> > > how so ?
> > 
> > # The configure.ac check for libgd and its headers did not use $SYSINCLUDES.
> > # The directory specified by --with-headers usually contains only the basic
> > # kernel interface headers, not something like libgd.  So the simplest thing
> > # is to presume that the standard system headers will be ok for this file.
> > $(objpfx)memusagestat.o: sysincludes = # nothing
> 
> One option is splitting out memusagestat and other installed executables 
> not depending on glibc internals or required by the glibc testsuite into a 
> separate package, built using an installed C library, as I suggested in 
> <https://sourceware.org/ml/libc-alpha/2012-05/msg00682.html> and 
> <https://sourceware.org/ml/libc-alpha/2012-11/msg00367.html>.

that makes sense to me, but doesn't preclude my patch ...

we could create a top level dir like "utils" and everything in there would be 
standalone.  the release scripts would create a small glibc-utils-xxx.tar.bz2 at 
the same time.
-mike
  

On Mon, Jun 01, 2015 at 11:01:58AM -0400, Mike Frysinger wrote:
> that makes sense to me, but doesn't preclude my patch ...

The patch looks OK to me.

Siddhesh
  

* Siddhesh Poyarekar:

> On Mon, Jun 01, 2015 at 11:01:58AM -0400, Mike Frysinger wrote:
>> that makes sense to me, but doesn't preclude my patch ...
>
> The patch looks OK to me.

I'm retesting this patch and plan to install it shortly.

Thanks,
Florian
  

* Florian Weimer:

> * Siddhesh Poyarekar:
>
>> On Mon, Jun 01, 2015 at 11:01:58AM -0400, Mike Frysinger wrote:
>>> that makes sense to me, but doesn't preclude my patch ...
>>
>> The patch looks OK to me.
>
> I'm retesting this patch and plan to install it shortly.

It turns out that this patch is wrong.  I assume that's because of the
incorrect location of -Wl,-rpath-link on the linker command line.  I'm
trying to fix this with additional patches.

Thanks,
Florian