Bug 44584

Summary:	Build fails with Apple's llvm-gcc-4.2
Product:	cairo	Reporter:	John Ralls <jralls>
Component:	general	Assignee:	Carl Worth <cworth>
Status:	RESOLVED FIXED	QA Contact:	cairo-bugs mailing list <cairo-bugs>
Severity:	normal
Priority:	medium
Version:	1.10.3
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	Conditionally add the -flto flag only if $CC != llvm-gcc-4.2 Config.log (without the patch)

Description John Ralls 2012-01-08 11:03:26 UTC

llvm-gcc-4.2 will fail to build cairo with the error message

"ld: lto: could not merge in .libs/cairo-analysis-surface.o because Unknown instruction for architecture i386"

This is caused by the '-flto' CFLAG telling llvm to produce bitcode instead of mach-o object files, but llvm under libtool will not link its bitcode files. 

Note that as of Xcode 4.2 Apple is no longer distributing gcc, so using llvm is necessary to build on the most recent releases of OSX.

Comment 1 John Ralls 2012-01-08 11:07:55 UTC

Created attachment 55304 [details] [review]
Conditionally add the -flto flag only if $CC != llvm-gcc-4.2

Comment 2 Andrea Canciani 2012-01-09 03:39:47 UTC

(In reply to comment #0)
> llvm-gcc-4.2 will fail to build cairo with the error message
> 
> "ld: lto: could not merge in .libs/cairo-analysis-surface.o because Unknown
> instruction for architecture i386"

Can you provide the environment you're using and/or the config.log?

In my environment configure correctly detects that -flto does not result in a usable binary:
http://ranma42.dyndns.info:8010/builders/full-macosx/builds/30/steps/configure/logs/stdio

> 
> This is caused by the '-flto' CFLAG telling llvm to produce bitcode instead of
> mach-o object files, but llvm under libtool will not link its bitcode files. 

The configure script should automatically detect if the -flto flag works.

> 
> Note that as of Xcode 4.2 Apple is no longer distributing gcc, so using llvm is
> necessary to build on the most recent releases of OSX.

Comment 3 John Ralls 2012-01-09 08:13:19 UTC

From *your* config file: 
>checking for gcc... gcc

What part of "llvm-gcc-4.2" do you not understand?

Comment 4 John Ralls 2012-01-09 08:21:50 UTC

Created attachment 55339 [details]
Config.log (without the patch)

Build environment is Gtk-OSX, with the following settings:
CPLUS_INCLUDE_PATH=/Users/john/Documents/Lion/gtk-unstable-3/inst/include
GCONF_DEFAULT_SOURCE_PATH=/Users/john/Documents/Lion/gtk-unstable-3/inst/etc/gconf/2/path.jhbuild
JHBUILD_PREFIX=/Users/john/Documents/Lion/gtk-unstable-3/inst
LDFLAGS=-L/Users/john/Documents/Lion/gtk-unstable-3/inst/lib -L/Users/john/Documents/Lion/gtk-unstable-3/inst/lib -arch i386 -L/Developer/SDKs/MacOSX10.7.sdk/usr/lib -isysroot /Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.4 -Wl,-headerpad_max_install_names
MANPATH=/Users/john/Documents/Lion/gtk-unstable-3/inst/share/man::/usr/man:/usr/share/man:/usr/local/man:/usr/local/share/man
TERM_PROGRAM=iTerm.app
DYLD_FALLBACK_LIBRARY_PATH=/Users/john/Documents/Lion/gtk-unstable-3/inst/lib
UNMANGLED_PATH=/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/Users/john/.local/bin
SHELL=/bin/bash
TERM=xterm-xi
CPPFLAGS=-I/Users/john/Documents/Lion/gtk-unstable-3/inst/include -I/Developer/SDKs/MacOSX10.7.sdk/usr/include
TMPDIR=/var/folders/9y/7rxkyjb151b587912dmzrl2h0000gn/T/
PERL5LIB=/Users/john/Documents/Lion/gtk-unstable-3/inst/lib/perl5/site_perl:/Users/john/Documents/Lion/gtk-unstable-3/inst/lib/perl5/vendor_perl:/Users/john/Documents/Lion/gtk-unstable-3/inst/lib/perl5
Apple_PubSub_Socket_Render=/tmp/launch-UenDke/Render
PATHSET=TRUE
BUILDCFLAGS=-arch i386 -I/Developer/SDKs/MacOSX10.7.sdk/usr/include -isysroot /Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.4
USER=john
LD_LIBRARY_PATH=/Users/john/Documents/Lion/gtk-unstable-3/inst/lib
COMMAND_MODE=unix2003
LD_TWOLEVEL_NAMESPACE=1
SSH_AUTH_SOCK=/tmp/launch-qVC494/Listeners
Apple_Ubiquity_Message=/tmp/launch-V9nvSK/Apple_Ubiquity_Message
__CF_USER_TEXT_ENCODING=0x1F5:0:0
CXXFLAGS=-O2 -arch i386 -I/Developer/SDKs/MacOSX10.7.sdk/usr/include -isysroot /Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.4
XDG_CONFIG_DIRS=/Users/john/Documents/Lion/gtk-unstable-3/inst/etc/xdg
PATH=/Users/john/Documents/Lion/gtk-unstable-3/inst/bin:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/Users/john/.local/bin
JHBUILD=unstable-3
CERTIFIED_GNOMIE=yes
XML_CATALOG_FILES=/Users/john/Documents/Lion/gtk-unstable-3/inst/etc/xml/catalog
VERSIONER_PYTHON_VERSION=2.7
C_INCLUDE_PATH=/Users/john/Documents/Lion/gtk-unstable-3/inst/include
CUPS_CONFIG=/Developer/SDKs/MacOSX10.7.sdk/usr/bin/cups-config
BUILD=unstable-3
PWD=/Users/john/Documents/Lion/gtk-unstable-3/src/cairo
LTDL_LIBRARY_PATH=/Users/john/Documents/Lion/gtk-unstable-3/inst/lib
EDITOR=pico
LANG=en_US.UTF-8
ITERM_PROFILE=Manjusri
MONO_GAC_PREFIX=/Users/john/Documents/Lion/gtk-unstable-3/inst
GCONF_SCHEMA_INSTALL_SOURCE=xml:merged:/Users/john/Documents/Lion/gtk-unstable-3/inst/etc/gconf/gconf.xml.defaults
XCURSOR_PATH=/Users/john/Documents/Lion/gtk-unstable-3/inst/share/icons
VERSIONER_PERL_PREFER_32_BIT=yes
UNMANGLED_LD_LIBRARY_PATH=
CXX=/usr/bin/llvm-g++-4.2
MONO_PREFIX=/Users/john/Documents/Lion/gtk-unstable-3/inst
HOME=/Users/john
SHLVL=2
CFLAGS=-O2 -arch i386 -I/Developer/SDKs/MacOSX10.7.sdk/usr/include -isysroot /Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.4
INSTALL=/Users/john/.local/bin/install-check
ITERM_SESSION_ID=w0t1p0
PYTHONPATH=/Users/john/Documents/Lion/gtk-unstable-3/inst/lib/python2.7:/Users/john/Documents/Lion/gtk-unstable-3/inst/lib/python2.7/site-packages/gtk-2.0:/Users/john/Documents/Lion/gtk-unstable-3/inst/lib/python2.7/site-packages
MACOSX_DEPLOYMENT_TARGET=10.4
LOGNAME=john
PREFIX=/Users/john/Documents/Lion/gtk-unstable-3/inst
CVS_RSH=ssh
VISUAL=pico
UNDER_JHBUILD=true
ACLOCAL_FLAGS=-I /Users/john/Documents/Lion/gtk-unstable-3/inst/share/aclocal -I /usr/share/aclocal
XDG_DATA_DIRS=/Users/john/Documents/Lion/gtk-unstable-3/inst/share
VERSIONER_PYTHON_PREFER_32_BIT=yes
PKG_CONFIG_PATH=/Users/john/Documents/Lion/gtk-unstable-3/inst/lib/pkgconfig:/Users/john/Documents/Lion/gtk-unstable-3/inst/share/pkgconfig:/usr/lib/pkgconfig
JHBUILD_PROMPT=[JH] 
PROMPT_COMMAND=prompt_command
ARCHFLAGS=-arch i386 -arch x86_64
INFOPATH=/usr/local/info:/usr/share/info/:/usr/local/share/info
GI_TYPELIB_PATH=/Users/john/Documents/Lion/gtk-unstable-3/inst/lib/girepository-1.0
CC=/usr/bin/llvm-gcc-4.2
DISPLAY=/tmp/launch-iqfhYt/org.x:0
JHBUILD_SOURCE=/Users/john/Documents/Lion/gtk-unstable-3/src
_=/usr/bin/env

Comment 5 John Ralls 2012-01-09 08:37:15 UTC

The obvious difference between configure's ac_fn_c_try_link test (which passes) and the library linkage (which fails) is that the latter is called with -dynamiclib and the former isn't.

Comment 6 Andrea Canciani 2012-01-09 08:41:20 UTC

(In reply to comment #3)
> From *your* config file: 
> >checking for gcc... gcc

And from *my* shell (and probably yours, too):

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'm using the default compiler with XCode 4.2.1.

> 
> What part of "llvm-gcc-4.2" do you not understand?

I'm already using llvm-gcc-4.2, but through the standard alias "gcc" (as provided by Xcode).
This also shows that your patch does not actually solve the issue.

(In reply to comment #4)
> Created attachment 55339 [details]
> Config.log (without the patch)

I think I found why I did not hit this bug.
My CFLAGS are the default ones, hence they include -g.
It looks like:

gcc -o conftest -O2  -Werror -flto conftest.c

completes successfully, while

$ gcc -o conftest -g -O2  -Werror -flto conftest.c
ld: in /var/folders/p2/lbn1bct52bq_1krlrp544t_c0000gn/T//ccHfXUes.o, could not parse object file /var/folders/p2/lbn1bct52bq_1krlrp544t_c0000gn/T//ccHfXUes.o: Malformed metadata record for architecture x86_64

(In reply to comment #5)
> The obvious difference between configure's ac_fn_c_try_link test (which passes)
> and the library linkage (which fails) is that the latter is called with
> -dynamiclib and the former isn't.

Then this is probably the correct thing to patch.

Comment 7 John Ralls 2012-01-09 09:36:32 UTC

FWIW, it fails on x86_64, too:
ld: lto: could not merge in .libs/cairo-analysis-surface.o because Unknown instruction for architecture x86_64

Comment 8 John Ralls 2012-01-09 12:26:12 UTC

(In reply to comment #6)
> I think I found why I did not hit this bug.
> My CFLAGS are the default ones, hence they include -g.
> It looks like:
> 
> gcc -o conftest -O2  -Werror -flto conftest.c
> 
> completes successfully, while
> 
> $ gcc -o conftest -g -O2  -Werror -flto conftest.c
> ld: in /var/folders/p2/lbn1bct52bq_1krlrp544t_c0000gn/T//ccHfXUes.o, could not
> parse object file /var/folders/p2/lbn1bct52bq_1krlrp544t_c0000gn/T//ccHfXUes.o:
> Malformed metadata record for architecture x86_64

Yes, if I pass a debug flag (-ggdb3 in this case) the flto link in configure fails for me as well.

> 
> (In reply to comment #5)
> > The obvious difference between configure's ac_fn_c_try_link test (which passes)
> > and the library linkage (which fails) is that the latter is called with
> > -dynamiclib and the former isn't.
> 
> Then this is probably the correct thing to patch.

So add it to the CFLAGS in CAIRO_CC_TRY_LINK_WITH_ENV_SILENT -- or perhaps where it's called at CAIRO_CC_FLAG_SILENT?

Comment 9 John Ralls 2013-06-21 14:29:33 UTC

Recent versions of Cairo don't have this problem, so closing as fixed.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.