Re: Multiple definitions of ___printf__

[Ben Pfaff]

John Darrington <address@hidden> writes:

> On Thu, Mar 25, 2010 at 09:36:48PM -0700, Ben Pfaff wrote:
>
>      We used to call AM_GNU_GETTEXT, but commit e59bf0b7b7 "Rewrite
>      automake rules for internationalisation files." back in August
>      2009 deleted it.
>      
>      I suspect that we should re-add
>              AM_GNU_GETTEXT([external], [need-ngettext])
>              AM_GNU_GETTEXT_VERSION([0.17])
>      back to configure.ac, and then append
>              if test -n "$LIBINTL"; then
>                  AC_DEFINE([DEPENDS_ON_LIBINTL], [1],
>                            [Define to 1 if libintl is built as a
>                             separate library rather than integrated
>                             into libc])
>              fi
>      based on Bruno's advice.
>      
>      What do you think?
>
> Removing AM_GNU_GETTEXT* was a concious decision.  I decided
> that it was hindering more than helping.  The log message for
> that commit elaborates on this.  If we decide to use
> AM_GNU_GETTEXT again, we should make sure that these problems
> don't reappear.  Particularly, since we now have a number of
> active translators.

AM_GNU_GETTEXT has two purposes.  First, it figures out how to
link against libintl.  Second, it invokes AM_PO_SUBDIRS to set up
all the po directory variables, etc.

I think that it is only the second part that causes trouble, and
I think that we can disable the second part by writing
        AC_PROVIDE([AM_PO_SUBDIRS])
just above the call to AM_GNU_GETTEXT.

I'll try this tonight, if I have time.

> I don't think it will be very difficult to write an autoconf
> test to see if libc contains libintl or not.

The gettext manual makes it sound difficult.  From the section
titled "AM_GNU_GETTEXT in `gettext.m4'":

   The complexities that `AM_GNU_GETTEXT' deals with are the following:

   * Some operating systems have `gettext' in the C library, for example
     glibc.  Some have it in a separate library `libintl'.  GNU
     `libintl' might have been installed as part of the GNU `gettext'
     package.

   * GNU `libintl', if installed, is not necessarily already in the
     search path (`CPPFLAGS' for the include file search path,
     `LDFLAGS' for the library search path).

   * Except for glibc, the operating system's native `gettext' cannot
     exploit the GNU mo files, doesn't have the necessary locale
     dependency features, and cannot convert messages from the
     catalog's text encoding to the user's locale encoding.

   * GNU `libintl', if installed, is not necessarily already in the run
     time library search path.  To avoid the need for setting an
     environment variable like `LD_LIBRARY_PATH', the macro adds the
     appropriate run time search path options to the `LIBINTL' and
     `LTLIBINTL' variables.  This works on most systems, but not on
     some operating systems with limited shared library support, like
     SCO.

   * GNU `libintl' relies on POSIX/XSI `iconv'.  The macro checks for
     linker options needed to use iconv and appends them to the
     `LIBINTL' and `LTLIBINTL' variables.

-- 
Ben Pfaff 
http://benpfaff.org