Re: gengenrtl needs to link with libintl

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> > I am still a puzzled as to what generator programs can and can't link
> > with.
> 
> The problem is detecting what's available, since autoconf doesn't
> check the build system when build!=host.  At the moment, anything that

When build!=host, autoconf wouldn't check the build system and as a
result HAVE_LIBINTL_H would not be defined.  Then, obstack.c would
not define gettext to be the error handler.  Thus, it should be
possible for autoconf to check for libintl and appropriately set
INTLLIBS and HAVE_LIBINTL_H when build==host.

However, I still think there should be a better way to turn
internationalization ON and OFF in obstack.c.  Maybe obstack
should do something similar to gcc/intl.h.  It defines
gettext(msgid) to (msgid) when ENABLE_NLS is undefined.

> will run on the build system can't link against anything in the build
> tree, and we don't autoconf-test the build system, so we have to be
> particularly careful to write portable code.  In general, generator
> programs shouldn't link with *anything* if possible.

It seems obstack.c needs memcpy, exit (in some cases), malloc and free.

> I think the problems we're seeing now are due to a partial infection
> of a build-system build with host-system config.h from libiberty,
> because of the obstack hack.  A build-libiberty should solve that
> problem neatly, and perhaps pave the way to better handling of the
> build system configuration.  We'll have to see how it pans out.
> 

No disagreement here.  There used to be similar problems when alloca
was built in the gcc tree.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)