Re: Multiple definitions of ___printf__

[Ben Pfaff]

I agree.  It is actually hardcoded into Automake though:

  if (-d 'po')
    {
      my @subdirs = $subdirs->value_as_list_recursive;

      msg_var ('syntax', $subdirs,
               "AM_GNU_GETTEXT used but `po' not in SUBDIRS")
        if ! grep ($_ eq 'po', @subdirs);

      # intl/ is not required when AM_GNU_GETTEXT is called with the
      # `external' option and AM_GNU_GETTEXT_INTL_SUBDIR is not called.
      msg_var ('syntax', $subdirs,
               "AM_GNU_GETTEXT used but `intl' not in SUBDIRS")
        if (! ($seen_gettext_external && ! $seen_gettext_intl)
            && ! grep ($_ eq 'intl', @subdirs));

      # intl/ should not be used with AM_GNU_GETTEXT([external]), except
      # if AM_GNU_GETTEXT_INTL_SUBDIR is called.
      msg_var ('syntax', $subdirs,
               "`intl' should not be in SUBDIRS when "
               . "AM_GNU_GETTEXT([external]) is used")
        if ($seen_gettext_external && ! $seen_gettext_intl
            && grep ($_ eq 'intl', @subdirs));
    }

It's possible that using an Automake conditional that we never
define would be sufficient, e.g. in configure.ac:
        AM_CONDITIONAL([NOPE], [false])
and in Makefile.am:
        if NOPE
        SUBDIRS += po
        endif

I'll see if that works too.

John Darrington <address@hidden> writes:

> It's a real shame we have to have that dummy po/Makefile.am
> One would have thought that because  we have the AC_PROVIDE([AM_PO_SUBDIRS])
> line it wouldn't be necessary.
>
>
> On Sat, Mar 27, 2010 at 02:31:01PM -0700, Ben Pfaff wrote:
>      I pushed out my proposed changes to a new branch named
>      "proposed-gettext".  It passes the testsuite.
>      
>      Comments?
>      
>      John Darrington <address@hidden> writes:
>      
>      > Yes.  I recall that was my primary complaint - it does (at least)
>      > two distinct  things.  At the time I didn't find a way to seperate
>      > them.  If we can do that, then it might be worth considering using
>      > it again.
>      >
>      > On Fri, Mar 26, 2010 at 05:05:16PM -0700, Ben Pfaff wrote:
>      >      
>      >      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
>      
>      -- 
>      Regarding a Microsoft/Xerox agreement:
>       "This is a match made in heaven.
>        Both companies excel at copying other people's work."
>      address@hidden <URL:http://slashdot.org/article.pl?sid=99/05/16/2211252>

-- 
Ben Pfaff 
http://benpfaff.org