File: dist.readme-packagers.html

package info (click to toggle)
valgrind 1%3A3.24.0-3
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 176,332 kB
  • sloc: ansic: 795,029; exp: 26,134; xml: 23,472; asm: 14,393; cpp: 9,397; makefile: 7,464; sh: 6,122; perl: 5,446; python: 1,498; javascript: 981; awk: 166; csh: 1
file content (152 lines) | stat: -rw-r--r-- 9,056 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>7. README_PACKAGERS</title>
<link rel="stylesheet" type="text/css" href="vg_basic.css">
<meta name="generator" content="DocBook XSL Stylesheets Vsnapshot">
<link rel="home" href="index.html" title="Valgrind Documentation">
<link rel="up" href="dist.html" title="Valgrind Distribution Documents">
<link rel="prev" href="dist.readme-developers.html" title="6. README_DEVELOPERS">
<link rel="next" href="dist.readme-s390.html" title="8. README.S390">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div><table class="nav" width="100%" cellspacing="3" cellpadding="3" border="0" summary="Navigation header"><tr>
<td width="22px" align="center" valign="middle"><a accesskey="p" href="dist.readme-developers.html"><img src="images/prev.png" width="18" height="21" border="0" alt="Prev"></a></td>
<td width="25px" align="center" valign="middle"><a accesskey="u" href="dist.html"><img src="images/up.png" width="21" height="18" border="0" alt="Up"></a></td>
<td width="31px" align="center" valign="middle"><a accesskey="h" href="index.html"><img src="images/home.png" width="27" height="20" border="0" alt="Up"></a></td>
<th align="center" valign="middle">Valgrind Distribution Documents</th>
<td width="22px" align="center" valign="middle"><a accesskey="n" href="dist.readme-s390.html"><img src="images/next.png" width="18" height="21" border="0" alt="Next"></a></td>
</tr></table></div>
<div class="chapter">
<div class="titlepage"><div><div><h1 class="title">
<a name="dist.readme-packagers"></a>7. README_PACKAGERS</h1></div></div></div>
<div class="literallayout"><p><br>
      <br>
Greetings, packaging person!  This information is aimed at people<br>
building binary distributions of Valgrind.<br>
<br>
Thanks for taking the time and effort to make a binary distribution of<br>
Valgrind.  The following notes may save you some trouble.<br>
<br>
-- If your toolchain (compiler, linker) support lto, using the configure<br>
   option --enable-lto=yes will produce a smaller/faster valgrind<br>
   (up to 10%).<br>
<br>
-- Do not ship your Linux distro with a completely stripped<br>
   /lib/ld.so.  At least leave the debugging symbol names on -- line<br>
   number info isn't necessary.  If you don't want to leave symbols on<br>
   ld.so, alternatively you can have your distro install ld.so's<br>
   debuginfo package by default, or make ld.so.debuginfo be a<br>
   requirement of your Valgrind RPM/DEB/whatever.<br>
<br>
   Reason for this is that Valgrind's Memcheck tool needs to intercept<br>
   calls to, and provide replacements for, some symbols in ld.so at<br>
   startup (most importantly strlen).  If it cannot do that, Memcheck<br>
   shows a large number of false positives due to the highly optimised<br>
   strlen (etc) routines in ld.so.  This has caused some trouble in<br>
   the past.  As of version 3.3.0, on some targets (ppc32-linux,<br>
   ppc64-linux), Memcheck will simply stop at startup (and print an<br>
   error message) if such symbols are not present, because it is<br>
   infeasible to continue.<br>
<br>
   It's not like this is going to cost you much space.  We only need<br>
   the symbols for ld.so (a few K at most).  Not the debug info and<br>
   not any debuginfo or extra symbols for any other libraries.<br>
<br>
<br>
-- (Unfortunate but true) When you configure to build with the<br>
   --prefix=/foo/bar/xyzzy option, the prefix /foo/bar/xyzzy gets<br>
   baked into valgrind.  The consequence is that you _must_ install<br>
   valgrind at the location specified in the prefix.  If you don't,<br>
   it may appear to work, but will break doing some obscure things,<br>
   particularly doing fork() and exec().<br>
<br>
   So you can't build a relocatable RPM / whatever from Valgrind.<br>
<br>
<br>
-- Don't strip the debug info off lib/valgrind/$platform/vgpreload*.so<br>
   in the installation tree.  Either Valgrind won't work at all, or it<br>
   will still work if you do, but will generate less helpful error<br>
   messages.  Here's an example:<br>
