[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.
- Re: [lmi] Testing build with native MinGW 4.9.1, (continued)
- Re: [lmi] Testing build with native MinGW 4.9.1, Greg Chicares, 2016/01/20
- Re: [lmi] Testing build with native MinGW 4.9.1, Vadim Zeitlin, 2016/01/20
- Re: [lmi] Testing build with native MinGW 4.9.1, Greg Chicares, 2016/01/20
- Re: [lmi] Testing build with native MinGW 4.9.1, Vadim Zeitlin, 2016/01/21
- Re: [lmi] Testing build with native MinGW 4.9.1, Greg Chicares, 2016/01/22
- Re: [lmi] Testing build with native MinGW 4.9.1, Vadim Zeitlin, 2016/01/22
- Re: [lmi] Testing build with native MinGW 4.9.1, Greg Chicares, 2016/01/22
- Re: [lmi] Testing build with native MinGW 4.9.1, Greg Chicares, 2016/01/28
- Re: [lmi] Testing build with native MinGW 4.9.1, Vadim Zeitlin, 2016/01/28
- Re: [lmi] Testing build with native MinGW 4.9.1, Greg Chicares, 2016/01/28
[lmi] Goodbye to some old tools [Was: Testing build with native MinGW 4.9.1],
Greg Chicares <=