cairo: static libs fail to build correctly with llvm

[matuzalem@…]

Cairo fails to compile:

libcairo.la fails to build with error no debug symbols in executable (-arch x86_64)

ranlib: archive: .libs/libcairo.a can't determine the byte order of table of contents (contains no Mach-O files)

10.7 Developer Preview 4
gcc version: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1

[matuzalem@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

I don't have Lion so I can't really help with this right now.

[jmroot (Joshua Root)]

If you build with configure.compiler=llvm-gcc-4.2 on 10.6 you can see that the .o files are llvm bitcode, not mach-o, so the static libs aren't correctly built. Turning off use of -flto fixes this. See attachments.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #30135.

[nerdling (Jeremy Lavergne)]

Just to clarify: does this actually produce an error during the MacPorts build phase or is it a bad resulting file?

[ryandesign (Ryan Carsten Schmidt)]

Using "sudo port install cairo configure.compiler=llvm-gcc-4.2" on Snow Leopard with Xcode 3.2.6, if I don't use the universal variant, it installs successfully but the created static libraries are not Mach-O files and are thus unusable; if I install with the universal variant, it fails after the destroot phase when lipo is unable to merge the static libraries because they are not Mach-O files (see #30135). According to the description of this ticket, the build fails on Lion, even when not using the universal variant, but I have not confirmed that.

[jeremyhu (Jeremy Huddleston Sequoia)]

The TOC issue should be fixed in a later version of the devtools.

ld64 understands llvm bitcode.

[matthew.a.shapiro@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Later than what? Is this still an issue for Lion 10.7 GM? What about for Xcode 4 on Snow Leopard?

[matthew.a.shapiro@…]

Under Lion GM + Xcode 4, cairo still fails to build.

[cdavis@…]

The problem as I understood it is that some of the cctools (e.g. lipo, libtool) don't understand LLVM bitcode. Specifically, they don't know how to determine the architecture of a bitcode file.

So lipo, and anything that uses it to read/write fat Mach-O and archive files, are all useless right now for dealing with LLVM bitcode objects, as well as archives composed entirely of bitcode objects. Same for libtool. I filed radar 9087924 for this; so far, I haven't gotten a response.

[rmstonecipher@…]

Ryan Schmidt,
Josh's patches allow cairo to be built +universal on Lion.
If they are an acceptable solution, could commit them?

Ryan Stonecipher

[ejtttje@…]

I concur, needed this patch to build for Lion, but also needed #30351 in order to build +quartz variant under 32-bit (i.e. +universal)

[jeremyhu (Jeremy Huddleston Sequoia)]

The use of lipo(1) on static libraries will not generally work as they will need to have their table of contents updated with respect to the time stamp of the newly created fat file. libtool(1) is the recommended way to properly create a fat archive. As libtool(1) will do what ever it takes to place the objects from the input in their proper place in the output (things like taking fat .o files out of thin archives, etc). So in this case the recommended way to make the output is:

/Developer/usr/bin/libtool i386.a x86_64.a -o cairo.a

The problem is in muniversal trying to do this with lipo.

[jeremyhu (Jeremy Huddleston Sequoia)]

@cdavis, what problem are you seeing with libtool? It should work fine.

[jeremyhu (Jeremy Huddleston Sequoia)]

Try the attached patch for muniversal. I haven't tested it, but it should work (modulo any syntax errors I may have inadvertently made)

[ryandesign (Ryan Carsten Schmidt)]

I committed the initial patch for cairo in r81083 and cairo-devel in r81084 before realizing new comments had appeared in this ticket.

Replying to jeremyhu@…:

The problem is in muniversal trying to do this with lipo.

Hmm, that's news to me. lipo always seemed to work before.

Replying to jeremyhu@…:

Try the attached patch for muniversal. I haven't tested it, but it should work (modulo any syntax errors I may have inadvertently made)

"/usr/bin/lipbtool" is presumably one typo.

If libtool is the correct tool to use now, why are we still trying with lipo first then? Why not just always use libtool?

[michelle.lynn.gill@…]

If it's of any help, I was able to build cairo @1.10.2_3 +opengl+x11 on MacPorts 2.0 using Mac OS X 10.7, Xcode 4.1, and mp-gcc44. I don't see any log files since it was a clean build, but I'm happy to provide them if someone will direct me.

[michelle.lynn.gill@…]

Cc Me!

[michelle.lynn.gill@…]

Cc Me!

[michelle.lynn.gill@…]

Cc Me!

[nerdling (Jeremy Lavergne)]

Logs aren't kept after a clean install by default. You'll need to build again to get logs; consider turn on keep_logs in macports.conf.

[ejtttje@…]

Is anyone seeing issues with PS or PDF generation from Cairo under Lion? I am, and ​this discussion page suggests it might be related to building with llvm. Unfortunately, configure.compiler=gcc-4.2 does not seem to fix the issue (so maybe I am subverting this bug report, but just want to check, we can fork to a new bug if needed)

What I can say is that no matter what I do with my cairo pdf surface calls, it consistently generates a 414 byte file with what look like PDF headers and footer, but no content. Further, Preview and Adobe Reader complain about an invalid file (Preview says it "can't be opened" and that it is damaged or unknown format, whereas Reader complains it "has no pages"). If I restrict the cairo version to 1.4, I see it does change the version number in the header, but that's the only diff. I have also tried cairo-devel, same issue. I'll attach a sample in case it is helpful.

[ejtttje@…]

Cairo doesn't seem to be producing valid PDF output anymore... llvm issue or not?

[jeremyhu (Jeremy Huddleston Sequoia)]

muniversal patch (untested)

[jeremyhu (Jeremy Huddleston Sequoia)]

ejtttje: please file a new bug report for your PS/PDF issue. This ticket is specifically about the build issue relating to LLVM Bitcode and muniversal.

[jeremyhu (Jeremy Huddleston Sequoia)]

r81091 ... I tested it with llvm-gcc-4.2 without ryan's r81083 change.

Leaving open for ryan to revert the -flto stripping in a future cairo if he wishes.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to ryandesign@…:

If libtool is the correct tool to use now, why are we still trying with lipo first then? Why not just always use libtool?

because libtool is correct for ar archives, lipo is correct for Mach-O ... lipo will work for most cases, so doing it first.

[ejtttje@…]

I tracked down the PDF problem as an llvm issue with libpixman... I've started a new ticket for it #30370.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

Leaving open for ryan to revert the -flto stripping in a future cairo if he wishes.

r81113