[tlbuild] Building on Mac

[Peter Breitenlohner]

On Wed, 21 Mar 2012, Richard Koch wrote:

> c) We build 32 bit PPC binaries on a PPC Leopard machine. Everything builds except
> XeTeX, which runs into problems in the link stage. Here's the console output. Does
> someone know what is wrong?
>
> ----------
> libtool: link: g++ -g -O2 -o xetex xetex-xetexextra.o xetex-synctex.o xetex-xetexini.o xetex-xetex0.o xetex-xetex_pool.o -Wl,-framework -Wl,CoreServices -Wl,-framework -Wl,ApplicationServices -Wl,-bind_at_load  -framework Carbon -framework Cocoa -framework QuickTime libxetex.a libxetexmm.a /Users/koch/texlive2012dev/source/Work/libs/icu/icu-build/lib/libicule.a /Users/koch/texlive2012dev/source/Work/libs/icu/icu-build/lib/libicuuc.a /Users/koch/texlive2012dev/source/Work/libs/icu/icu-build/lib/libicudata.a /Users/koch/texlive2012dev/source/Work/libs/teckit/libTECkit.a /Users/koch/texlive2012dev/source/Work/libs/graphite/libgraphite.a /Users/koch/texlive2012dev/source/Work/libs/freetype2/libfreetype.a /Users/koch/texlive2012dev/source/Work/libs/zlib/libz.a lib/lib.a /Users/koch/texlive2012dev/source/Work/texk/kpathsea/.libs/libkpathsea.a
> ld: bl out of range (-18576024 max is +/-16M) from __static_initialization_and_destruction_0(int, int)at 0x01390030 in __StaticInit of libxetex.a(libxetex_a-XeTeXLayoutInterface.o) to __ZNSt8ios_base4InitC1Ev$stub$island at 0x001D8DDC in __text of  xetex in __static_initialization_and_destruction_0(int, int)from libxetex.a(libxetex_a-XeTeXLayoutInterface.o)
> collect2: ld returned 1 exit status

Hi Dick,

my guess: this is caused by the fact that the unicode data in libicudata.a
have grown such that the size of either the executable or the unicode data
exceeds the 16M limit.  Perhaps there is a linker option to increase that
limit.

Looking at libs/icu/icu-build/data/out/tmp/icudt49l_dat.o from this year
(for i686-linux) the file has 17958049 bytes with 0x1120240 bytes of ro
data.  For icudt46l_dat.o from last year these numbers are 15148097 and
0xe721e0.

Your number 18576024=0x11b7298 could support this idea.

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