On AIX, the results of using --with-aix-soname=svr4 and LT_INIT([aix-soname=svr4]) should be the same, but they are not.  One project where this is evident is OpenAFS.  If the --with-aix-soname=svr4 argument is used with ./configure, the resultant build is correct, whereas if the svr4 option is set as the default when generating the configure script by calling LT_INIT with the aix-soname=svr4 argument, the resultant libtool configuration does not build the static/shared libraries correctly.

Not being very familiar with the libtool codebase, I posted this to the mailing list, and Nick Bolwer was kind enough to do some investigation.  His analysis is below:

> In particular, I noticed that if you add libtool to a project by
> calling LT_INIT, and then run ./configure with the
> --with-aix-soname=svr4, the .la files that get produced with the
> library_names='whatever.so.3 whatever.so', but if you call
> LT_INIT([aix-soname=svr4]) and then don't specify --with-aix-soname to
> ./configure, the .la files have library_names='whatever.a whatever.a"
>
> It seems to me that --with-aix-soname=svr4 and
> LT_INIT([aix-soname=svr4]) should be identical, correct?  Is this a
> libtool bug, or is this a bug in the particular project leveraging
> libtool?  (OpenAFS, in this case).

Yes this looks like a libtool bug to me.

I notice that when aix-soname=svr4 is NOT passed to LT_INIT, if you look
in the generated configure script, you can find the following code in
the following order

  ### FIRST PART
  if test "${enable_shared+set} = set; then
  [...]
  else
    enable_shared=yes
  fi

  [...]

  ### SECOND PART
  case $host,$enable_shared in
  power*-*-aix[5-9]*,yes)
  *)
  esac
 
And in this case, when you run configure --with-aix-soname=svr4, you can
see the output line:

  checking which variant of shared library versioning to provide... svr4

But when I use LT_INIT([aix-soname=svr4]), for some reason the order of
these two parts in the configure script are reversed.  As a result, the
default value of enable_shared is not set before it is used, and the
output about shared library versioning is conspicuously missing.  This
probably causes the other strange behaviour as some variables are not
being set properly.

If you explicitly run ./configure --enable-shared it goes back to normal
(with svr4 versioning as expected), as this has the effect of setting
enable_shared=yes early.


Hopefully that provides enough information to track down the issue.  Please let me know if I can provide additional details.