1ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
2ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff BrownGreetings, packaging person!  This information is aimed at people
3ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brownbuilding binary distributions of Valgrind.
4ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
5ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff BrownThanks for taking the time and effort to make a binary distribution of
6ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff BrownValgrind.  The following notes may save you some trouble.
7ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
8ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
9ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown-- Do not ship your Linux distro with a completely stripped
10ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   /lib/ld.so.  At least leave the debugging symbol names on -- line
11ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   number info isn't necessary.  If you don't want to leave symbols on
12ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   ld.so, alternatively you can have your distro install ld.so's
13ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   debuginfo package by default, or make ld.so.debuginfo be a
14ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   requirement of your Valgrind RPM/DEB/whatever.
15ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
16ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   Reason for this is that Valgrind's Memcheck tool needs to intercept
17ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   calls to, and provide replacements for, some symbols in ld.so at
18ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   startup (most importantly strlen).  If it cannot do that, Memcheck
19ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   shows a large number of false positives due to the highly optimised
20ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   strlen (etc) routines in ld.so.  This has caused some trouble in
21ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   the past.  As of version 3.3.0, on some targets (ppc32-linux,
22ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   ppc64-linux), Memcheck will simply stop at startup (and print an
23ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   error message) if such symbols are not present, because it is
24ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   infeasible to continue.
25ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
26ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   It's not like this is going to cost you much space.  We only need
27ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   the symbols for ld.so (a few K at most).  Not the debug info and
28ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   not any debuginfo or extra symbols for any other libraries.
29ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
30ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
31ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown-- (Unfortunate but true) When you configure to build with the 
32ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   --prefix=/foo/bar/xyzzy option, the prefix /foo/bar/xyzzy gets
33ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   baked into valgrind.  The consequence is that you _must_ install
34ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   valgrind at the location specified in the prefix.  If you don't,
35ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   it may appear to work, but will break doing some obscure things,
36ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   particularly doing fork() and exec().
37ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
38ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   So you can't build a relocatable RPM / whatever from Valgrind.
39ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
40ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
41ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown-- Don't strip the debug info off lib/valgrind/$platform/vgpreload*.so
42ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   in the installation tree.  Either Valgrind won't work at all, or it
43ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   will still work if you do, but will generate less helpful error
44ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   messages.  Here's an example:
45ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
46ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   Mismatched free() / delete / delete []
47ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      at 0x40043249: free (vg_clientfuncs.c:171)
48ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      by 0x4102BB4E: QGArray::~QGArray(void) (tools/qgarray.cpp:149)
49ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      by 0x4C261C41: PptDoc::~PptDoc(void) (include/qmemarray.h:60)
50ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      by 0x4C261F0E: PptXml::~PptXml(void) (pptxml.cc:44)
51ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      Address 0x4BB292A8 is 0 bytes inside a block of size 64 alloc'd
52ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      at 0x4004318C: __builtin_vec_new (vg_clientfuncs.c:152)
53ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      by 0x4C21BC15: KLaola::readSBStream(int) const (klaola.cc:314)
54ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      by 0x4C21C155: KLaola::stream(KLaola::OLENode const *) (klaola.cc:416)
55ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      by 0x4C21788F: OLEFilter::convert(QCString const &) (olefilter.cc:272)
56ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
57ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   This tells you that some memory allocated with new[] was freed with
58ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   free().
59ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
60ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   Mismatched free() / delete / delete []
61ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      at 0x40043249: (inside vgpreload_memcheck.so)
62ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      by 0x4102BB4E: QGArray::~QGArray(void) (tools/qgarray.cpp:149)
63ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      by 0x4C261C41: PptDoc::~PptDoc(void) (include/qmemarray.h:60)
64ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      by 0x4C261F0E: PptXml::~PptXml(void) (pptxml.cc:44)
65ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      Address 0x4BB292A8 is 0 bytes inside a block of size 64 alloc'd
66ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      at 0x4004318C: (inside vgpreload_memcheck.so)
67ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      by 0x4C21BC15: KLaola::readSBStream(int) const (klaola.cc:314)
68ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      by 0x4C21C155: KLaola::stream(KLaola::OLENode const *) (klaola.cc:416)
69ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown      by 0x4C21788F: OLEFilter::convert(QCString const &) (olefilter.cc:272)
70ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
71ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   This isn't so helpful.  Although you can tell there is a mismatch, 
72ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   the names of the allocating and deallocating functions are no longer
73ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   visible.  The same kind of thing occurs in various other messages 
74ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   from valgrind.
75ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
76ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
77ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown-- Don't strip symbols from lib/valgrind/* in the installation tree.
78ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   Doing so will likely cause problems.  Removing the line number info is
79ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   probably OK (at least for some of the files in that directory), although
80ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   that has not been tested by the Valgrind developers.
81ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
82ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
83ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown-- Please test the final installation works by running it on something
84ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   huge.  I suggest checking that it can start and exit successfully
85ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   both Firefox and OpenOffice.org.  I use these as test programs, and I
86ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   know they fairly thoroughly exercise Valgrind.  The command lines to use
87ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   are:
88ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
89ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   valgrind -v --trace-children=yes firefox
90ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
91ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown   valgrind -v --trace-children=yes soffice
92ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
93ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brown
94ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff BrownIf you find any more hints/tips for packaging, please report
95ed07e00d438c74b7a23c01bfffde77e3968305e4Jeff Brownit as a bugreport. See http://www.valgrind.org for details.
96