* Jeff Law <l...@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
