Dear MacPorts wizards, This is a "preliminary problem". I have problems compiling the trunk version of software that's already part of MacPorts (only an older version), but it is not clear to me if the one to be blamed are clang header files or the software that fails to compile.
I'm asking now because it would make sense to solve the issue before the release that's expected somewhere between March and June. 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). The modifications are not 100% finished yet, but the sources are building fine with llvm-gcc-4.2. The problem is that an ancient code from TeX Live and some clang libraries clash with each other when loading Carbon (or CoreServices & ApplicationServices). The problematic code is the following (around line 1100 of /usr/lib/clang/3.1/include/emmintrin.h): static __inline__ __m128i __attribute__((__always_inline__, __nodebug__)) _mm_set_epi8(char b15, char b14, char b13, char b12, char b11, char b10, char b9, char b8, char b7, char b6, char b5, char b4, char b3, char b2, char b1, char b0) { return (__m128i)(__v16qi){ b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, b10, b11, b12, b13, b14, b15 }; } clashing with #define b0 u.B0 #define b1 u.B1 #define b2 u.B2 #define b3 u.B3 from http://tug.org/svn/texlive/trunk/Build/source/texk/web2c/texmfmem.h?view=markup The reported error is: In file included from ../../../texk/web2c/xetexdir/XeTeX_ext.c:57: In file included from ./xetexd.h:571: In file included from ./xetexcoerce.h:1202: In file included from ../../../texk/web2c/xetexdir/xetex.h:103: In file included from ../../../texk/web2c/xetexdir/XeTeXOTMath.h:36: In file included from ../../../texk/web2c/xetexdir/XeTeX_ext.h:78: In file included from /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20: In file included from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21: In file included from /System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20: In file included from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:129: In file included from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32: In file included from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:29: In file included from /usr/bin/../lib/clang/3.1/include/xmmintrin.h:985: /usr/bin/../lib/clang/3.1/include/emmintrin.h:1100:133: error: expected ')' _mm_set_epi8(char b15, char b14, char b13, char b12, char b11, char b10, char b9, char b8, char b7, char b6, char b5, char b4, char b3, char b2, char b1, char b0) ^ ../../../texk/web2c/texmfmem.h:171:13: note: expanded from macro 'b3' #define b3 u.B3 ^ /usr/bin/../lib/clang/3.1/include/emmintrin.h:1100:13: note: to match this '(' _mm_set_epi8(char b15, char b14, char b13, char b12, char b11, char b10, char b9, char b8, char b7, char b6, char b5, char b4, char b3, char b2, char b1, char b0) ^ /usr/bin/../lib/clang/3.1/include/emmintrin.h:1102:30: error: member reference base type 'char' is not a structure or union return (__m128i)(__v16qi){ b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, b10, b11, b12, b13, b14, b15 }; ^~ ../../../texk/web2c/texmfmem.h:168:14: note: expanded from macro 'b0' #define b0 u.B0 ~ ^ One of the main developers of TeX Live argued with the following: > the corresponding code in > /usr/lib/gcc/ix86-linux-gnu/4.7.2/include/emmintrin.h:597ff > reads > > extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, > __artificial__)) > _mm_set_epi8 (char __q15, char __q14, char __q13, char __q12, > char __q11, char __q10, char __q09, char __q08, > char __q07, char __q06, char __q05, char __q04, > char __q03, char __q02, char __q01, char __q00) > { > return __extension__ (__m128i)(__v16qi){ > __q00, __q01, __q02, __q03, __q04, __q05, __q06, __q07, > __q08, __q09, __q10, __q11, __q12, __q13, __q14, __q15 > }; > > and I'd say that clang must not usurpate user space variables such as b0, > b1, b2, etc. It is certainly legitimate to #define them to whatever is > useful for the user code. So this is a bug in clang! > > Regards > Peter 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?) Mojca _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
