bug-texinfo
[Top][All Lists]
Advanced

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

Re: libintl glitches in XS


From: Hans-Bernhard Bröker
Subject: Re: libintl glitches in XS
Date: Fri, 12 Apr 2019 23:00:11 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

Am 12.04.2019 um 12:56 schrieb Gavin Smith:
> On Tue, Apr 09, 2019 at 11:47:26PM +0200, Hans-Bernhard Bröker wrote:

>> *) I had to add $(LIBINTL) to Parsetexi_la_LIBADD, or it wouldn't manage
>> to build Parsetexi.la.  This may be partly due to Cygwin's variant of
>> shared library, unlike the Linux kind, requiring to be fully covered,
>> i.e. they cannot have undefined references inside.  It feels like
>> something similar should be done with $(LTLIBINTL) and $(LIBICONV), too.
>>  Either that, or $(LTLIBICONF) should be in ..._LIBADD, not ..._LDFLAGS.
> 
> Is this with Texinfo 6.6 or the current git development?  

It's the git head version.

> I see in tp/Texinfo/XS/Makefile.am, $(LIBINTL) is in XSParagraph_la_LIBADD
> so it would make sense to have it in Parsetexi_la_LIBADD too.  (Although 
> XSParagraph.la doesn't use gettext, so maybe it is needed for something 
> else.)  Is that the only change you needed to make it work?

That alone did appear to fix it.

OTOH, so did replacing $(LTLIBICONV) in Parsetexi_la_LDFLAGS with
$(LTLIBINTL).  I.e. the core issue may just be that we now need the full
-lintl instead of just -liconv.

I'm really not suffiiently clear on what the difference between
$(LTLIBINTL) and  $(LIBINTL) is supposed to be, including the question
which is supposed to be used where.

> The "undefined references" issue is supposed to be taken care of in 
> Makefile.am under the HOST_NEEDS_NO_UNDEFINED section.

Let's see...

Yes, adding this

if HOST_NEEDS_NO_UNDEFINED
Parsetexi_la_LDFLAGS += $(LTLIBINTL)
endif

below the definition of Parsetex_la_LDFLAGS does work.

>> *) I'm seeing quite a few `$p' in Makefile.am.  I'm pretty sure these
>> really should be `$(p)' instead.

> If the brackets are missing the first character after the $ is taken as 
> the variable name.

After I now managed to find where that's documented for GNU make, I have
to point out that it's immediately followed by

> However, this practice is strongly discouraged, except in the case of
> the automatic variables (*note Automatic Variables::).



reply via email to

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