Re: -no-undefined

[Ken Brown]

On 1/13/2016 3:09 PM, Eli Zaretskii wrote:

Date: Wed, 13 Jan 2016 19:42:45 +
From: Gavin Smith 
Cc: Texinfo 

It would appear to be inappropriate to add the -no-undefined flag
unconditionally.


Then we should do so conditionally, I guess.  E.g., have a Make
variable that is normally empty, except on Windows.


-no-undefined is needed on Cygwin also.

Ken

-no-undefined

[Gavin Smith]

On 1 January 2016 at 14:36, Eli Zaretskii  wrote:
>> Is this the right fix? -
>>
>> Index: Makefile.am
>> ===
>> --- Makefile.am (revision 6893)
>> +++ Makefile.am (working copy)
>> @@ -78,14 +78,14 @@
>>
>>  XSParagraph_la_CFLAGS += -DVERSION=\"$(VERSION)\"
>> -DXS_VERSION=\"$(XSPARAGRAPH_INTERFACE_VERSION)\"  "-I$(PERL_INC)"
>>
>> -XSParagraph_la_LDFLAGS=-avoid-version -module $(PERL_CONF_cccdlflags)
>> +XSParagraph_la_LDFLAGS=-no-undefined -avoid-version -module
>> $(PERL_CONF_cccdlflags)
>>
>>
>>  TestXS_la_CFLAGS = $(PERL_CONF_ccflags)
>>
>>  TestXS_la_CFLAGS += -DVERSION=\"$(VERSION)\"
>> -DXS_VERSION=\"$(VERSION)\"  "-I$(PERL_INC)"
>>
>> -TestXS_la_LDFLAGS=-module $(PERL_CONF_cccdlflags)
>> +TestXS_la_LDFLAGS=-no-undefined -module $(PERL_CONF_cccdlflags)
>
> Looks OK, thanks.

Apparent problem under Solaris 10 with this change. I've realised that
since SVN revision 6903, which made this change (adding
-no-undefined), the XS modules don't get used. From log at
https://buildfarm.opencsw.org/buildbot/builders/texinfo-solaris10-i386/builds/574/steps/shell_1/logs/stdio:

/bin/bash ./libtool  --tag=CC   --mode=link /opt/SUNWspro/bin/cc
-D_REENTRANT -I/opt/csw/bdb48/include -I/opt/csw/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV
-DVERSION=\"6.0\" -DXS_VERSION=\"6.0\"
"-I/opt/csw/lib/perl/5.10.1/CORE"  -no-undefined -module   -o
TestXS.la -rpath /usr/local/libexec/texinfo TestXS_la-TestXS.lo
libtool: link: /opt/SUNWspro/bin/cc -G -z defs -h TestXS.so.0 -o
.libs/TestXS.so.0.0.0  .libs/TestXS_la-TestXS.o   -lc
Undefined first referenced
 symbol  in file
Perl_newSVpv.libs/TestXS_la-TestXS.o
Perl_vstringify .libs/TestXS_la-TestXS.o
Perl_croak  .libs/TestXS_la-TestXS.o
Perl_sv_derived_from.libs/TestXS_la-TestXS.o
Perl_Istack_sp_ptr  .libs/TestXS_la-TestXS.o
Perl_Icurpad_ptr.libs/TestXS_la-TestXS.o
Perl_get_sv .libs/TestXS_la-TestXS.o
Perl_Iunitcheckav_ptr   .libs/TestXS_la-TestXS.o
Perl_croak_xs_usage .libs/TestXS_la-TestXS.o
Perl_form   .libs/TestXS_la-TestXS.o
Perl_vcmp   .libs/TestXS_la-TestXS.o
Perl_Iop_ptr.libs/TestXS_la-TestXS.o
Perl_newXS_flags.libs/TestXS_la-TestXS.o
Perl_sv_newmortal   .libs/TestXS_la-TestXS.o
Perl_Isv_yes_ptr.libs/TestXS_la-TestXS.o
Perl_Istack_base_ptr.libs/TestXS_la-TestXS.o
Perl_sv_2pv_flags   .libs/TestXS_la-TestXS.o
Perl_Imarkstack_ptr_ptr .libs/TestXS_la-TestXS.o
Perl_new_version.libs/TestXS_la-TestXS.o
Perl_Iscopestack_ix_ptr .libs/TestXS_la-TestXS.o
Perl_call_list  .libs/TestXS_la-TestXS.o
ld: fatal: symbol referencing errors. No output written to .libs/TestXS.so.0.0.0
Makefile:914: recipe for target 'TestXS.la' failed
make: *** [TestXS.la] Error 1
no

