Introducing libtool into our build #340
marshallward
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
The construction of
libFMS.a
inac/deps
is currently done by explicitly callingar
. This is fine for very standard systems, but is very ad hoc and volatile on less conventional platforms. To standardize this, we would need to start using something likelibtool
. I will try to outline what is required if we were to adopt it.Add the
LT_INIT
macro toconfigure.fms.ac
This triggers
libtoolize
, which creates a script calledlibtool
and populates a bunch of required*.m4
macros in them4
directory. This is much likeautoconf
, which generates theconfigure
script. As with Autoconf, one could then bundlelibtool
with the source, so that the user does not requirelibtoolize
.Requirements:
AC_CONFIG_MACRO_DIR([m4])
to be set, so that it knows where to put the new macro files.LT_INIT
can't be placed beforeAC_FC_SRCEXT([F90])
. I don't know why, but it triggers a recursive error. Could be a bug in libtool, or could be that I am not using it properly.LT_INIT
will populateAR
, althoughlibtool
will replace any invocations ofar
. This means that we can dropAR
andARFLAGS
.Rules created by
makedep
will need some significant editsIncludes from
-I
must be moved before the targets (-c $<
). This is because libtool appears to determine the object file name (.o
) from the extension of the source. (Rather surprising that it needs this restriction but OK...)Build rules need to be reworked to invoke libtool; see below.
libFMS.a
currently seems to be comprised of object files from both modules andtest_*
programs, such astest_axis_utils.o
. Butlibtool
seems to choke when these are together. They would need to be removed from thelibFMS.a
rule.Not sure why, nor am I sure how much work this would be to distinguish.
Build rules with
$(FC) $(FCFLAGS) -c $<
, like this:mpifort -g -O2 -c MOM.F90
will need to run through libtool:
libtool --tag=FC --mode=compile $(FC) $(FCFLAGS) -c $<
This will create both object files (
.o
) and a new.lo
file containing libtool metadata. Static object files appear in the current directory, and shared (-fPIC
) files are in a hidden.libs
directory.These
.lo
files could perhaps replace the.o
in the rules.This could be done by simply redefining $(FC) as
libtool --tag=FC --mode=compile $(FC)
, though it's perhaps a bit flaky.--tag
is required to indicate a Fortran build. If removed, it assumes C and chokes.There may be some way to make this implicit with an autoconf macro, but I have yet to find it.
Library creation with
$(AR) $(ARFLAGS)
is dropped and replaced with libtool:libtool --tag=FC --mode=link $(FC) -o libfms.la mod1.lo mod2.lo ...
The target is now
libfms.la
rather thanlibfms.a
. The.lo
files are used in place of.o
. Libtool handles the magic to create both.Without flags, this creates a static library (
libfms.a
). If you build with-rpath /usr/local/lib
, then it will create a dynamic library (libfms.so
), assuming the system supports them.Both libraries appear in the hidden
.libs
. The.la
metadata file is more like a sentinel for the actual libraries(?).Uppercase
libFMS.a
will no longer do, it needs to belibfms.a
. Not entirely sure how this is determined, looking into it.There is more to it, but that is the bulk of it. I have managed to automate most of this, but there are still a few hand-edits that would need to be handled by
makedep
.I will edit this post if it evolves into a requirements list. For now, it's just a rough sketch of how a libtool-based build might look.
Beta Was this translation helpful? Give feedback.
All reactions