   • You currently need GNU make to build the Libtool package itself.

   • On AIX there are two different styles of shared linking, one where
     symbols are bound at link-time and one where symbols are bound at
     runtime only, similar to ELF.  In case of doubt use
     ‘LDFLAGS=-Wl,-brtl’ for the latter style.

   • On AIX, native tools are to be preferred over binutils; especially
     for C++ code, if using the AIX Toolbox GCC 4.0 and binutils,
     configure with ‘AR=/usr/bin/ar LD=/usr/bin/ld NM='/usr/bin/nm -B'’.

   • On AIX, the ‘/bin/sh’ is very slow due to its inefficient handling
     of here-documents.  A modern shell is preferable:
          CONFIG_SHELL=/bin/bash; export $CONFIG_SHELL
          $CONFIG_SHELL ./configure [...]

   • For C++ code with templates, it may be necessary to specify the way
     the compiler will generate the instantiations.  For Portland pgCC
     version5, use ‘CXX='pgCC --one_instantiation_per_object'’ and avoid
     parallel ‘make’.

   • For C++ code, it may be necessary to specify a library if it is a
     dependency of a link/compile flag.  For example in GNU G++, if you
     want to use ‘-fsanitize=address’ you need to specify the ‘-lasan’
     library, like so: ‘g++ -o libx.la -fsanitize=address -lasan -rpath
     [...]’.

   • On Darwin, for C++ code with templates you need two level shared
     libraries.  Libtool builds these by default if
     ‘MACOSX_DEPLOYMENT_TARGET’ is set to 10.3 or later at ‘configure’
     time.  See <rdar://problem/4135857> for more information on this
     issue.

   • The default shell on UNICOS 9, a ksh 88e variant, is too buggy to
     correctly execute the libtool script.  Users are advised to install
     a modern shell such as GNU bash.

   • Some HP-UX ‘sed’ programs are horribly broken, and cannot handle
     libtool's requirements, so users may report unusual problems.
     There is no workaround except to install a working ‘sed’ (such as
     GNU sed) on these systems.

   • The vendor-distributed NCR MP-RAS ‘cc’ programs emits copyright on
     standard error that confuse tests on size of ‘conftest.err’.  The
     workaround is to specify ‘CC’ when run configure with ‘CC='cc
     -Hnocopyr'’.

   • Any earlier DG/UX system with ELF executables, such as R3.10 or
     R4.10, is also likely to work, but hasn't been explicitly tested.

   • On Reliant Unix libtool has only been tested with the Siemens
     C-compiler and an old version of ‘gcc’ provided by Marco Walther.

   • ‘libtool.m4’, ‘ltdl.m4’ and the ‘configure.ac’ files are marked to
     use autoconf-mode, which is distributed with GNU Emacs 21, Autoconf
     itself, and all recent releases of XEmacs.

   • When building on some GNU/Linux systems for multilib targets
     ‘libtool’ sometimes guesses the wrong paths that the linker and
     dynamic linker search by default.  If this occurs for the dynamic
     library path, you may use the ‘LT_SYS_LIBRARY_PATH’ environment
     variable to adjust.  Otherwise, at ‘configure’ time you may
     override libtool's guesses by setting the ‘autoconf’ cache
     variables ‘lt_cv_sys_lib_search_path_spec’ and
     ‘lt_cv_sys_lib_dlsearch_path_spec’ respectively.

   • For many GNU/Linux systems, the shared library cache is not updated
     after a ‘make install’.  Instead, the user will need to manually
     execute ‘ldconfig 'LIBDIR'’ to locate newly installed libraries.
     Users should consult a system administrator as this should be done
     with great care.  Here are some considerations:

        • Libtool is designed to be portable to many different operating
          systems, and these OSs behave in various ways.  Some OSs will
          find a new library automatically if it is installed in the
          existing configured library paths.

        • The library installed might not ever be intended to be used by
          the currently executing OS because it is part of new
          distribution builds.

        • Sometimes libraries are installed privately, using hard-coded
          run-paths in their dependent binaries.  This is very common
          when a different version of the software is to be run than the
          OS is designed to support.

   • When using the MSVC toolchain, users should set Fortran environment
     variables to the following F77="no" and FC="no".  This should avoid
     possible issues for symbols not being found when linking libltdl.

