Re: Multiple definitions of ___printf__

[John Darrington]

Maybe weĺl have to live with it then.

Would it be worth raising this problem with the automake and/or gettext 
maintainers?


On Mon, Mar 29, 2010 at 08:09:56PM -0700, Ben Pfaff wrote:
     It occurred to me that it wouldn't help, because Automake would
     still expect to see a Makefile for a directory that could ever be
     included in SUBDIRS (it would still use it at "make dist" time,
     for example).
     
     At any rate, this ugliness trades off against the ability to
     support systems with various needs for -lintl and so on.  I think
     that it is probably worth it, since otherwise PSPP won't build
     gracefully on many systems.  What do you think?
     
     Ben Pfaff <address@hidden> writes:
     
     > 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

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

signature.asc
Description: Digital signature