This is the mail archive of the
mailing list for the GCC project.
Re: Linking libgfortran with libiberty
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.