diff mbox

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

Message ID 1433013240-3040-1-git-send-email-vapier@gentoo.org
State Changes Requested
Delegated to: Mike Frysinger
Headers show

Commit Message

Mike Frysinger May 30, 2015, 7:14 p.m. UTC
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(-)

Comments

Andreas Schwab May 30, 2015, 8:20 p.m. UTC | #1
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.
Mike Frysinger May 31, 2015, 4:56 a.m. UTC | #2
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
Andreas Schwab May 31, 2015, 9:40 a.m. UTC | #3
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.
Mike Frysinger May 31, 2015, 1:50 p.m. UTC | #4
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
Joseph Myers June 1, 2015, 2:39 p.m. UTC | #5
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>.
Siddhesh Poyarekar June 1, 2015, 2:57 p.m. UTC | #6
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
Mike Frysinger June 1, 2015, 3:01 p.m. UTC | #7
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
Siddhesh Poyarekar June 1, 2015, 3:24 p.m. UTC | #8
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
Florian Weimer April 24, 2019, 11:29 a.m. UTC | #9
* 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 April 25, 2019, 8:52 a.m. UTC | #10
* 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
diff mbox

Patch

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