Opened 10 years ago

Closed 10 years ago

#30370 closed defect (fixed)

libpixman erroneous execution with llvm-gcc-4.2

Reported by: ejtttje@… Owned by: ryandesign (Ryan Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.0.0
Keywords: lion llvm-gcc-4.2 cairo pdf Cc: nerdling (Jeremy Lavergne), ejtttje@…, eborisch (Eric A. Borisch), soehn@…, jeremyhu (Jeremy Huddleston Sequoia), a.y.harano@…, frank@…, kristian@…
Port: libpixman

Description

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)

Attachments (4)

main.log (13.2 KB) - added by eborisch (Eric A. Borisch) 10 years ago.
Broken build with clang on SL. Log is from issuing build again, so it skips most of the "working" portion.
build-full.log (48.6 KB) - added by eborisch (Eric A. Borisch) 10 years ago.
Without ccache. Shows from fetch to failure.
build-short.log (10.5 KB) - added by eborisch (Eric A. Borisch) 10 years ago.
Without ccache; Log from issuing 'port build' again after initial failure.
build-full-serial.log (47.9 KB) - added by eborisch (Eric A. Borisch) 10 years ago.
Same as build-full.log, but with serial make.

Download all attachments as: .zip

Change History (27)

comment:1 Changed 10 years ago by ryandesign (Ryan Schmidt)

Owner: changed from macports-tickets@… to ryandesign@…

comment:2 in reply to:  description Changed 10 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: newclosed

Replying to ejtttje@…:

Please set libpixman's configure.compiler=clang

r81114

comment:3 Changed 10 years ago by eborisch (Eric A. Borisch)

Resolution: fixed
Status: closedreopened

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?

Changed 10 years ago by eborisch (Eric A. Borisch)

Attachment: main.log added

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

comment:4 Changed 10 years ago by jmroot (Joshua Root)

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

comment:5 Changed 10 years ago by 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 :)

comment:6 Changed 10 years ago by ejtttje@…

Cc: ejtttje@… added

Cc Me!

comment:7 Changed 10 years ago by eborisch (Eric A. Borisch)

Cc: eborisch@… added

Cc Me!

comment:8 Changed 10 years ago by soehn@…

Cc: soehn@… added

Cc Me!

comment:9 Changed 10 years ago by 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.

comment:10 Changed 10 years ago by 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?)

comment:11 Changed 10 years ago by jmroot (Joshua Root)

Cc: jeremyhu@… added

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.

comment:12 Changed 10 years ago by 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.

comment:13 Changed 10 years ago by 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.

comment:14 Changed 10 years ago by 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".

comment:15 Changed 10 years ago by eborisch (Eric A. Borisch)

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

comment:16 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Please report this as well:

xcodebuild -version
clang --version

comment:17 in reply to:  14 Changed 10 years ago by ryandesign (Ryan 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.

comment:18 Changed 10 years ago by 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.

Changed 10 years ago by eborisch (Eric A. Borisch)

Attachment: build-full.log added

Without ccache. Shows from fetch to failure.

Changed 10 years ago by eborisch (Eric A. Borisch)

Attachment: build-short.log added

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

comment:19 Changed 10 years ago by 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...)

Changed 10 years ago by eborisch (Eric A. Borisch)

Attachment: build-full-serial.log added

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

comment:20 Changed 10 years ago by a.y.harano@…

Cc: a.y.harano@… added

Cc Me!

comment:21 Changed 10 years ago by frank@…

Cc: frank@… added

Cc Me!

comment:22 Changed 10 years ago by kristian@…

Cc: kristian@… added

Cc Me!

comment:23 Changed 10 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: reopenedclosed

r81520, maintainer timeout

Note: See TracTickets for help on using tickets.