[tlbuild] Stripping the luatex binary

[Peter Breitenlohner]

On Fri, 1 Apr 2011, Philipp Stephani wrote:

>> (3) thus "libtool --mode=link" is used to build the binaries, for luatex
>> with '--export-dynamic' but for pdftex without, and "libtool --mode=install"
>> to install them.
>
> The OS X libtool has neither --mode nor --export-dynamic flags, nor does
> the linker.  Do you use a custom libtool and/or linker?

Hi Philipp,

no, I was talking about GNU libtool (and didn't know that there is an OS X
binary with the same name.

GNU libtool is a shell script created by configure (from ltmain.sh and test
results) used to build shared and/or static "libtool libraries" and
executables using such libraries and allows to run uninstalled such programs
using equally uninstalled shared libraries, e.g., in order to test the
libraries plus programs before installing them.

This libtool script does have both the --mode option and --export-dynamic
flag, the later is supposed to
      Allow symbols from OUTPUT-FILE to be resolved with `dlsym'

The libtool script is supposed to pass suitable flags to the system linker
to achieve that and it is nowhere said that 'strip' would remove such exported
symbols.  From my experience there seems to be a distinction between
exported symbols and debug symbols (but that may not so for OS X, causing
all the problems).

>> (4) Autoconf likes to compile with '-g' unless the user specifies CFLAGS (or
>> CXXFLAGS).
>>
>> (5) the programs are stripped upon installation when this is done via "make
>> install-strip" and it seems this is always done with '-s'.
>
> Do you mean -S (capital S)? If so, that's fine and also supported by OS X strip and ld.

certainly not, I mean '-s' (small s).

>> To see how all this works for i686-linux-gnu (and probably linux in general)
>> I have inspected the unstripped versions in the build tree as well as the
>> stripped installed ones with 'nm' and grepped for 'write_png':
>>
>> 	unstripped luatex or pdftex:	one 'T write_png'
>> 	stripped luatex or pdftex:	nothing
>>
>> Next I have grepped the output of 'strings':
>>
>> 	unstripped or stripped luatex:	two times 'write_png'
>> 	unstripped or stripped pdftex:	nothing
>
> On some x86-64 bit Linux system, nm says "no symbols" for both lua and
> luatex.  Maybe the loader ABI is again different for 64-bit Linux systems.

I think the test above demonstrates this.  nm sees lots of symbols in the
unstripped versions of both binaries and none in the stripped versions. 
However, the string 'write_png' (together with many others, I just wanted a
symbol present in both programs) is present in the luatex binary and absent
in pdftex (stripped or not).

>> If all that doesn't work for OS X, this is IMHO a libtool + OS X problem
>
> The underlying program (ld) works as expected, and if I compile with
> "build.sh --nostrip" from the LuaTeX repository, I get a working binary
> even though the makefile uses libtool to call ld.  But LuaTeX uses a
> custom libtool, maybe that makes a difference.

More precisely: a "GNU libtool" + "OS X ld" + "OS X strip" problem.

>> (either the OS X ld doesn't have the required capabilities

> No special capabilities are required since all symbols are exported by
> default.  It works (at least with the binary from the LuaTeX repository)
> if you call strip with -S -x.  Libtool itself doesn't seem to call strip
> at all (at least when compiled with LuaTeX's build script).  To summarize:
> On OS X, call "ld -S -x -o luatex", or call "strip -S -x luatex"
> afterward, but not "strip luatex".

With the present TL build system that would mean that no OS X binaries can
be stripped. That might be an option provided they are compiled without
debugging symbols.

NB: why would luatex want to to load, e.g., lsqlite3.so?  Is this because
texlua (-> luatex) is used as general purpose lua interpreter?

Regards
Peter Breitenlohner <peb at mppmu.mpg.de>