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

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[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  <[hidden email]>

        [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

Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab-2
Mike Frysinger <[hidden email]> 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, [hidden email]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

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

Mike Frysinger
On 30 May 2015 22:20, Andreas Schwab wrote:
> Mike Frysinger <[hidden email]> 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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab-2
Mike Frysinger <[hidden email]> writes:

> On 30 May 2015 22:20, Andreas Schwab wrote:
>> Mike Frysinger <[hidden email]> 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, [hidden email]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

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

Mike Frysinger
On 31 May 2015 11:40, Andreas Schwab wrote:

> Mike Frysinger <[hidden email]> writes:
> > On 30 May 2015 22:20, Andreas Schwab wrote:
> >> Mike Frysinger <[hidden email]> 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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Joseph Myers
In reply to this post by Andreas Schwab-2
On Sun, 31 May 2015, Andreas Schwab wrote:

> Mike Frysinger <[hidden email]> writes:
>
> > On 30 May 2015 22:20, Andreas Schwab wrote:
> >> Mike Frysinger <[hidden email]> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Siddhesh Poyarekar-3
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

attachment0 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Mike Frysinger
In reply to this post by Joseph Myers
On 01 Jun 2015 14:39, Joseph Myers wrote:

> On Sun, 31 May 2015, Andreas Schwab wrote:
> > Mike Frysinger <[hidden email]> writes:
> > > On 30 May 2015 22:20, Andreas Schwab wrote:
> > >> Mike Frysinger <[hidden email]> 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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Siddhesh Poyarekar-3
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

attachment0 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Florian Weimer-5
* 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
Reply | Threaded
Open this post in threaded view
|

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

Florian Weimer-5
* 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