Compilation failure of texlive: a bug in clang or application code?

Dan Ports dports at macports.org
Wed Jan 16 02:39:02 PST 2013


On Mon, Jan 14, 2013 at 04:10:34PM +0100, Mojca Miklavec wrote:
> XeTeX
> (http://sourceforge.net/projects/xetex/,
> http://xetex.git.sourceforge.net or
> http://tug.org/svn/texlive/trunk/Build/source/) finally builds under
> x86_64 without patching (earlier it didn't compile at all and the
> current version in MacPorts disables part of the functionality that
> depends on Carbon libraries for handling AAT).

This is really great news! Do we have Khaled to thank for this?

> The problem is that an ancient code from TeX Live and some clang
> libraries clash with each other when loading Carbon (or CoreServices &
> ApplicationServices).

I ran into this problem a while back also, though I didn't look too far
into it because it only came up for a variant we don't build by
default. We use llvm-gcc to build the +atsui variant; getting it to
work with clang wasn't a priority since it was also 32-bit only.
(Actually, I had thought the header file problem was specific to ATS;
had I realized it was related to Carbon in general, I would have
reported it upstream.)

> So my question is basically: can this be considered a bug in clang and
> if so: what would be the best place to report it to? (And if not, is
> anyone willing to take a look to see if there's an easy workaround
> before the port maintainer gets bitten by this issue?)

I'm not sure if this is technically a bug in clang, but it's surprising
enough behavior that it's worth reporting.

If this isn't deemed a bug in clang (or while waiting for a fixed
version to be available), we can always build the port with llvm-gcc;
it's not ideal, but it's not a serious problem.

Dan

-- 
Dan R. K. Ports                UW CSE                http://drkp.net/


More information about the macports-dev mailing list