|
From: Julian S. <js...@ac...> - 2005-11-20 22:03:32
|
Release candidates for Valgrind 3.1.0, and a matching version of Callgrind, 0.10.1, are available at: http://www.valgrind.org/downloads/valgrind-3.1.0RC1.tar.bz2 http://www.valgrind.org/downloads/callgrind-0.10.1RC.tar.gz A matching version of the Valkyrie GUI and associated XML tools will be available for 3.1.0 final. This release works on {x86,amd64,ppc32}-linux. The main changes are greatly improved AMD64 support, better memory management, and fully integrated support for 32-bit PowerPC. There are many refinements and bug fixes. See NEWS in the sources for more details. Please download and test it. We would be especially pleased to hear from people with less-mainstream setups, especially if: - you run Linux on PowerPC - you have an older x86 distro. 3.1.0 should work on a vanilla RedHat 7.3 setup. However, our ability to test on old LinuxThreads setups is gradually declining. - your application uses large amounts of memory. 3.1.0 can utilise all available address space on 32-bit targets, and up to 32GByte on amd64. - you use exotic/obscure/non-mainstream functionality of Valgrind. To build, first build Valgrind in the normal way: cd valgrind-3.1.0RC1 ./configure --prefix=... make make install Then you can untar and build callgrind: cd callgrind-0.10.1RC ./configure --prefix=... (same prefix as above) make install $PREFIX/valgrind --tool=callgrind ls Known issues, which will be fixed in 3.1.0 final: - Due to a bug in the build system, you must do 'make' and then 'make install' to get a V install tree against which callgrind is buildable. ('make install' by itself works fine for building V). - The tarball contains two Altivec test programs (for ppc32). Due to a packaging oversight these are not run at 'make regtest' time. J |
|
From: Dirk M. <dm...@gm...> - 2005-11-21 10:38:03
Attachments:
fix-build.diff
|
On Sunday 20 November 2005 22:55, Julian Seward wrote: > Please download and test it. callgrind doesn't install properly because of ultra ugly install hacks that forget to create the target dir. attached patch removes that code. I'm still not too happy about callgrind, now it installs a callgrind.html into /usr/share/doc/valgrind - either it should be part of valgrind, then it is allowed to install there, or it should install its documentation into /usr/share/doc/callgrind. the current mixture doesn't make distributors happy. Dirk |
|
From: Josef W. <Jos...@gm...> - 2005-11-21 16:04:45
|
On Monday 21 November 2005 11:37, Dirk Mueller wrote: > callgrind doesn't install properly because of ultra ugly install hacks that > forget to create the target dir. attached patch removes that code. Ah, thanks. That is a lot better. > I'm still not too happy about callgrind, now it installs a callgrind.html > into /usr/share/doc/valgrind - either it should be part of valgrind, then it > is allowed to install there, or it should install its documentation > into /usr/share/doc/callgrind. the current mixture doesn't make distributors > happy. Hmm... Callgrind is an external plugin for Valgrind, so the binary (previously the shared lib) of course has to be installed into Valgrinds path. Why should this be different for the documentation (e.g. the include file installs into the same path). The documentation was always installed into this path with Callgrind 0.9.x. So what is the exact problem? Josef > > > > Dirk > |
|
From: Josef W. <Jos...@gm...> - 2005-11-21 16:39:49
|
On Monday 21 November 2005 16:59, Josef Weidendorfer wrote: > On Monday 21 November 2005 11:37, Dirk Mueller wrote: > > callgrind doesn't install properly because of ultra ugly install hacks that > > forget to create the target dir. attached patch removes that code. > > Ah, thanks. That is a lot better. > > > I'm still not too happy about callgrind, now it installs a callgrind.html > > into /usr/share/doc/valgrind - either it should be part of valgrind, then it > > is allowed to install there, or it should install its documentation > > into /usr/share/doc/callgrind. the current mixture doesn't make distributors > > happy. > > Hmm... Callgrind is an external plugin for Valgrind, so the binary (previously the > shared lib) of course has to be installed into Valgrinds path. Why should this be > different for the documentation (e.g. the include file installs into the same path). > The documentation was always installed into this path with Callgrind 0.9.x. > > So what is the exact problem? To separate VG and external tools: What about a TOOL_PATH variable, similar to PATH, which is searched for a matching tool by the VG launcher? Callgrind's configure would distinguish between --prefix and --vgprefix, i.e. you can do ./configure --vgprefix=/usr --prefix=$HOME How does this sound? Josef |
|
From: Dirk M. <dm...@gm...> - 2005-11-21 23:33:02
Attachments:
use-pkgconfig.diff
|
On Monday 21 November 2005 16:59, Josef Weidendorfer wrote:
> So what is the exact problem?
well, by default packages should install their documentation into
%_docdir/%{name}, this rule is violated here.
Anyway, I generally agree that there is tight coupling between callgrind and
valgrind. callgrind packages should probably be named "valgrind-callgrind"
instead.
BTW, callgrind still fails configure on x86_64 on bi-arch systems. Thats
because the .pc files are in /usr/lib64 then, which doesn't work with the
hardcoded paths in configure.
I don't see why one shouldn't use pkgconfig here, so I've made a patch that
converts configure to use pkgconfig. See below. (Its been around for a long
time, I'm quite surprised nobody has noticed this before).
Dirk
|
|
From: Josef W. <Jos...@gm...> - 2005-11-22 13:36:50
|
On Tuesday 22 November 2005 00:32, Dirk Mueller wrote:
> On Monday 21 November 2005 16:59, Josef Weidendorfer wrote:
>
> > So what is the exact problem?
>
> well, by default packages should install their documentation into
> %_docdir/%{name}, this rule is violated here.
The reasoning for putting the callgrind docu nearside valgrinds documentation
was the hope that some "magic" would allow to link clg's docu inside of vg's docu.
But valgrinds launcher at least should list available tools.
This worked in VG 3.0. Is the a way to revive this with VG 3.1 ?
Oh well, I can also install the docu into %_docdir/%{name}.
I am neither a autoconf/make nor RPM-specfile guru. What should
be the docdir definition in docs/Makefile.am ?
> Anyway, I generally agree that there is tight coupling between callgrind and
> valgrind. callgrind packages should probably be named "valgrind-callgrind"
> instead.
But I can not do anything about this. Package naming is distro specific.
> BTW, callgrind still fails configure on x86_64 on bi-arch systems. Thats
> because the .pc files are in /usr/lib64 then, which doesn't work with the
> hardcoded paths in configure.
Where are hardcoded paths in configure?
VG's installation currently does not let me detect for a biarch installation.
If you have an idea how to make this work, I would appreciate it.
Can you provide a patch? I suppose this first needs VG to install 2 .pc files.
> I don't see why one shouldn't use pkgconfig here, so I've made a patch that
> converts configure to use pkgconfig. See below. (Its been around for a long
> time, I'm quite surprised nobody has noticed this before).
I did this "pkg-extract" for callgrind 0.9.x, as it could be installed on
very old systems (e.g. with VG 2.0.x), and I was not sure if pkgconfig is
available here, especially as VG itself does not need pkgconfig. But that
reasoning seems to be moot for VG 3.
Probably I should check for pkgconfig in configure before using it?
Josef
>
>
> Dirk
>
|
|
From: Nicholas N. <nj...@cs...> - 2005-11-21 17:11:20
|
On Sun, 20 Nov 2005, Julian Seward wrote: > Release candidates for Valgrind 3.1.0, and a matching version of > Callgrind, 0.10.1, are available at: > > http://www.valgrind.org/downloads/valgrind-3.1.0RC1.tar.bz2 > http://www.valgrind.org/downloads/callgrind-0.10.1RC.tar.gz Valgrind works as expected on the oldish x86/Debian-3.0-something and newer x86/Ubuntu-something boxes I have access to. I didn't test Callgrind, sorry. Nick |
|
From: Dave N. <dc...@us...> - 2005-11-21 21:11:24
|
On Sun, 2005-11-20 at 21:55 +0000, Julian Seward wrote: > Release candidates for Valgrind 3.1.0, and a matching version of > Callgrind, 0.10.1, are available at: > > http://www.valgrind.org/downloads/valgrind-3.1.0RC1.tar.bz2 > http://www.valgrind.org/downloads/callgrind-0.10.1RC.tar.gz > ... > Please download and test it. I downloaded and ran the regtest on a PPC 970 and got about 30 failures many of which have differences listed below. This is similar behavior to what I was seeing early last week but those problems were fixed in an SVN refresh on Nov 17. In that build I was seeing only about 19 failures and differed with the nightly build reports on only 5-6 tests. Did I pick up updates that didn't make it into the tarball? I saw some postings of bug fixes to trunk/glibc-2.3.supp (versions: 5182 & 5194) that referenced expand_dynamic_string_token. I thought they might have been related. ================ from *.diff files ======================== + Conditional jump or move depends on uninitialised value(s) + at 0x........: index (strchr.S:86) + by 0x........: expand_dynamic_string_token (dl-load.c:322) + by 0x........: map_doit (rtld.c:587) + by 0x........: _dl_catch_error (dl-error.c:161) + by 0x........: dl_main (rtld.c:676) + by 0x........: _dl_sysdep_start (dl-sysdep.c:237) + by 0x........: _dl_start_final (rtld.c:307) + by 0x........: _dl_start (rtld.c:532) + by 0x........: _start (dl-start.S:39) + + Conditional jump or move depends on uninitialised value(s) + at 0x........: index (strchr.S:95) + by 0x........: expand_dynamic_string_token (dl-load.c:322) + by 0x........: map_doit (rtld.c:587) + by 0x........: _dl_catch_error (dl-error.c:161) + by 0x........: dl_main (rtld.c:676) + by 0x........: _dl_sysdep_start (dl-sysdep.c:237) + by 0x........: _dl_start_final (rtld.c:307) + by 0x........: _dl_start (rtld.c:532) + by 0x........: _start (dl-start.S:39) |