[XeTeX] XeTeX build fails

Jonathan Kew jonathan_kew at sil.org
Fri Dec 21 22:46:10 CET 2007


On 21 Dec 2007, at 8:04 pm, Peter Dyballa wrote:

>
> Am 21.12.2007 um 18:01 schrieb Jonathan Kew:
>
>> So are you sure that's the gcc being used to build all the files
>> involved?
>
> No, of course not. Once the build-xetex script starts I have on
> influence.

Your path and other environment settings *are* an influence!

The script doesn't do anything out of the ordinary; it just runs  
configure and make for the various libs and then xetex itself, as  
there isn't currently a single top-level makefile target that handles  
all the dependencies properly. You could read it, and follow the same  
steps by hand if you like.

> Searching the *compilation* buffer I get:
>
> 	checking dependency style of gcc... gcc3		configuring in graphite-
> engine
> 	checking dependency style of g++... gcc3		configuring in graphite-
> engine
> 	checking dependency style of g++... (cached) gcc3	configuring in  
> teckit
> 	checking dependency style of gcc... (cached) gcc3	configuring in  
> teckit
>
> There are some strange lines I don't understand, in which gcc-
> <something> is used:
>
> 	DYLD_LIBRARY_PATH=../lib:../stubdata:../tools/ctestfw:
> $DYLD_LIBRARY_PATH  ../bin/genccode -a gcc-darwin -n icudt36b -e
> icudt36 -d ./out/tmp out/tmp/icudt36b.dat
> 	DYLD_LIBRARY_PATH=../lib:../stubdata:../tools/ctestfw:
> $DYLD_LIBRARY_PATH  ../bin/genccode -a gcc-darwin -n icudt36b -e
> icudt36 -d ./out/tmp out/tmp/icudt36b.dat
> 	DYLD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw:
> $DYLD_LIBRARY_PATH  ../../bin/genccode -a gcc-darwin -n uconvmsg -e
> uconvmsg -d uconvmsg uconvmsg/uconvmsg.dat

That looks like an option being passed to ICU's genccode tool; I see  
the same thing.

>> And was it used to build whatever libraries you're linking with?
>
> Libtool is hiding this detail it delegates to gcc. I'll try another
> compilation with -v among the CFLAGS!
>
> 'otool -L xetex' returns only system libraries. I don't know how to
> determine their compiler(s) or the static libraries in xetex, and how
> they were built. This, at least, gives a hint that a mismatch of
> compilers and linkers might exist. This situation is also true for
> Carbon Emacs or Emacs.app or whatever built here – and all these
> applications are built without complaints or failures. And they work.

The system libraries aren't the problem; my guess is that it's a  
mismatch between the gcc version used to compile some of the object  
files and the gcc runtime libs or C standard library used by the  
linker (ld). The idea of mixing Apple's gcc and Fink's ld sounds like  
a recipe for trouble to me.

I think those errors about "_fprintf$LDBLStub" etc are characteristic  
of trying to link object files compiled by gcc 4.x using ld and/or  
library versions that belong to gcc 3.3. In many cases you may get  
away with this, but if the gcc4-compiled code uses runtime library  
symbols that weren't present in the earlier version, it'll fail.

>> I've seen those undefined symbols before, but it's always been
>> caused by mixed compiler (or C library) versions. If that's not it,
>> then I don't know. You could try inspecting all your object and
>> library files to see where they're being requested.
>
> How can I inspect this?

I'm not sure, maybe nm can help.

It seems that you're trying to use Apple's version of gcc (according  
to the version info you quoted from /usr/bin/gcc); a locally-updated  
libtool (/usr/local/bin/libtool); and a linker from some Fink package  
(/sw/lib/odcctools/bin/ld). Who knows what C libraries (libstdc++,  
libgcc, etc) end up getting used. With a mixture like that, you're on  
your own!

JK



More information about the XeTeX mailing list