[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