]> git.ipfire.org Git - thirdparty/gcc.git/commit
gcc: Add new configure options to allow static libraries to be selected
authorAndrew Burgess <andrew.burgess@embecosm.com>
Wed, 22 Jan 2020 14:54:26 +0000 (14:54 +0000)
committerAndrew Burgess <andrew.burgess@embecosm.com>
Mon, 27 Jan 2020 22:02:35 +0000 (22:02 +0000)
commite7c26e04b2dd6266d62d5a5825ff7eb44d1cf14e
tree62d830b9fba6b4823faf161909504f0bbde3bdb5
parent15d552394e1cb94598eef278ff3d9e9876097b33
gcc: Add new configure options to allow static libraries to be selected

The motivation behind this change is to make it easier for a user to
link against static libraries on a target where dynamic libraries are
the default library type (for example GNU/Linux).

Further, my motivation is really for linking libraries into GDB,
however, the binutils-gdb/config/ directory is a copy of gcc/config/
so changes for GDB need to be approved by the GCC project first.

After making this change in the gcc/config/ directory I've run
autoreconf on all of the configure scripts in the GCC tree and a
couple have been updated, so I'll use one of these to describe what my
change does.

Consider libcpp, this library links against libiconv.  Currently if
the user builds on a system with both static and dynamic libiconv
installed then autotools will pick up the dynamic libiconv by
default.  This is almost certainly the right thing to do.

However, if the user wants to link against static libiconv then things
are a little harder, they could remove the dynamic libiconv from their
system, but this is probably a bad idea (other things might depend on
that library), or the user can build their own version of libiconv,
install it into a unique prefix, and then configure gcc using the
--with-libiconv-prefix=DIR flag.  This works fine, but is somewhat
annoying, the static library available, I just can't get autotools to
use it.

My change then adds a new flag --with-libiconv-type=TYPE, where type
is either auto, static, or shared.  The default auto, ensures we keep
the existing behaviour unchanged.

If the user configures with --with-libiconv-type=static then the
configure script will ignore any dynamic libiconv it finds, and will
only look for a static libiconv, if no static libiconv is found then
the configure will continue as though there is no libiconv at all
available.

Similarly a user can specify --with-libiconv-type=shared and force the
use of shared libiconv, any static libiconv will be ignored.

As I've implemented this change within the AC_LIB_LINKFLAGS_BODY macro
then only libraries configured using the AC_LIB_LINKFLAGS or
AC_LIB_HAVE_LINKFLAGS macros will gain the new configure flag.

If this is accepted into GCC then there will be follow on patches for
binutils and GDB to regenerate some configure scripts in those
projects.

For GCC only two configure scripts needed updated after this commit,
libcpp and libstdc++-v3, both of which link against libiconv.

config/ChangeLog:

* lib-link.m4 (AC_LIB_LINKFLAGS_BODY): Add new
--with-libXXX-type=... option.  Use this to guide the selection of
either a shared library or a static library.

libcpp/ChangeLog:

* configure: Regenerate.

libstdc++-v3/ChangeLog:

* configure: Regenerate.
config/ChangeLog
config/lib-link.m4
libcpp/ChangeLog
libcpp/configure
libstdc++-v3/ChangeLog
libstdc++-v3/configure