From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100924 invoked by alias); 19 May 2017 13:43:09 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 100908 invoked by uid 89); 19 May 2017 13:43:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=Hx-languages-length:1154, telling X-HELO: mail-wr0-f180.google.com Received: from mail-wr0-f180.google.com (HELO mail-wr0-f180.google.com) (209.85.128.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 May 2017 13:43:07 +0000 Received: by mail-wr0-f180.google.com with SMTP id z52so17668967wrc.2 for ; Fri, 19 May 2017 06:43:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ERCCdksL++MqzQf8YLU9T4WYwquZ45jJcq6cjgPIkmE=; b=prShIf/LB+Qz0kfAtdbMGMNQMkQpuwyJXNObgORxo3TzpKuLdieTK9tGJtTBoIN006 AIo3R6gEVSA+feiZ14VLw5Ryx49yH/bSk30pF/0SVcjBLOU4b1sxDUQFTTcCnYf1M6d4 /m+QllCWyq/nfIPfM55xAWtQSI7wKz3o8g+uxGH4TDlSji3jm6AtXgcQgIqhBIjUUr8i hUa6bBhAkS3ZY2YNdPR6K7YaKJ1l21OfUD9x/imSYUT/o0ebqbhFj537k120kdReUsLC xcMCGSVruGlSzxpR14FxG8dVxXFpFQgsg3eOGS4kBHuLC+u1aQadLEhDD38qbjeRR054 nsjQ== X-Gm-Message-State: AODbwcAMMZ3o7zjKo6ACiURFssMPQiOsb94FDvX4ysnogAnG1BA54rnZ RSEFMh9pe5wZVOMg X-Received: by 10.223.163.91 with SMTP id d27mr3876328wrb.27.1495201389110; Fri, 19 May 2017 06:43:09 -0700 (PDT) Received: from [192.168.0.102] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id n27sm1234165wra.57.2017.05.19.06.43.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 May 2017 06:43:08 -0700 (PDT) Subject: Re: Fix tui compilation with Solaris libcurses (PR tui/21482) To: Rainer Orth , Eli Zaretskii References: <32521e83-00b5-e2a8-faff-03b5407cfc67@redhat.com> <83h90h2dbu.fsf@gnu.org> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <14c55a75-c08a-5abc-74df-f59277d7061f@redhat.com> Date: Fri, 19 May 2017 13:43:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00445.txt.bz2 On 05/19/2017 02:26 PM, Rainer Orth wrote: > Hi Eli, > >>> I've checked in the cast part now. Here's the NOMACROS part for >>> gdb_curses.h. Tested as before on sparcv9-sun-solaris2.10 (curses) and >>> amd64-pc-solaris2.12 (ncurses). Ok too? >> >> I think this should be guarded by some OS-specific macro, so as not to >> affect other platforms, where the original problem doesn't exist. (I >> see 6 instances of these macros being tested in my ncurses headers, >> and I'm not on Solaris.) Who knows what new problems this could cause? > > that's what I had done initially (via configure.ac for solaris2.* only), > but Pedro suggested to do it unconditionally since some other targets > (AIX notably) seem to be having the same problem. Yes, and it's not host specific, but really curses-implementation specific. On the same host you may compile against different versions of curses (BSD curses, ncurses, pdcurses, etc.). I don't see any benefit to complicate things when we have no evidence that telling curses to avoid defining its symbols as macros causes problems. Thanks, Pedro Alves