Introducing libtool into our build

[marshallward]

The construction of libFMS.a in ac/deps is currently done by explicitly calling ar. 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 like libtool. I will try to outline what is required if we were to adopt it.

• Add the LT_INIT macro to configure.fms.ac

  This triggers libtoolize, which creates a script called libtool and populates a bunch of required *.m4 macros in the m4 directory. This is much like autoconf, which generates the configure script. As with Autoconf, one could then bundle libtool with the source, so that the user does not require libtoolize.

  Requirements:

  • This needs 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 before AC_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 populate AR, although libtool will replace any invocations of ar. This means that we can drop AR and ARFLAGS.

• Rules created by makedep will need some significant edits

  • Includes 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 and test_* programs, such as test_axis_utils.o. But libtool seems to choke when these are together. They would need to be removed from the libFMS.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 than libfms.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 be libfms.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.