This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Linking libgfortran with libiberty
- From: FX <fxcoudert at gmail dot com>
- To: fortran at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Sun, 29 Mar 2009 13:00:50 +0200
- Subject: Linking libgfortran with libiberty
Hi all,
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:
Index: Makefile.am
===================================================================
--- Makefile.am (revision 145225)
+++ Makefile.am (working copy)
@@ -17,7 +17,7 @@
toolexeclib_LTLIBRARIES = libgfortran.la
libgfortran_la_LINK = $(LINK)
-libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/
libtool-version` $(LTLDFLAGS) -lm $(extra_ldflags_libgfortran) $
(version_arg)
+libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/
libtool-version` $(LTLDFLAGS) -L../libiberty -liberty -lm $
(extra_ldflags_libgfortran) $(version_arg)
myexeclib_LTLIBRARIES = libgfortranbegin.la
myexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$
(MULTISUBDIR)
i.e. we add "-L../libiberty -liberty" to libgfortran_la_LDFLAGS. My
question is the following: is "-L../libiberty" the right way to tell
the build machinery where to find the target libiberty, or is there
something more clever to do? I see that libjava uses a variable named $
(here), but I couldn't get it working in libgfortran/Makefile.am, so I
reverted to the simpler "../libiberty".
Thanks for your help,
FX
PS: the current draft of the complete patch, if you are interested in
it, is attached (it was put together by Tobias Burnus)
Attachment:
memleak2.diff
Description: Binary data
PPS, to Dominique: this is the promised fix for Darwin :)