On Sun, Mar 29, 2009 at 01:00:50PM +0200, FX wrote:
> This mail is a request for some help from our local build machinery
> experts... We have a patch under testing for libgfortran to add
> runtime memleaks checking, and it uses libiberty's hash tables. So, we
> now link gfortran programs with libiberty. We also need to link in
> libiberty while building libgfortran (which I discovered because
> otherwise we get failures on darwin), by the following patch:
I don't think it is a good idea to turn libgfortran into a kitchen sink.
memleak checking should be IMHO left to valgrind/mtrace and other memory
allocators that track memory leaks.
You should never link libiberty.a into target libraries, if really needed
just #include the files from include/ and/or libiberty/ in your sources
and rename the symbols, so that common libiberty symbols aren't exported
from libgfortran.
Jakub
