[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multiple definitions of ___printf__
From: |
John Darrington |
Subject: |
Re: Multiple definitions of ___printf__ |
Date: |
Tue, 30 Mar 2010 13:20:31 +0000 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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
- Multiple definitions of ___printf__, Michel Boaventura, 2010/03/25
- Re: Multiple definitions of ___printf__, Ben Pfaff, 2010/03/26
- Re: Multiple definitions of ___printf__, Ben Pfaff, 2010/03/26
- Re: Multiple definitions of ___printf__, John Darrington, 2010/03/26
- Re: Multiple definitions of ___printf__, Ben Pfaff, 2010/03/26
- Re: Multiple definitions of ___printf__, John Darrington, 2010/03/27
- Re: Multiple definitions of ___printf__, Ben Pfaff, 2010/03/27
- Re: Multiple definitions of ___printf__, John Darrington, 2010/03/29
- Re: Multiple definitions of ___printf__, Ben Pfaff, 2010/03/29
- Re: Multiple definitions of ___printf__, Ben Pfaff, 2010/03/29
- Re: Multiple definitions of ___printf__,
John Darrington <=