[tlbuild] Stripping the luatex binary

[Philipp Stephani]

Am 07.04.2011 um 10:13 schrieb Peter Breitenlohner:

> On Tue, 5 Apr 2011, Peter Breitenlohner wrote:
> 
>> Well, given such a substitute for "strip" this could be done by configure or
>> maybe even from outside.
> 
> Hi Philipp and Taco,
> 
> 1. can you please try to configure TL or the stand alone luatex (as far as I
> know essentially a cut down version of TL) with
> 
>  configure STRIP='strip -S -x' ....
> 
> note this is not the same as having STRIP in the environment!  This is for
> the bare configure, youd'd have to translate that for Build or build.sh. With this 'make install-strip' should use 'strip -S -x' for luatex.

This doesn't work since in the rule

install-strip:
	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
	  `test -z '$(STRIP)' || \
	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install

the `test...` isn't properly quoted (at least on my system) so that no spaces can be used in the STRIP variable.

> 
> 2. in order to quickly verify that this works, you could go to texk/web2c/
> in the build tree and do
> 
>  make STRIP='strip -S -x' DESTDIR=/tmp install-strip
> 
> in order to install under /tmp/

Same problem as above. However, if I say STRIP=/tmp/mystrip with an appropriate /tmp/mystrip script (which should theoretically work), there are numerous other errors during the compilation process. Even with make -k nothing gets installed. Specifically, I get a bunch of undefined symbols when building "makeconv".

> 
> 3. it seems to me that the whole problem is somewhat home made by lua and
> caused by a slightly naive handling of extension modules.
> 
> In other cases (e.g., gtk input methods, pam modules) the procedure is
> 
>  a) load the extension module
>  b) get address of the module's init function
>  c) call the module's init function
> 
> where step (c) can pass a table of function (and data) pointers in the main
> binary that the module might legitimately use.  That way the module doesn't
> depend on any global symbol from the main binary.  Unfortunately that is not
> the way lua works.

Yes, requiring a library to call external functions in a program seems to be uncommon on all systems, and is totally unsupported on Windows. That's why Lua uses a shared library instead on Windows, and I think it should do so on OS X, too.