Hi Andrew,
Andrew Burgess <andrew.burg...@embecosm.com> wrote:
* 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.
This kinda surprises me, gcc/ also configures for iconv
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.
this (r10-6269,
https://gcc.gnu.org/g:e7c26e04b2dd6266d62d5a5825ff7eb44d1cf14e) causes or
exposes a problem which breaks bootstrap on all Darwin platforms I tried.
Bootstrap fails stage1 self-check with:
cc1: internal compiler error: in on_diagnostic, at input.c:2182
* AFAICT, this is caused by self-test attempting to do something that
libcpp was not configured to support.
* All viable Darwin platforms have libiconv installed (but Darwin’s /lib is
/usr/lib; this might well apply to other BSD derivatives too).
* Before the patch, libcpp and gcc configury finds this and they agree on the
availability of ICONV (#define HAVE_ICONV 1).
* After the patch libcpp no longer thinks iconv is available, but gcc
continues to find it - and that, I think, leads to it attempting tests for
which libcpp has not been configured.
* I can work around this by adding —with-iconv-prefix=/usr to the configure
line which forces both libcpp and gcc to find the library explicitly - but
that’s only a short-term solution.
Can you clarify why there’s no need to match the configury changes in
libcpp / gcc / libstdc++ ?
thanks
Iain
