On 05/29/2015 10:25 PM, Yaakov Selkowitz wrote:
> This is the second in a series of patches to make a build with an
> in-tree GNU libiconv work as designed.
>
> Currently GDB is the only toolchain component which actually uses an
> in-tree libiconv. This patch modifies the common AM_ICONV to use an
> in-tree libiconv when present and not already provided by libc. (GDB's
> workaround uses an in-tree libiconv even when libc provides iconv(3);
> I'm not sure when or why that would be desirable.)
>
> Once these two patches are merged in to each tree, I will follow with
> patches to regenerate the various configure scripts and a few other
> minor corresponding changes.
I noticed that regenerating binutils/configure or gdb/configure
undoes the libiconv changes done here:
commit 016a3251631341bf4d8fe50966d2b70f8ea69e96
Author: DJ Delorie <d...@redhat.com>
AuthorDate: Thu Aug 6 18:35:26 2015 -0400
Commit: DJ Delorie <d...@redhat.com>
CommitDate: Thu Aug 6 23:55:06 2015 -0400
Yaakov Selkowitz: fixes for in-tree libiconv
* Makefile.def (libiconv): Define bootstrap=true.
Mark pdf/html/info as missing.
(configure-gcc): Depend on all-libiconv.
(all-gcc): Ditto.
(configure-libcpp): Ditto.
(all-libcpp): Ditto.
(configure-intl): Ditto.
(all-intl): Ditto.
* Makefile.in: Regenerate.
binutils/
* configure: Regenerate.
gdb/
* Makefile.in (LIBICONV): Define.
(CLIBS): Add LIBICONV.
* acinclude.m4: Use config/iconv.m4 instead of custom AM_ICONV.
* configure: Regenerate.
However, that commit does not include any config/iconv.m4/AM_ICONV
change. Looks like you forgot to attach the config/iconv.m4 patch, and
then only the regeneration bits were pushed (both binutils-gdb git
and gcc svn)?
Thanks,
Pedro Alves
