This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: gengenrtl needs to link with libintl
- To: dave at hiauly1 dot hia dot nrc dot ca
- Subject: Re: gengenrtl needs to link with libintl
- From: DJ Delorie <dj at redhat dot com>
- Date: Tue, 13 Nov 2001 00:05:14 -0500
- Cc: gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- References: <200111130445.fAD4jHvh027099@hiauly1.hia.nrc.ca>
> Do you think configure should support HAVE_LIBINTL_H?
For libiberty, the problem is three times harder, because libiberty is
built for the host (like gcc), for the target (like libstdc++), and
soon for the build. To properly support libintl, we'd need three
configure flags: --enable-nls --enable-target-nls --enable-build-nls.
And probably a much more complicated configury (mostly because of the
target-side build).
> Another option to prevent the interaction with gcc's config.h and
> any other package which uses libiberty might be to unconditionally
> disable the HAVE_LIBINTL_H (NLS) code in these functions.
That would make libiberty diverge from glibc, so I'd rather avoid
that. In fact, I'm working on converging them again. The problem
with gcc's config.h doesn't affect other packages, because they don't
do what gcc does (namely, build a build-obstack.o with a
host-config.h). What gcc needs is a build-side libiberty. Until
then, the ENABLE_NLS and/or Zack's config.h patches give us a
workaround.