From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72789 invoked by alias); 13 Feb 2017 15:38:42 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 72779 invoked by uid 89); 13 Feb 2017 15:38:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=eliz@gnu.org, U*eliz, elizgnuorg, bulls X-HELO: mail-yb0-f181.google.com Received: from mail-yb0-f181.google.com (HELO mail-yb0-f181.google.com) (209.85.213.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 13 Feb 2017 15:38:39 +0000 Received: by mail-yb0-f181.google.com with SMTP id w194so28089029ybe.0 for ; Mon, 13 Feb 2017 07:38:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qRuFKwqDzAkhNATkRV5L3I0fXEuCc+3H4i/JOJJX75Y=; b=PHBUvtWx3t3RkKyLMDJR+ZQjwPv9vU3zJwImTttIeAEWmDVbkh98l4WnBh2GHfB7jE ZBdCOC0YHK8WhaeOweMIN4Lh7GxPVfJhE0bFahkp8qiICeJAVTGTMQH7mVzmOr74B380 pPmgArNN/ruhFhljBvDzDVZTU6pyE421MCs+LNslny+nAlqIaqrkocNWw7Fgrzcm66qf GR21wSRNmkahlc31sMzMG4M8WyYsbV3afyHZMPZorgA8zfZ69IdCr36nX00mZ9v8Z93o kzq4FOeyS90duNRLJFtM6nZYqnZYe97Y+n+/GXZcGtTT19Db/x37ioz02D3Y9uLyNj6y Ad5A== X-Gm-Message-State: AMke39mLqpgPPpYFvDDwsSzBKTsACc1ANXKD8Hbl+7v0X0mNi2K1P2KUXbd5QzJ9WKTpNeiIlctNByaKBmJp0A== X-Received: by 10.37.244.11 with SMTP id q11mr16622969ybd.26.1487000318510; Mon, 13 Feb 2017 07:38:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.164.199 with HTTP; Mon, 13 Feb 2017 07:38:37 -0800 (PST) In-Reply-To: <83d1em15l7.fsf@gnu.org> References: <331a72d9-050c-7cd7-adc2-78e5f1ed6f85@redhat.com> <57147db4-83c3-2a8f-0c74-0efc6a94e9f5@redhat.com> <5967c781-4f67-06f2-db34-f4cb3818d603@palves.net> <83d1em15l7.fsf@gnu.org> From: Nitish Kumar Mishra Date: Mon, 13 Feb 2017 15:38:00 -0000 Message-ID: Subject: Re: Issue with Latest GDB on AIX with GCC-6.12 To: David Edelsohn Cc: pedro@palves.net, gdb@sourceware.org, Yao Qi Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00031.txt.bz2 Hi David ! >Who built GCC 6.1 for you? Is this an IBM build or Bull Freeware? IBM does not have GCC-6 build yet, and generally Bull's rpm breaks our environment. I took it from perzl.org. But now I have tested it with Bull's RPM, static linking still not working but removing --static-libstdc++ and --static-libgcc is working for me as well. Now, I will run the testsuite and will paste the result once it's finished. I disabled the static options manually. I don't see any configure option for disabling the static linking. I tried with one configure option --disable-libstdcxx, but I dont think it will lead to dynamic linking. Anyways, for me, using this option --disable-libstdcxx was giving compilation error, saying, "ld soes not support target". Thanks, Nitish On Mon, Feb 13, 2017 at 8:49 PM, Eli Zaretskii wrote: >> From: David Edelsohn >> Date: Mon, 13 Feb 2017 10:02:35 -0500 >> Cc: Nitish Kumar Mishra , "gdb@sourceware.org" , Yao Qi >> >> >> Can we disable -static-libgcc and -static-libstdc++ for AIX? >> > >> > Works for me. Those are added by the top level configure. They were >> > originally added for gcc, we just inherited it. Ideally adding >> > those would be controllable with a configure option, IMO. >> >> We shouldn't disable static-libgcc and static-libstdc++ for GCC. And >> static would be better. But linking GDB dynamically could be helpful >> as an interim work-around. > > Please let's not do that on MS-Windows at least. Dynamically linking > against these two libraries has the following 2 adverse effects: > > . it requires any site that distributes precompiled Windows binaries > of GDB to also distribute the full humongous tarball of GCC > sources (because libgcc runtime exception doesn't cover dynamic > linking against shared libraries); and > > . it opens the gates of the "DLL hell", since there's any number of > libgcc and libstdc++ DLLs from different versions of GCC floating > around on any given Windows system with GNU software, and there's > no practical way to ensure binary compatibility between the one > found first on PATH and a particular version of GDB one wants to > run