From patchwork Fri May 23 02:23:16 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans-Peter Nilsson X-Patchwork-Id: 351693 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4A466140082 for ; Fri, 23 May 2014 12:23:47 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; q=dns; s=default; b=fVNTgs4AlYrVmMd8 rw7bXmKTIS545FxFx/OgDnAQjts71+LJY47uAW5vtIfzMReWODhwIl7Wf+DNNBvW FQKx2ahvKB1MIvrpngLBsSEV2nsIm/pSsJY5zM5Xld0lhw3naLqqNhSmNXh0gwDW 4q6x63W/GAhRSs4GzElrxX3XCqg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=default; bh=n62AWFOg1TUy6nV2fVdKUF wojQE=; b=X9n9bsp/GxGZ2sCfScruyo26lej8han3+VE9oyKlXdh/+jcHp7NfIr o67KXlR5XQZE9ll6mcK5rw1CyCTj5qtvOD2JVaDRNw8aIZ/Vzg3Wnhtqqbz4yVpr 9X3giq8gCWKVaERadt5de6F9VwxqCRJYCI6BE0dqo+gKcxcROgSb0= Received: (qmail 31418 invoked by alias); 23 May 2014 02:23:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 31387 invoked by uid 89); 23 May 2014 02:23:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 X-HELO: arjuna.pair.com Received: from arjuna.pair.com (HELO arjuna.pair.com) (209.68.5.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Fri, 23 May 2014 02:23:18 +0000 Received: (qmail 91659 invoked by uid 3006); 23 May 2014 02:23:16 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 23 May 2014 02:23:16 -0000 Date: Thu, 22 May 2014 22:23:16 -0400 (EDT) From: Hans-Peter Nilsson To: Janne Blomqvist cc: Fortran List , GCC Patches Subject: Re: Breakage with [PATCH, libgfortran] PR60324 Handle arbitrarily long path names In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (BSF 1266 2009-07-14) MIME-Version: 1.0 X-IsSubscribed: yes On Fri, 23 May 2014, Janne Blomqvist wrote: > On Thu, May 22, 2014 at 6:36 PM, Hans-Peter Nilsson wrote: > > This patch broke build for newlib targets; you need AC_DEFINE > > clauses for those in the "if-then"-leg where you patched the > > "else"-leg. > > Do I? The way that configure-clause is written, that's obviously the intended means. > The patch does include fallback implementations for strnlen and > strndup in case the target doesn't supply them. The target *does* supply them, but the configuration machinery doesn't (can't) look, as linking may not (yet) be possible. > I don't know whether > newlib does, or if current versions do have it but old still in use > versions don't etc. Both are in newlib since 2002 (two years before the release of the required minimum host-gcc-version), no need to add such complexity. > I suggest that whoever was insisting on this > stupid hard-coded func list for newlib takes care of figuring that out > and, if it turns out that all relevant newlib versions do supply one > or both of those functions, posts a patch. I'm not defending the existing solution, I was observing your patch breaking it. The obvious fix is adjustments by means of this existing machinery; done. I suggest breakages be fixed without shooting messengers or requiring jumping through even stupider hoops in order to fix an obvious immediate breakage. If you take issue with that machinery, that's a separate issue which shouldn't be holding up fixing a breakage. > Or hmm, is there some symbol name conflict, in case we try to use a > fallback implementation but the target already defines it? Exactly. The declaration was clashing with that included from string.h. Committed as obvious knowing the cause and the effect and the prerequisites, after observing build passing the point of failure for cris-elf. * configure.ac [with_newlib] (HAVE_STRNLEN, HAVE_STRNDUP): Define. * configure: Regenerate. brgds, H-P Index: libgfortran/configure.ac =================================================================== --- libgfortran/configure.ac (revision 210821) +++ libgfortran/configure.ac (working copy) @@ -273,6 +273,8 @@ if test "x${with_newlib}" = "xyes"; then AC_DEFINE(HAVE_VSNPRINTF, 1, [Define if you have vsnprintf.]) AC_DEFINE(HAVE_LOCALTIME_R, 1, [Define if you have localtime_r.]) AC_DEFINE(HAVE_GMTIME_R, 1, [Define if you have gmtime_r.]) + AC_DEFINE(HAVE_STRNLEN, 1, [Define if you have strnlen.]) + AC_DEFINE(HAVE_STRNDUP, 1, [Define if you have strndup.]) # At some point, we should differentiate between architectures # like x86, which have long double versions, and alpha/powerpc/etc.,