This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

Paolo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]