Re: [PATCH] gcc: Add new configure options to allow static libraries to be selected

[Andrew Burgess <andrew dot burgess at embecosm dot com>]

* Jeff Law <law@redhat.com> [2020-01-22 13:52:27 -0700]:

> On Wed, 2020-01-22 at 15:39 +0000, Andrew Burgess wrote:
> > 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: Regnerate.
> > 
> > libstdc++-v3/ChangeLog:
> > 
> > 	* configure: Regnerate.
> s/Regnerate/Regenerate/
> 
> This isn't strictly a regression bugfix.  But given the nature of these
> files I think we probably need to be a bit more lax and allow safe
> changes so that downstream uses can move forward independent of the gcc
> development and release schedule.
> 
> So, OK.

Thanks for the flexibility.  Now pushed.

Thanks,
Andrew