It would be great if valgrind could ship memcheck.h and friends, and
valgrind.pc, in a new valgrind-dev or valgrind-headers or something on all
architectures; then packages that consume them, like dbus, wouldn't have
to stay in sync with valgrind's architecture list (leading to RC bugs
like #729136 when valgrind drops an architecture).
Looking at those headers, the declarations already seem to expand to
nothing on platforms not supported by valgrind?
Thanks,
S
Control: tags -1 pending Makes sense. I made it so that valgrind Depends on valgrind-dev for now, in order to avoid eventual breakage due to packages expecting the files in the main valgrind package. Cheers
We believe that the bug you reported is fixed in the latest version of
valgrind, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 731228@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Alessandro Ghedini <ghedo@debian.org> (supplier of updated valgrind package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 10 Dec 2013 19:28:22 +0100
Source: valgrind
Binary: valgrind valgrind-dev valgrind-dbg valgrind-mpi
Architecture: source amd64
Version: 1:3.9.0-2
Distribution: unstable
Urgency: medium
Maintainer: Alessandro Ghedini <ghedo@debian.org>
Changed-By: Alessandro Ghedini <ghedo@debian.org>
Description:
valgrind - instrumentation framework for building dynamic analysis tools
valgrind-dbg - instrumentation framework for building dynamic analysis tools (de
valgrind-dev - instrumentation framework for building dynamic analysis tools (de
valgrind-mpi - instrumentation framework for building dynamic analysis tools (MP
Closes: 729040 730844 731228
Changes:
valgrind (1:3.9.0-2) unstable; urgency=medium
.
* Remove valgrind.manpages (manpages are installed anyway)
* Build on mips64 and mips64el (Closes: #729040)
* Add 09_fix-armhf-detect.patch to fix FTBFS on armhf (Closes: #730844)
* Move headers and pkg-config file to valgrind-dev (Closes: #731228)
See Debian.NEWS for more info
* Bump Standards-Version to 3.9.5 (no changes needed)
Checksums-Sha1:
8be46f2817bbe4823fc9896b5cd3fd209c6d3d54 2180 valgrind_3.9.0-2.dsc
07e93470ba2bd4c2eef5e97e77a6d06dffaf7899 29000 valgrind_3.9.0-2.debian.tar.gz
ff98a0b68e876f852bf92a50b444fc97e634e66e 14706422 valgrind_3.9.0-2_amd64.deb
ce1ff1bbdc82458dca50e913a7f7959d404377a1 91898 valgrind-dev_3.9.0-2_amd64.deb
899ed175b8cff2eae412ee11ecb7a75089e7e354 66585092 valgrind-dbg_3.9.0-2_amd64.deb
021973c3ee067c84b9248f8832260657d8b6108d 94906 valgrind-mpi_3.9.0-2_amd64.deb
Checksums-Sha256:
7e06c807f6f8b10b2de1738fa7407461bac3dd4f31e693a1c873fad72e5d79ba 2180 valgrind_3.9.0-2.dsc
ce12ebf6d97aae935b01143880a555e429781d050431f9663f042c7759379ea5 29000 valgrind_3.9.0-2.debian.tar.gz
68ddde88ec1035fb20aed2e2d89e3eaab54e8663b84e4d914426099916f2de5f 14706422 valgrind_3.9.0-2_amd64.deb
4a3f91ef8bbb187dabb7c8e9ffedab29e10bc4c287886797265acb0c16882386 91898 valgrind-dev_3.9.0-2_amd64.deb
3ecd56307d32031bc38c0e3d2cacd20301add3f8d25cf8af05b10ddeb7cf28d1 66585092 valgrind-dbg_3.9.0-2_amd64.deb
ca73571a39cbe0bf361285348b76ff4745759ed312661ecfdd13b3ab95ee886f 94906 valgrind-mpi_3.9.0-2_amd64.deb
Files:
725bc227f11cf367618335d3ce2891bd 2180 devel optional valgrind_3.9.0-2.dsc
d684ba9e2913f2b93caf396083b23141 29000 devel optional valgrind_3.9.0-2.debian.tar.gz
17c0e6c359b4292ec796d71ecd786d13 14706422 devel optional valgrind_3.9.0-2_amd64.deb
48b813fa41250499cf90d1c6f0a630b7 91898 devel optional valgrind-dev_3.9.0-2_amd64.deb
e702755b19332838cb6b8627d1a63727 66585092 debug extra valgrind-dbg_3.9.0-2_amd64.deb
2e2ed7c81cb4cd675d73f9ba6c117792 94906 devel optional valgrind-mpi_3.9.0-2_amd64.deb
iQIcBAEBAgAGBQJSp3ddAAoJEK+lG9bN5XPLnZoP/R+9Bbk5UNsrKV7KKIINV9BJ
AA1D0+xhvD8dN2FXNV7/30FPAkZW+pm/IMe6c3BdpAtD8jdjOg+EiZtSFoA1mkKe
CfY4P9LofT7/VpzxIq2ylWPoAh5/opZicoQCemBmiD4wKzd6hZIlV6RHmDugUvMP
vlzlPGSHCImmb05/yFgiC5TLe22H0eXT4b2JngEmOCvKrDNRCoxN0x/m/1dVodEV
8ZngYYk4wf4+0Dr8OrgaN5VpF3SyILThwH6UGlFccQ3qv10iZT4irNzsVoQS0008
NxuPGGMfKC9Q7k+Kx/lG47GlEjimBxpH8fxGA/mXWYqxCbryZe7KIadNPZ3RKn++
NDyc5q3blnw6lwaK7AGNW6eWeYrVEEiyZLtPo34Vgq+tn6I8u47OJ9nh0TTsyeki
lJFwKY05TtqBh4QE0YvJ9CQumcXe3HzStl9xVRNvIjOqaDeL81sB79snv3ZuGzy3
N8DDDsatWGCZq2kewhcv8s9uYAQ9r5aLZoNV46bsrziwZdAzGWySy8nF6uSjwMT8
t1d+K5RVYYAwdbVEOz3PNtSYc1oQzEuXIVW3Q/WAMH1stet4Ovp8NLQFieIy8p3D
SLh42gnNlciO/+4NJULvVKBU2lxGiu8MikMj5vN17QZlTC/yuJTqumlBD+iEhvdN
I7ZZW6mHT42tdhup/3K1
=vW61
-----END PGP SIGNATURE-----
Control: reopen -1 Control: notfixed -1 valgrind/1:3.9.0-2 I didn't quite think this through enough, and the thing I've implemented don't work as I expected it to, so I just reverted the change for now. While I still think this would be nice, it turned out to be a bit more difficult to implement (basically the pkg-config file is generated at build time, and it can't be created if the configure stage fails). Anyway, I reopened this report now, I'll see if I can fix things in a later upload but I wouldn't keep my breath. Cheers
Thanks for looking at this, anyway.
You could generate a stub .pc file from debian/rules on unsupported
architectures, maybe, and install the header files (or stub versions
where all the macros expand to nothing) manually? The .pc file format
is hardly rocket science.
Regards,
S
Simon McVittie <smcv@debian.org> writes: Well, I think I've figured it out; there are really *two* packages wanting to be split off, an Arch:all package and an Arch:any package. I'm providing two patches for this, one of which should look awfully familiar; I suggest you save the files and use "git am" to apply them, then if you like you can use "git rebase -i" to squash them (but if you do that, please set "Author: Samuel Bronson <naesten@gmail.com>" on the resulting commit.)
This doesn't really solve anything though. AFAICT e.g. dbus requires the pkg-config file to enable the valgrind thing, but valgrind-tools-dev would still be only available on the architectures already supported by valgrind, and if dbus Build-Depends on it, it would still have to maintain the arch list. I could just move the headers to valgrind-dev and be done with it, but that in itself doesn't solve anything either unless all the other packages implement their own checks for the header files (making the pkg-config file pretty much useless). Considering that the last "transition" (having all the valgrind build rdeps not Build-Depends on valgrind on armel) took months to complete, this will likely take a lot more of both time and work for very little gain... I'd rather spend that time on something else. All in all, I don't think these patches are worth the effort. A real solution would really be to have Debian packages stop Build-Depending on valgrind in the first place. There's no point in enabling the valgrind support in "production" builds for the end users. Those facilities are meant to be used by the developers of the software not their users. Well, we could just not install the *.a libraries. It's not like they are of any use, and it would lower the valgrind package size by ~15MB out of 90. So why are you moving the symbols back in the valgrind package (by disabling the stripping)? The whole point of having a seprate non-Depends -dbg package is to let users not have to install the 200MB of valgrind libs debug symbols, if you move them back into valgrind it'd be like having a Depends on valgrind-dbg in the valgrind package itself (thus making the whole exercise useless). Cheers
Alessandro Ghedini <ghedo@debian.org> writes: Yeah, I *did* notice that my changes won't just magically make things better for dbus; it would, in fact, require patching configure.ac there as well. However, what little mention I see of the pkg-config file on valgrind's bug tracker is skeptical about it's usefulness as well; my proposal certainly isn't making things any worse. Also note that, as far as I can tell, the pkg-config file was never actually intended for use with the client request headers in the first place, but only for use with out-of-tree tools. It is, however, hard to tell for sure when both the pkg-config file and out-of-tree tool development are completely undocumented. I'm certainly not trying to do anything that will lead to more such pain; quite the opposite. Actually, for libraries, such facilities can also be important to any developers using those libraries in other software; if, for example, not enabling valgrind client requests at build time will result in valgrind reporting false errors in any program that uses that library, that could get majorly annoying to people developing against the distro version of that library. (It's quite possible, however, that libdbus is not actually one of those libraries.) Hmm, I see what you mean; it does seem to add ~140000 to the "Installed-Size" field. I guess I should've looked more closely at that before sending; that's obviously way too much space to blow trying to combat a problem that I'm not even certain actually exists anymore. (That patch was basically an afterthought anyway.)
I would not oppose changing dbus' configure.ac to use AC_CHECK_HEADER,
and changing dbus to include <valgrind/valgrind.h>, if that's what it
takes. I am an upstream D-Bus maintainer, so as long as I can coerce one
of my upstream co-maintainers into reviewing my change, patching
configure.ac is not a problem.
I slightly prefer pkg-config because that provides a standard way to set
non-standard paths, even if you don't even have pkg-config (FOO_CFLAGS
and FOO_LIBS will override the configure check for FOO), but if valgrind
upstream intend valgrind.pc to be for external tools and don't want to
provide a valgrind-client-requests.pc, that's fair enough.
memory-pool mechanism to recycle small memory allocations (mainly
linked-list links), so valgrind will report significant memory leaks
unless libdbus uses client requests to teach valgrind about what it's doing.
In the Debian package, the instrumentation is only present in the "debug
build" (install dbus-1-dbg and add
/usr/lib/x86_64-linux-gnu/dbus-1.0/debug-build/lib to the
LD_LIBRARY_PATH), not in the build that is normally used by the OS.
S
Ok, so, I just checked how all the reverse build deps actually use valgrind:
* abiword: checks for valgrind/memcheck.h, but runs valgrind at build.
* alleyoop: requires valgrind at build.
* dbus: uses pkg-config.
* diod: runs valgrind at build.
* gsasl: runs valgrind at build.
* gss: runs valgrind at build.
* jq: runs valgrind at build.
* libdrm: uses pkg-config.
* libtest-valgrind-perl: runs valgrind at build.
* mpich: checks for valgrind/{memcheck,valgrind}.h.
* pypy: checks for valgrind/valgrind.h.
* qpid-cpp: runs valgrind at build.
* re2: checks for valgrind/valgrind.h.
* rhmessaging: runs valgrind at build.
* shishi: runs valgrind at build.
* simgrid: checks for valgrind/valgrind.h, probably runs valgrind at build as
well.
* starpu: checks for valgrind/valgrind.h.
* swi-prolog: checks for valgrind/valgrind.h.
* valkyrie: doesn't seem to require valgrind at build at all (???).
* xserver-xorg-video-intel: uses pkg-config.
(note that there may be errors).
Most of them run valgrind during build (mostly for testing AFAICT) and there's
nothing we can do about them (those are the packages that should probably stop
build-depending on valgrind).
Of the others, the ones that use pkg-config are dbus, xserver-xorg-video-intel
and libdrm, so we are in a pretty good position I think. They need to be fixed
before we do the switch though. All the others could simply switch to
valgrind-dev without further changes.
Cheers
Simon McVittie <smcv@debian.org> writes: Huh, why isn't the valgrind stuff in both variants? Are those four bit-rotates on every allocation/deallocation really that big a deal? (Also, I don't see any documentation about the existance of the debug build. It might be good to mention it in README.Debian or something.)