This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Linking libgfortran with libiberty
- From: Jakub Jelinek <jakub at redhat dot com>
- To: FX <fxcoudert at gmail dot com>
- Cc: fortran at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Mon, 30 Mar 2009 00:32:07 +0200
- Subject: Re: Linking libgfortran with libiberty
- References: <6BA6A458-3B25-4186-ADD6-C2956BBF13A9@gmail.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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