Jakub Jelinek wrote: > 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.
+1. If libgfortran includes a custom allocator of any sort (does it?) instead of using malloc/free, it should use valgrind hooks like those we already have in GCC. > 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. Agreed on this. The patch posted is *not* ok. Paolo
