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.
Created attachment 55304 [details] [review] Conditionally add the -flto flag only if $CC != llvm-gcc-4.2
(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.
From *your* config file: >checking for gcc... gcc What part of "llvm-gcc-4.2" do you not understand?
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
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.
(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.
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
(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?
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.