lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Goodbye to some old tools [Was: Testing build with native MinGW 4.


From: Greg Chicares
Subject: [lmi] Goodbye to some old tools [Was: Testing build with native MinGW 4.9.1]
Date: Thu, 28 Jan 2016 03:07:39 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

On 2016-01-20 17:28, Vadim Zeitlin wrote:
[...]
> 1. Building mpatrol failed with the following error:
> 
> gcc -I../../src -I../../tools -O2 -c -osymbol.o ../../src/symbol.c
> ../../src/symbol.c:77:17: fatal error: bfd.h: No such file or directory
>  #include <bfd.h>

Even if we had the header...
  /usr/bin/i686-w64-mingw32-ld: cannot find -lbfd
  /usr/bin/i686-w64-mingw32-ld: cannot find -liberty
...MinGW-w64 doesn't provide the libraries.

It was a good malloc debugger, and the manual was excellent; but its last
release was in 2008, and its mailing list is pretty much dead: zero posts
in 2014, six in 2015 (five from the same person). I'll remove mpatrol
support from lmi.

I'll also remove support for two non-free compilers that were pretty
famous in their day, but are no longer being maintained.

> I didn't spend much time on this because IMO mpatrol shouldn't be used at
> all nowadays, it's quite obsolete by now and it's probably better to use a
> dynamic instrumentation tool such as DrMemory (http://drmemory.org/)
> instead.

I tried looking at it, but got a "unicorn". You use github, so I guess you
know what that is. Searching elsewhere:

https://www.chromium.org/developers/how-tos/using-drmemory
| DrMemory supports Linux, but the support is not as robust.

https://blog.mozilla.org/jseward/2015/10/05/dr-memory-a-memory-checking-tool-for-windows/
| a promising tool, but just a bit too hard to use

I would suppose that the GNU/Linux tools are more mature:

> Better yet, build lmi under Linux with address (and/or undefined
> behaviour_ sanitizer, which is much faster than DrMemory or Valgrind but
> still finds most problems. So for now I've just skipped this step.

Sounds like a good idea. I guess we should also try building with clang.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]