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. jeff >
