pspp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multiple definitions of ___printf__


From: Ben Pfaff
Subject: Re: Multiple definitions of ___printf__
Date: Mon, 29 Mar 2010 20:09:56 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]