Re: Multiple definitions of ___printf__

[Ben Pfaff]

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>