Message ID | 1433013240-3040-1-git-send-email-vapier@gentoo.org (mailing list archive) |
---|---|
State | Changes Requested, archived |
Delegated to: | Mike Frysinger |
Headers |
Received: (qmail 68467 invoked by alias); 30 May 2015 19:14:07 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 68454 invoked by uid 89); 30 May 2015 19:14:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL, BAYES_00, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org From: Mike Frysinger <vapier@gentoo.org> To: libc-alpha@sourceware.org Subject: [PATCH] memusagestat: use local glibc when linking [BZ #18465] Date: Sat, 30 May 2015 15:14:00 -0400 Message-Id: <1433013240-3040-1-git-send-email-vapier@gentoo.org> |
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
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
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))