[tlbuild] Stripping the luatex binary

George N. White III gnwiii at gmail.com
Mon May 2 19:49:23 CEST 2011


On Sat, Apr 30, 2011 at 2:40 PM, Philipp Stephani <st_philipp at yahoo.de> wrote:
>
> Am 28.04.2011 um 23:13 schrieb Karl Berry:
>
>>    I'm on OS X 10.6. Running ./Build ends with:
>>    Undefined symbols:
>>      "_u_getDataDirectory_46", referenced from:
>>          _main in makeconv.o
>>
>> Hmm.  u_getDataDirectory is defined in icu-4.6/common/putil.c.  So the
>> question is apparently where this _46 suffix is being added and how to
>> stop it (or add it to definition).  That's not something I want to delve
>> into, even if I had access to such a system (which I don't), sorry.
>
> The 46 suffix indicates the version number of the ICU library, and that is fine. The problem was that I had a dynamic version of the ICU libraries in /usr/local which are always preferred by the linker even if the directory of the static libraries is listed on the command line. (This means that linking against static libraries without giving the full file name is not portable.)
>

You are missing a key option to ld -- "man ld" (on Leopard) says:

 -search_paths_first
                 By default the -lx and -weak-lx options first search for a
                 file of the form `libx.dylib' in each directory in the
                 library search path, then a file of the form `libx.a' is
                 searched for in the library search paths.  This option
                 changes it so that in each path `libx.dylib' is searched for
                 then `libx.a' before the next path in the library search path
                 is searched.


>>
>>    make[5]: *** No rule to make target `mplibdir/lmplib.c', needed by
>>    `libluatex_a-lmplib.o'.  Stop.  make[4]: *** [all-recursive] Error 1
>>
>> Well, that file does exist, in source/texk/web2c/mplibdir/lmplib.c.
>> If this wasn't a completely fresh Build, definitely try that first.
>>
>> Otherwise, all I can think of is to run it again, let it fail, and then
>> rerun make -rd in the directory where it failed, which will output
>> voluminous debugging information about what is going on.
>
> I'll have to wait until the ptexlib.h issue (which is now the first error) is sorted. Thanks for your support so far.
>



-- 
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia



More information about the tlbuild mailing list