libpixman erroneous execution with llvm-gcc-4.2

[ejtttje@…]

When executing Cairo with PDF output, the resulting PDFs are always 414 bytes, just the PDF header and footer with no content. I have tracked this down to a compilation issue in libpixman: when this lib is compiled with clang or gcc-4.2, then Cairo will work properly, but if libpixman uses the now-default llvm-gcc-4.2, then it somehow breaks Cairo.

Please set libpixman's configure.compiler=clang

(This was originally reported with other llvm issue for Cairo in #29842)

[ryandesign (Ryan Carsten Schmidt)]

Replying to ejtttje@…:

Please set libpixman's configure.compiler=clang

r81114

[eborisch (Eric A. Borisch)]

This fix breaks the universal build on Snow Leopard. (Log attached.)

Perhaps change to gcc-4.2 (builds universal successfully) on Snow Leopard and clang on Lion?

[eborisch (Eric A. Borisch)]

Broken build with clang on SL. Log is from issuing build again, so it skips most of the "working" portion.

[jmroot (Joshua Root)]

Actually it's specifically the i386 build. Could be bad inline asm?

[ejtttje@…]

Yes, libpixman does do some asm, which is the root cause of the issue... must be making some assumptions about how the compiler is going to emit code, and is noted as a source of issues when moving to llvm. Older versions of clang have additional parsing bugs, some of which I ran into in my own code (and to their credit, the clang team was responsive to my bug reports and I moved pretty easily to svn checkout of clang to use their fixes.)

So, really MacPorts should do a version test on the compiler to make the selection: users could have retained an old Xcode 3 install through a Lion upgrade, or inversely, be on Snow Leopard but updated the clang install like I did. So it would be more robust to base the selection on the available clang version instead of the OS version. For reference:

• a semi-recent manual build from llvm/clang svn reports --version "clang version 3.0 (trunk 129294)"
• the Xcode 4.1 version reports as "Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn)"
• Xcode 4.0 was "based on LLVM 2.9svn"

I'd suggest requiring clang>=3.0 in order to be robust. But more practically, don't worry about it and just fall back to gcc-4.2 for everyone for now :)

[ejtttje@…]

Cc Me!

[eborisch (Eric A. Borisch)]

Cc Me!

[soehn@…]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

I'd recommend using clang (period) instead of llvm-gcc-4.2. XCode 4.1's clang works fine. Do you have a specific failure you are seeing with clang in XCode 4.0? I believe it should be fine as well.

[ejtttje@…]

I think we all agree that llvm-gcc-4.2 is failing.

The trick is that although Xcode 4.1's clang works, according to eborisch's log, clang fails on this port in Snow Leopard (could be Xcode 4.0 or 3... doesn't really matter). So then the only global fallback is gcc-4.2 (note non-llvm), unless someone wants to test for the actual clang version (and even then, what version works? Xcode 4.0? Current MacPorts? Some random svn revision in-between?)

[jmroot (Joshua Root)]

I reproduced eborisch's build failure with Xcode 3.2.6 and build_arch=i386. It's fine with x86_64 and may well be fine with Xcode 4.0.x.

[jmroot (Joshua Root)]

Although it wouldn't be using llvm-gcc-4.2 in the first place unless he was using Xcode 4, so I guess 4.0.x is also affected.

[eborisch (Eric A. Borisch)]

For the record, I have (and the failed build log I posted is from) 4.0.x (I'm not at that computer right now, so I don't want to commit on the .x ... I thought I was up-to-date as far as the App Store was concerned.) I'll record the definitive version # here in the morning.

I can also confirm that, similar to jmr's 3.2.6 results, on it builds fine for x86_64 (you can actually see that in the build log) -- only i386 failed.

[jeremyhu (Jeremy Huddleston Sequoia)]

I'm not saying we should use clang globally. I'm suggesting that we use clang if llvm-gcc-4.2 is the default compiler (ie: if we're on XCode 4.0.x). I suspect the issues with clang are stemming from XCode 3.2.6, but that version of XCode will be using gcc-4.2 anyways and won't be forced to use clang. Once they update to XCode4, they'll have a clang that will work, and pixman will be using it.

I'm highly suspicious of eborisch's build log, especially since it's using ccache. It looks like it's not doing something "normal".

[eborisch (Eric A. Borisch)]

I will re-run with ccache disabled and report back. As previously noted, the system is running Xcode4.

[jeremyhu (Jeremy Huddleston Sequoia)]

Please report this as well:

xcodebuild -version
clang --version

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

I'm suggesting that we use clang if llvm-gcc-4.2 is the default compiler (ie: if we're on XCode 4.0.x).

That is what the port does, as of r81114.

[eborisch (Eric A. Borisch)]

Still fails without ccache. Please let me know if there is anything else suspicious I can address.

MacPro:~$ xcodebuild -version Xcode 4.0.2 Build version 4A2002a

MacPro:~$ clang --version Apple clang version 2.0 (tags/Apple/clang-139) (based on LLVM 2.9svn) Target: x86_64-apple-darwin10 Thread model: posix

Logs will be attached.

[eborisch (Eric A. Borisch)]

Without ccache. Shows from fetch to failure.

[eborisch (Eric A. Borisch)]

Without ccache; Log from issuing 'port build' again after initial failure.

[eborisch (Eric A. Borisch)]

For the record, I'm running 10.6.8.

Building with parallel builds off (just in case - just another knob I could turn) did not change the result. I will attach the serial build log as well for good measure. (I find them easier to read than the parallel ones...)

[eborisch (Eric A. Borisch)]

Same as build-full.log, but with serial make.

[a.y.harano@…]

Cc Me!

[frank@…]

Cc Me!

[kristian@…]

Cc Me!

[jmroot (Joshua Root)]

r81520, maintainer timeout