Compare this with the log at
https://buildfarm.opencsw.org/buildbot/builders/texinfo-solaris10-i386/builds/573/steps/shell_1/logs/stdio:

/bin/bash ./libtool  --tag=CC   --mode=link /opt/SUNWspro/bin/cc
-D_REENTRANT -I/opt/csw/bdb48/include -I/opt/csw/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV
-DVERSION=\"6.0\" -DXS_VERSION=\"6.0\"
"-I/opt/csw/lib/perl/5.10.1/CORE"  -module   -o TestXS.la -rpath
/usr/local/libexec/texinfo TestXS_la-TestXS.lo
libtool: link: /opt/SUNWspro/bin/cc -G -h TestXS.so.0 -o
.libs/TestXS.so.0.0.0  .libs/TestXS_la-TestXS.o   -lc
libtool: link: (cd ".libs" && rm -f "TestXS.so.0" && ln -s
"TestXS.so.0.0.0" "TestXS.so.0")
libtool: link: (cd ".libs" && rm -f "TestXS.so" && ln -s
"TestXS.so.0.0.0" "TestXS.so")
libtool: link: ar cru .libs/TestXS.a  TestXS_la-TestXS.o
libtool: link: ranlib .libs/TestXS.a
libtool: link: ( cd ".libs" && rm -f "TestXS.la" && ln -s
"../TestXS.la" "TestXS.la" )
message from XS module
yes

It would appear to be inappropriate to add the -no-undefined flag
unconditionally.

Re: -no-undefined

[Eli Zaretskii]

> Date: Wed, 13 Jan 2016 19:42:45 +
> From: Gavin Smith 
> Cc: Texinfo 
> 
> It would appear to be inappropriate to add the -no-undefined flag
> unconditionally.

Then we should do so conditionally, I guess.  E.g., have a Make
variable that is normally empty, except on Windows.

Re: XeTeX encoding problem

[Masamichi HOSODA]

>> I've created a patch that uses native unicode support of both XeTeX and 
>> LuaTex.
>> It works fine in my XeTeX, LuaTeX and pdfTeX environment.
>> Except, LuaTeX create broken PDF bookmark.
>>
>> How about this?
> 
> It looks mostly all right. We'd need to wait until we have your
> copyright assignment on file before merging a patch of this size.

I sent it, today.

> The main change I'd make is to turn it off by default to avoid the
> risk of breaking something that worked before (for example: if someone
> didn't have the right fonts installed), but it would be easy to modify
> your patch to do this.

If XeTeX/LuaTeX is used and @documentencoding is UTF-8,
using native UTF-8 support is very natural for me.

Of course, even if using XeTeX/LuaTeX, if @documentencoding is US-ASCII,
I think that the native UTF-8 support may be turned off.

Most users use pdfTeX instead of XeTeX/LuaTeX.
The risk of using native UTF-8 support is few
because pdfTeX does not have the function.

If you consciously use XeTeX/LuaTeX instead of pdfTeX
and consciously set @documentencoding to UTF-8 instead of US-ASCII,
it means that you want to use native UTF-8 support in my humble opinion.

Otherwise, if you use UTF-8 characters on XeTeX/LuaTeX
without native UTF-8 support, some problems can be happen.
(something like ``Table of Contents'' broken etc.)
I think this is obviously a risk.

Additionally, CJK characters can not be used without native UTF-8 support.