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

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

[Mike Frysinger]

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(-)

diff --git a/malloc/Makefile b/malloc/Makefile
index 67ed293..48515b8 100644
--- a/malloc/Makefile
+++ b/malloc/Makefile
@@ -75,6 +75,7 @@ ifneq ($(cross-compiling),yes)
 # If the gd library is available we build the `memusagestat' program.
 ifneq ($(LIBGD),no)
 others: $(objpfx)memusage
+others += memusagestat
 install-bin = memusagestat
 install-bin-script += memusage
 generated += memusagestat memusage
@@ -98,8 +99,7 @@ cpp-srcs-left := $(memusagestat-modules)
 lib := memusagestat
 include $(patsubst %,$(..)cppflags-iterator.mk,$(cpp-srcs-left))
 
-$(objpfx)memusagestat: $(memusagestat-modules:%=$(objpfx)%.o)
-	$(LINK.o) -o $@ $^ $(libgd-LDFLAGS) -lgd -lpng -lz -lm
+LDLIBS-memusagestat = $(libgd-LDFLAGS) -lgd -lpng -lz -lm
 
 ifeq ($(run-built-tests),yes)
 ifeq (yes,$(build-shared))
-- 
2.4.1

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

[Andreas Schwab]

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.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Andreas Schwab]

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.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Joseph Myers]

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>.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Siddhesh Poyarekar]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Siddhesh Poyarekar]

[-- Attachment #1: Type: text/plain, Size: 161 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

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

[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.

Thanks,
Florian

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

[Florian Weimer]

* 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