<br>
   Mismatched free() / delete / delete []<br>
      at 0x40043249: free (vg_clientfuncs.c:171)<br>
      by 0x4102BB4E: QGArray::~QGArray(void) (tools/qgarray.cpp:149)<br>
      by 0x4C261C41: PptDoc::~PptDoc(void) (include/qmemarray.h:60)<br>
      by 0x4C261F0E: PptXml::~PptXml(void) (pptxml.cc:44)<br>
      Address 0x4BB292A8 is 0 bytes inside a block of size 64 alloc'd<br>
      at 0x4004318C: __builtin_vec_new (vg_clientfuncs.c:152)<br>
      by 0x4C21BC15: KLaola::readSBStream(int) const (klaola.cc:314)<br>
      by 0x4C21C155: KLaola::stream(KLaola::OLENode const *) (klaola.cc:416)<br>
      by 0x4C21788F: OLEFilter::convert(QCString const &amp;) (olefilter.cc:272)<br>
<br>
   This tells you that some memory allocated with new[] was freed with<br>
   free().<br>
<br>
   Mismatched free() / delete / delete []<br>
      at 0x40043249: (inside vgpreload_memcheck.so)<br>
      by 0x4102BB4E: QGArray::~QGArray(void) (tools/qgarray.cpp:149)<br>
      by 0x4C261C41: PptDoc::~PptDoc(void) (include/qmemarray.h:60)<br>
      by 0x4C261F0E: PptXml::~PptXml(void) (pptxml.cc:44)<br>
      Address 0x4BB292A8 is 0 bytes inside a block of size 64 alloc'd<br>
      at 0x4004318C: (inside vgpreload_memcheck.so)<br>
      by 0x4C21BC15: KLaola::readSBStream(int) const (klaola.cc:314)<br>
      by 0x4C21C155: KLaola::stream(KLaola::OLENode const *) (klaola.cc:416)<br>
      by 0x4C21788F: OLEFilter::convert(QCString const &amp;) (olefilter.cc:272)<br>
<br>
   This isn't so helpful.  Although you can tell there is a mismatch, <br>
   the names of the allocating and deallocating functions are no longer<br>
   visible.  The same kind of thing occurs in various other messages <br>
   from valgrind.<br>
<br>
<br>
-- Don't strip symbols from libexec/valgrind/* in the installation tree.<br>
   Doing so will likely cause problems.  Removing the line number info is<br>
   probably OK (at least for some of the files in that directory), although<br>
   that has not been tested by the Valgrind developers.<br>
<br>
   One consequence of stripping these binaries is that if Valgrind crashes<br>
   it won't be able to print out a useful callstack. Here is an example<br>
   posted on Stack Overflow<br>
<br>
      valgrind: the 'impossible' happened: Killed by fatal signal<br>
<br>
      host stacktrace:<br>
      ==7732== at 0x38091C12: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)<br>
      ==7732== by 0x38050E84: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)<br>
      ==7732== by 0x380510A9: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)<br>
      ==7732== by 0x380D4F7B: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)<br>
      ==7732== by 0x380E3946: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)<br>
<br>
  Bug reports like this are less likely to be resolved.<br>
<br>
-- Please test the final installation works by running it on something<br>
   huge.  I suggest checking that it can start and exit successfully<br>
   both Firefox and OpenOffice.org.  I use these as test programs, and I<br>
   know they fairly thoroughly exercise Valgrind.  The command lines to use<br>
   are:<br>
<br>
   valgrind -v --trace-children=yes firefox<br>
<br>
   valgrind -v --trace-children=yes soffice<br>
<br>
<br>
If you find any more hints/tips for packaging, please report<br>
it as a bugreport. See http://www.valgrind.org for details.<br>
<br>
    </p></div>
</div>
<div>
<br><table class="nav" width="100%" cellspacing="3" cellpadding="2" border="0" summary="Navigation footer">
<tr>
<td rowspan="2" width="40%" align="left">
<a accesskey="p" href="dist.readme-developers.html">&lt;&lt; 6. README_DEVELOPERS</a> </td>
<td width="20%" align="center"><a accesskey="u" href="dist.html">Up</a></td>
<td rowspan="2" width="40%" align="right"> <a accesskey="n" href="dist.readme-s390.html">8. README.S390 &gt;&gt;</a>
</td>
</tr>
<tr><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td></tr>
</table>
</div>
</body>
</html>