From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-281447-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12457 invoked by alias); 19 Dec 2010 19:05:28 -0000
Received: (qmail 12441 invoked by uid 22791); 19 Dec 2010 19:05:28 -0000
X-SWARE-Spam-Status: No, hits=-1.8 required=5.0	tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE
X-Spam-Check-By: sourceware.org
Received: from mx02.qsc.de (HELO mx02.qsc.de) (213.148.130.14)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 19 Dec 2010 19:05:22 +0000
Received: from [192.168.178.22] (port-92-204-118-252.dynamic.qsc.de [92.204.118.252])	by mx02.qsc.de (Postfix) with ESMTP id 903BB1E937;	Sun, 19 Dec 2010 20:05:19 +0100 (CET)
Message-ID: <4D0E576F.4020809@net-b.de>
Date: Sun, 19 Dec 2010 19:37:00 -0000
From: Tobias Burnus <burnus@net-b.de>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.13) Gecko/20101206 SUSE/3.1.7 Thunderbird/3.1.7
MIME-Version: 1.0
To: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>,  gcc patches <gcc-patches@gcc.gnu.org>
Subject: Re: [Build, Patch, libquadmath] PR 46520   Do not call AC_CHECK_LIB for gcc_no_link
References: <4D0C8A2C.3080209@net-b.de> <20101219120803.GK7020@gmx.de> <4D0E306A.5090809@net-b.de> <20101219182826.GW7020@gmx.de>
In-Reply-To: <20101219182826.GW7020@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2010-12/txt/msg01545.txt.bz2

Ralf Wildenhues wrote:
> Well, this patch is ok as well (and a bit nicer for users willing
> to pass cache variables), but what I meant was something like
>
>    # The toplevel --target becomes the --host in target libdirs.
>    case $host_os in
>      linux*) ac_cv_lib_m_sqrtl=yes ;;
>      ...
>    esac
>
> that already seeds the variables on systems where the answer is known.
> (Kind of like another step further.)

Is it obvious that all linux* support sqrtl? I wouldn't rule out that 
there are Linux systems with double-only LIBC. Admittedly, I rather 
would expect those on, e.g., ARM systems where no __float128 exists.

I have now committed the second version of the patch (Rev. 168069). 
However, if we find something better, one can still commit it as 
follow-up patch.

Tobias