From libffi-discuss-return-1089-listarch-libffi-discuss=sources dot redhat dot com at sourceware dot org Fri Feb 04 20:36:10 2011 Return-Path: Delivered-To: listarch-libffi-discuss at sources dot redhat dot com Received: (qmail 24178 invoked by alias); 4 Feb 2011 20:36:10 -0000 Received: (qmail 23923 invoked by uid 22791); 4 Feb 2011 20:36:09 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_BF X-Spam-Check-By: sourceware.org Received: from dm-mail01.mozilla.org (HELO dm-mail01.mozilla.org) (63.245.208.150) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 Feb 2011 20:36:04 +0000 Received: from [10.240.2.241] (v74-nslb.mozilla.org [10.2.74.4]) (Authenticated sender: respindola@mozilla.com) by dm-mail01.mozilla.org (Postfix) with ESMTP id 947326A89D2 for ; Fri, 4 Feb 2011 12:35:12 -0800 (PST) Message-ID: <4D4C62FE.4070409@mozilla.com> Date: Fri, 04 Feb 2011 15:35:10 -0500 From: Rafael Avila de Espindola User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: libffi-discuss at sourceware dot org Subject: [patch] Check for libffi_cv_as_x86_pcrel should not look for just "warning" Content-Type: multipart/mixed; boundary="------------000904010404030601050307" X-IsSubscribed: yes Mailing-List: contact libffi-discuss-help at sourceware dot org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner at sourceware dot org Delivered-To: mailing list libffi-discuss at sourceware dot org This is a multi-part message in MIME format. --------------000904010404030601050307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The check that sets libffi_cv_as_x86_pcrel currently check for "warning" or "illegal". The problem is that when trying to build libffi with LTO clang will produce the warning clang: warning: argument unused during compilation: '-emit-llvm' The attached patch just uses the $CC error code instead. Is that OK or is there some strange assembler out there that rejects the assembly bug exists with 0? Cheers, Rafael --------------000904010404030601050307 Content-Type: text/x-patch; name="pcrel.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pcrel.patch" diff --git a/configure b/configure index e086c65..a1c5ec8 100755 --- a/configure +++ b/configure @@ -14506,10 +14506,10 @@ if test "${libffi_cv_as_x86_pcrel+set}" = set; then $as_echo_n "(cached) " >&6 else - libffi_cv_as_x86_pcrel=yes + libffi_cv_as_x86_pcrel=no echo '.text; foo: nop; .data; .long foo-.; .text' > conftest.s - if $CC $CFLAGS -c conftest.s 2>&1 | $EGREP -i 'illegal|warning' > /dev/null; then - libffi_cv_as_x86_pcrel=no + if $CC $CFLAGS -c conftest.s > /dev/null; then + libffi_cv_as_x86_pcrel=yes fi fi diff --git a/configure.ac b/configure.ac index c7cead8..c12c858 100644 --- a/configure.ac +++ b/configure.ac @@ -276,10 +276,10 @@ fi if test x$TARGET = xX86 || test x$TARGET = xX86_WIN32 || test x$TARGET = xX86_64; then AC_CACHE_CHECK([assembler supports pc related relocs], libffi_cv_as_x86_pcrel, [ - libffi_cv_as_x86_pcrel=yes + libffi_cv_as_x86_pcrel=no echo '.text; foo: nop; .data; .long foo-.; .text' > conftest.s - if $CC $CFLAGS -c conftest.s 2>&1 | $EGREP -i 'illegal|warning' > /dev/null; then - libffi_cv_as_x86_pcrel=no + if $CC $CFLAGS -c conftest.s > /dev/null; then + libffi_cv_as_x86_pcrel=yes fi ]) if test "x$libffi_cv_as_x86_pcrel" = xyes; then --------------000904010404030601050307--