You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(3) |
2
(4) |
3
(10) |
|
4
(1) |
5
(2) |
6
(10) |
7
(16) |
8
(7) |
9
(3) |
10
|
|
11
(11) |
12
(16) |
13
(14) |
14
(9) |
15
(13) |
16
(10) |
17
(2) |
|
18
|
19
(14) |
20
(1) |
21
(1) |
22
(11) |
23
(7) |
24
(8) |
|
25
(11) |
26
(10) |
27
(3) |
28
(8) |
29
(24) |
30
(10) |
|
|
From: Josef W. <Jos...@gm...> - 2005-09-19 14:36:06
|
On Monday 19 September 2005 15:47, Stefan Ottosson wrote: > Dr D1mr D2mr > > . . . bb0: > 10 9 9 movl 0(%ebp), %esi > 0 0 0 inc %esi > 0 0 0 and $0xFFFFFF, %esi > 0 0 0 mov %esi, 0(%ebp) > 0 0 0 pushl %eax > ; is the load below skipped? > 0 0 0 movl 0x1E26A0(%ebp), %ecx > 0 0 0 addl $1, %ecx This is assembler source, compiled with as -g ? > How can Dr be zero for the "movl 0x1E26A0(%ebp), %ecx" instruction, if it > did get executed, which it should have? This Looks strange. What is the result if you run it with Cachegrind from VG 2.4.1? > --18056-- warning: Pentium with 12 K micro-op instruction trace cache > --18056-- Simulating a 16 KB cache with 32 B lines > > Why does this message appear, is it a problem, and if so what can I do > about it? Nothing. As Tom notes, I1mr for sure will have another value than a level 1 instruction cache miss counter would get, measured with real HW performance counters. I2mr would probably be more near to reality, as Cachegrind's L2 cache models the hardware of your processor better, but that can not really be measured separately in hardware. But I do not think that exact miss counters on instruction fetches are important: Most of the time, instruction misses play no role at all for bad cache behaviour. And if they are high, this means that your code size is very large for often executed code. The best optimization I know in this case would be to reduce the amount of inlining done by the compiler. And to check any improvements, the relative figures are important and not the absolute. Josef > > Thanks for your help. > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or your very > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@cs...> - 2005-09-19 14:01:43
|
On Mon, 19 Sep 2005, Stefan Ottosson wrote: > However, to me the output looks unreasonable. Some loads appear to be > skipped, even though other loads in the same basic block do get executed. > Maybe I'm just misunderstanding the output? Cachegrind annotation is only as good as the debug info present in the binary. Often it's not very exact, so that could be the problem. > Dr D1mr D2mr > > . . . bb0: > 10 9 9 movl 0(%ebp), %esi > 0 0 0 inc %esi > 0 0 0 and $0xFFFFFF, %esi > 0 0 0 mov %esi, 0(%ebp) > 0 0 0 pushl %eax > ; is the load below skipped? > 0 0 0 movl 0x1E26A0(%ebp), %ecx > 0 0 0 addl $1, %ecx It's interesting that you're annotating the asm. What command line are you assembling with? > Also, I get an error message: > > --18056-- warning: Pentium with 12 K micro-op instruction trace cache > --18056-- Simulating a 16 KB cache with 32 B lines > > Why does this message appear, is it a problem, and if so what can I do > about it? Cachegrind doesn't simulate trace caches accurately. So it just simulates a normal I-cache instead. The overall results will still be indicative of your program's cache behaviour in general, but don't expect it to match the exact results you'd get on the real hardware. Nick |
|
From: Tom H. <to...@co...> - 2005-09-19 13:57:21
|
In message <Pin...@ko...>
Stefan Ottosson <so...@ly...> wrote:
> Also, I get an error message:
>
> --18056-- warning: Pentium with 12 K micro-op instruction trace cache
> --18056-- Simulating a 16 KB cache with 32 B lines
>
> Why does this message appear, is it a problem, and if so what can I do
> about it?
You can't do anything about it, other than not use a Pentium 4 to
run cachegrind - basically cachegrind is not capable of accurately
modelling the instruction cache on your machine because the cache
doesn't cache raw instructions it caches the internal micro-ops that
your CPU decodes instructions to.
So your CPU has a cache capable of hold 12000 micro-ops but cachgrind
is treating it as if it held 16000 bytes of variable length x86
instructions which is not the same thing at all. So the instruction
cache hit/miss values will not be accurate.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Stefan O. <so...@ly...> - 2005-09-19 13:51:52
|
I forgot to specify what my setup looks like in my previous mail. Here it is: P4 with hyper-threading, 3GHz, 1Mb L2 cache Linux kernel: 2.6.11.4-21.8-smp distribution: SuSe. valgrind-3.0.1 gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) |
|
From: Stefan O. <so...@ly...> - 2005-09-19 13:47:27
|
Hi, I need to identify the top cache-missing loads in a program written in assembly language. To this end I compiled and installed the latest version of Cachegrind. However, to me the output looks unreasonable. Some loads appear to be skipped, even though other loads in the same basic block do get executed. Maybe I'm just misunderstanding the output? Dr D1mr D2mr . . . bb0: 10 9 9 movl 0(%ebp), %esi 0 0 0 inc %esi 0 0 0 and $0xFFFFFF, %esi 0 0 0 mov %esi, 0(%ebp) 0 0 0 pushl %eax ; is the load below skipped? 0 0 0 movl 0x1E26A0(%ebp), %ecx 0 0 0 addl $1, %ecx How can Dr be zero for the "movl 0x1E26A0(%ebp), %ecx" instruction, if it did get executed, which it should have? Also, I get an error message: --18056-- warning: Pentium with 12 K micro-op instruction trace cache --18056-- Simulating a 16 KB cache with 32 B lines Why does this message appear, is it a problem, and if so what can I do about it? Thanks for your help. |
|
From: Arndt M. <amu...@is...> - 2005-09-19 13:20:17
|
Hi! Does Helgrind support read-write locks (pthread_rwlock)? I just ask, because I couldn't find it in the source code, but the original eraser-algorithm contains an extension for rw-locks. And, the hardware-bus-lock could be better simulated by a rw-lock. Arndt |
|
From: Brendan H. <har...@ya...> - 2005-09-19 12:57:02
|
Hi I am using Helgrind (part of valgrind 2.2.0) to assist with ensuring that processes are thread safe. I am find ing that for many (although not all) the process crashes shortly after startup with the message 'segmentation fault' (last lines from trace shown below): --7478-- supp: 1 _dl_lookup_symbol_x/fixup/_dl_runtime_resolve ==7478== ==7478== IN SUMMARY: 24 errors from 24 contexts (suppressed: 1 from 1) ==7478== ==7478== 25 possible data races found; 0 lock order problems --7478-- TT/TC: 0 tc sectors discarded. --7478-- 97133 tt_fast misses. --7478-- translate: new 32065 (532860 -> 4505112; ratio 84:10) --7478-- discard 0 (0 -> 0; ratio 0:10). --7478-- chainings: 17647 chainings, 0 unchainings. --7478-- dispatch: 29121137 jumps (bb entries); of them 7666969 (26%) unchained. --7478-- 14665/395268 major/minor sched events. --7478-- reg-alloc: 86 t-req-spill, 793027+202 orig+spill uis, --7478-- 80042 total-reg-rank --7478-- sanity: 14659 cheap, 587 expensive checks. --7478-- ccalls: 168577 C calls, 60% saves+restores avoided (596770 bytes) --7478-- 221736 args, avg 0.61 setup instrs each (169998 bytes) --7478-- 0% clear the stack (505314 bytes) --7478-- 139 retvals, 47% of reg-reg movs avoided (128 bytes) Segmentation fault Looking at the messages I think that the crash has occured reasonable early on during the intialisation. I am using the command below to run process: valgrind -v --tool=helgrind <process name> and am running it on SUSE 9.0 enterprise (linux). Does anybody have an idea what could be causing this or any suggestions on what to try. Thanks __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Steinar B. <sb...@do...> - 2005-09-17 16:14:09
|
>>>>> Josef Weidendorfer <Jos...@gm...>: > This should be a problem in Valgrinds debug reader then. If you run > memcheck, are there any errors so that you can verify that this > problem is in fact Valgrinds? Do I need to run the entire procedure (which took the entire night)? Or is it enough that I just run the program a little with memcheck? |
|
From: Marius M. <mmi...@gm...> - 2005-09-17 02:10:58
|
Dirk Mueller <dmuell <at> gmx.net> writes: > On Friday 16 September 2005 04:43, Bob Rossi wrote: > > > is this a bug in my program, or ld? > > its not in your program, its a race between ld and valgrind. there have been > hacks added to newer releases, you might want to upgrade your valgrind > version. what do you mean by newer *releases*? My Debian box says valgrind-3.0.1, while I can find only 3.0.0 release on valgrind homepage :-/ marius |
|
From: Nicholas N. <nj...@cs...> - 2005-09-16 22:17:51
|
On Fri, 16 Sep 2005, Abebaw Wubshet wrote: > I am quite new to valgrind. Is there any way that I can determine the peak > memory requirement of my program using valgrind, or another tool for that matter ? Not directly with the current tools. mpatrol might be useful for this. Nick |
|
From: Brian C. <cr...@fi...> - 2005-09-16 22:02:37
|
glibc's allocator offers a routine called mallinfo() which returns a struct mallinfo object that you might be able to pull some instructive information out of (whenever you like, and without instrumentation). The structure doesn't seem to have man pages, but the comments in /usr/include/malloc.h are descriptive enough. Good luck, -- Brian Abebaw Wubshet wrote: > Hi all, > > I am quite new to valgrind. Is there any way that I can determine the peak > memory requirement of my program using valgrind, or another tool for that matter ? > > Thanks, > Abebaw > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or your very > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > |
|
From: Abebaw W. <a.w...@tu...> - 2005-09-16 21:03:03
|
Hi all, I am quite new to valgrind. Is there any way that I can determine the peak memory requirement of my program using valgrind, or another tool for that matter ? Thanks, Abebaw |
|
From: Tom H. <to...@co...> - 2005-09-16 17:59:36
|
In message <003401c5bae4$6ad87e50$0300a8c0@hugo>
"cjk" <cj...@co...> wrote:
> I issued './configure' and that seemed to go ok.
> When I issued 'make', however, I get the following error:
>
> /usr/bin/ld: cannot find -lc
>
> Could someone please tell me what I am doing wrong?
> (I have looked through the FAQ page and the manual.)
> Thank you much.
Install the glibc-static-devel package from your distribution.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: cjk <cj...@co...> - 2005-09-16 17:31:22
|
I am a newbie. I have downloaded and am trying to build valgrind (version 3.0.1--the = latest=20 version). I have MandrakeLinux 10.1 (Mandriva), with kernel 2.6.8. I have GNU Make 3.80. I have gcc version 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk) I read a web page (http://www.cprogramming.com/debugging/valgrind.html) = that=20 said: ... after download ... bzip2 -d valgrind-XYZ.tar.bz2 tar -xf valgrind-XYZ.tar ... change to that directory and issue ... ./configure make make install I issued './configure' and that seemed to go ok. When I issued 'make', however, I get the following error: /usr/bin/ld: cannot find -lc Could someone please tell me what I am doing wrong? (I have looked through the FAQ page and the manual.) Thank you much. --=20 |
|
From: Dirk M. <dm...@gm...> - 2005-09-16 15:14:55
|
On Friday 16 September 2005 13:27, Julian Seward wrote: > A race which later got fixed? I'm not sure what you mean. > Can you clarify? index-not-intercepted-early-enough-HACK-* in glibc-2.3.supp |
|
From: Julian S. <js...@ac...> - 2005-09-16 11:17:44
|
> On Friday 16 September 2005 10:45, Dirk Mueller wrote: > > its not in your program, its a race between ld and valgrind. there have > been hacks added to newer releases, you might want to upgrade your valgrind > version. A race which later got fixed? I'm not sure what you mean. Can you clarify? J |
|
From: Dirk M. <dm...@gm...> - 2005-09-16 09:45:49
|
On Friday 16 September 2005 04:43, Bob Rossi wrote: > is this a bug in my program, or ld? its not in your program, its a race between ld and valgrind. there have been hacks added to newer releases, you might want to upgrade your valgrind version. Dirk |
|
From: Nicholas N. <nj...@cs...> - 2005-09-16 03:02:25
|
On Thu, 15 Sep 2005, Bob Rossi wrote: > I updated debian recently and started getting these errors, > > ==8266== Conditional jump or move depends on uninitialised value(s) > ==8266== at 0x1B8ECB13: (within /lib/ld-2.3.5.so) > ==8266== by 0x1B8E631C: (within /lib/ld-2.3.5.so) > ==8266== by 0x1B8F2BDD: (within /lib/ld-2.3.5.so) > ==8266== by 0x1B8E7675: (within /lib/ld-2.3.5.so) > ==8266== by 0x1B8E47C6: (within /lib/ld-2.3.5.so) > > is this a bug in my program, or ld? Probably ld. Nick |
|
From: Bob R. <bo...@br...> - 2005-09-16 02:43:21
|
Hi all, I updated debian recently and started getting these errors, ==8266== Conditional jump or move depends on uninitialised value(s) ==8266== at 0x1B8ECB13: (within /lib/ld-2.3.5.so) ==8266== by 0x1B8E631C: (within /lib/ld-2.3.5.so) ==8266== by 0x1B8F2BDD: (within /lib/ld-2.3.5.so) ==8266== by 0x1B8E7675: (within /lib/ld-2.3.5.so) ==8266== by 0x1B8E47C6: (within /lib/ld-2.3.5.so) is this a bug in my program, or ld? Thanks, Bob Rossi |
|
From: Nicholas N. <nj...@cs...> - 2005-09-15 15:27:42
|
On Thu, 15 Sep 2005, Thomas Lavergne wrote: > What about the --with-db= to point to the debugger software at configure > time? I guess it wouldn't hurt, but it doesn't seem very important since (a) no-one else has mentioned it before and (b) you can control it via the command line. Nick |
|
From: Ashley P. <as...@qu...> - 2005-09-15 14:50:22
|
On Thu, 2005-09-15 at 09:28 -0500, Nicholas Nethercote wrote: > On Thu, 15 Sep 2005, Ashley Pittman wrote: > > >> We have already a mechanism for redirecting all calls to a function to a > >> replacement version (eg. you call malloc and it ends up at __wrap_malloc). > >> The hard part is then being able to call __real_malloc from within > >> __wrap_malloc in a way that bypasses the redirection mechanism. (Without > >> the redirection bypassing, we end up in an infinite call loop.) The > >> problem is that we effectively need to store two different translations > >> (for __wrap_malloc and __real_malloc) for a single code address (malloc). > >> The code cache doesn't have a mechanism for this. > > > > Why does __wrap_malloc() need to translate to malloc(), surely it's a > > case of adding extra code/address pairs rather then breaking the > > one-to-one mapping? > > I don't understand the question, sorry. You said that __wrap_malloc() and __real_malloc() both need to point to a single code address (malloc). As far as I can see only __real_malloc() does, the other one needs to point elsewhere. Or is this translation for going the other way? /somewhat idle musings... Ashley, |
|
From: Thomas L. <tho...@jr...> - 2005-09-15 14:30:19
|
I am no expert but it should do ok with this patch. I won't fill a bug-report. (I cannot find my bugzilla password ;-)) What about the --with-db= to point to the debugger software at configure time? Thomas Nicholas Nethercote wrote: > On Thu, 15 Sep 2005, Tom Hughes wrote: > >>> 1) the VEX library is by default taken to `pwd` (that was objdir/VEX >>> and not srcdir/VEX) so I had to say --with-vex=srcdir/VEX >> >> >> Can you raise a bug for this please and I'll see what I can do. > > > I've improved this situation recently. The below diff for the trunk > makes VPATH builds work again. > > Nick > > > > Index: configure.in > =================================================================== > --- configure.in (revision 4644) > +++ configure.in (working copy) > @@ -20,7 +20,7 @@ > [AC_MSG_ERROR([Directory '$withval' does not exist, or does > not contain Vex])]) > ], > [ > - VEX_DIR=`pwd`/VEX > + VEX_DIR='$(top_srcdir)/VEX' > ]) > AC_SUBST(VEX_DIR) > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or your > very > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Nicholas N. <nj...@cs...> - 2005-09-15 14:28:30
|
On Thu, 15 Sep 2005, Ashley Pittman wrote: >> We have already a mechanism for redirecting all calls to a function to a >> replacement version (eg. you call malloc and it ends up at __wrap_malloc). >> The hard part is then being able to call __real_malloc from within >> __wrap_malloc in a way that bypasses the redirection mechanism. (Without >> the redirection bypassing, we end up in an infinite call loop.) The >> problem is that we effectively need to store two different translations >> (for __wrap_malloc and __real_malloc) for a single code address (malloc). >> The code cache doesn't have a mechanism for this. > > Why does __wrap_malloc() need to translate to malloc(), surely it's a > case of adding extra code/address pairs rather then breaking the > one-to-one mapping? I don't understand the question, sorry. Nick |
|
From: Nicholas N. <nj...@cs...> - 2005-09-15 14:22:29
|
On Thu, 15 Sep 2005, Tom Hughes wrote:
>> 1) the VEX library is by default taken to `pwd` (that was objdir/VEX
>> and not srcdir/VEX) so I had to say --with-vex=srcdir/VEX
>
> Can you raise a bug for this please and I'll see what I can do.
I've improved this situation recently. The below diff for the trunk makes
VPATH builds work again.
Nick
Index: configure.in
===================================================================
--- configure.in (revision 4644)
+++ configure.in (working copy)
@@ -20,7 +20,7 @@
[AC_MSG_ERROR([Directory '$withval' does not exist, or does not
contain Vex])])
],
[
- VEX_DIR=`pwd`/VEX
+ VEX_DIR='$(top_srcdir)/VEX'
])
AC_SUBST(VEX_DIR)
|
|
From: Tom H. <to...@co...> - 2005-09-15 13:12:44
|
In message <432...@jr...>
Thomas Lavergne <tho...@jr...> wrote:
> 1) the VEX library is by default taken to `pwd` (that was objdir/VEX
> and not srcdir/VEX) so I had to say --with-vex=srcdir/VEX
Can you raise a bug for this please and I'll see what I can do.
> 2) I wanted to use --prog-suffix=-3.0.1 (to get an executable
> valgrind-3.0.1), but at linking time (I think) the run-time-libraries
> (.so) where not created in a consistent manner: I think I remember
> make was searching for (e.g. vg_memcheck-3.0.1.so) but vg_memcheck.so
> had been created.
There is already a bug for this but I haven't managed to come up with
a fix yet - the problem is that we use a PROGRAMS target to create and
install shared libraries which causes them to get the suffix added
which is probably wrong.
I haven't come up with any other way to create shared libraries
without using libtool though.
It's a fairly minor issue though, and will become even more so once we
have proper dual architecture support in the amd64 build so I'm not
too worried about it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|