Opened 10 years ago

Closed 9 years ago

#29842 closed defect (fixed)

cairo: static libs fail to build correctly with llvm

Reported by: matuzalem@… Owned by: ryandesign (Ryan Schmidt)
Priority: Normal Milestone:
Component: ports Version: 1.9.99
Keywords: lion Cc: shirocov@…, nerdling (Jeremy Lavergne), matthew.a.shapiro@…, michelle.lynn.gill@…
Port: cairo

Description (last modified by ryandesign (Ryan Schmidt))

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

Attachments (4)

Portfile.diff (634 bytes) - added by jmroot (Joshua Root) 10 years ago.
configure_disable_lto.diff (406 bytes) - added by jmroot (Joshua Root) 10 years ago.
bad_cairo_output.pdf (414 bytes) - added by ejtttje@… 9 years ago.
Cairo doesn't seem to be producing valid PDF output anymore... llvm issue or not?
muniversal.libtool.patch (1.5 KB) - added by jeremyhu (Jeremy Huddleston Sequoia) 9 years ago.
muniversal patch (untested)

Download all attachments as: .zip

Change History (32)

comment:1 Changed 10 years ago by matuzalem@…

Cc: matuzalem@… added

Cc Me!

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

Cc: matuzalem@… removed
Description: modified (diff)
Owner: changed from macports-tickets@… to ryandesign@…
Port: cairo added; Cairo removed
Summary: libcairo.la fails to build on Lion x68_64cairo: libcairo.la fails to build on Lion x68_64

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

Changed 10 years ago by jmroot (Joshua Root)

Attachment: Portfile.diff added

Changed 10 years ago by jmroot (Joshua Root)

Attachment: configure_disable_lto.diff added

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

Keywords: libcairo.la removed
Summary: cairo: libcairo.la fails to build on Lion x68_64cairo: static libs fail to build correctly with llvm

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.

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

Cc: shirocov@… added

Has duplicate #30135.

comment:5 Changed 10 years ago by nerdling (Jeremy Lavergne)

Cc: snc@… added

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

comment:6 Changed 10 years ago by ryandesign (Ryan 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.

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

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

ld64 understands llvm bitcode.

comment:8 Changed 10 years ago by matthew.a.shapiro@…

Cc: matthew.a.shapiro@… added

Cc Me!

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

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

comment:10 in reply to:  9 Changed 10 years ago by matthew.a.shapiro@…

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

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

comment:12 in reply to:  11 Changed 9 years ago by 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

comment:13 Changed 9 years ago by 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)

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

comment:15 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

comment:16 Changed 9 years ago by 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)

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

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

comment:19 Changed 9 years ago by michelle.lynn.gill@…

Cc: michelle.lynn.gill@… added

Cc Me!

comment:20 Changed 9 years ago by michelle.lynn.gill@…

Cc: michelle.lynn.gill@… removed

Cc Me!

comment:21 Changed 9 years ago by michelle.lynn.gill@…

Cc: michelle.lynn.gill@… added

Cc Me!

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

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

Changed 9 years ago by ejtttje@…

Attachment: bad_cairo_output.pdf added

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

Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Attachment: muniversal.libtool.patch added

muniversal patch (untested)

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

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

comment:26 in reply to:  17 Changed 9 years ago by 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.

comment:27 Changed 9 years ago by ejtttje@…

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

comment:28 in reply to:  25 Changed 9 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: newclosed

Replying to jeremyhu@…:

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

r81113

Note: See TracTickets for help on using tickets.