From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94729 invoked by alias); 21 Feb 2017 14:47:46 -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 94692 invoked by uid 89); 21 Feb 2017 14:47:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=mishra.nitish.88@gmail.com, mishranitish88gmailcom, H*f:sk:hkjAH1-, H*i:sk:hkjAH1- X-HELO: mail-qk0-f193.google.com Received: from mail-qk0-f193.google.com (HELO mail-qk0-f193.google.com) (209.85.220.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Feb 2017 14:47:35 +0000 Received: by mail-qk0-f193.google.com with SMTP id n127so7657765qkf.2 for ; Tue, 21 Feb 2017 06:47:35 -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=5xwX+W2z7OEl4hvtL7BmV74nVFI7HwEZLsBAJeMyDVQ=; b=FSVbH83pFp2Jzz6LhaJMPil6DfT+cwPcKYTVuOQ+ww+VcLXuCpocs0Y9T5UFL3WEQE CvL+S6ex1hUdXdplo4BsbJWJkwuCTNpKon+zKWAwd7eEBiE4Re+0p46CH35JoTRKZ4fR aAuy44eMx7tVZ1Wgvp8wF09hcsNv7NSOlplN5DrPcVeXpcIve+0OrtGXYu15rTodyCML R2STAimlrmJigy2b7yRc2Qv1ZxxabDrrcCb7/GMRTZdsJNBm4v65kluDSplM7CDRVNt5 RY60Ha5okAp5juKQjMsQrebclvKv5B6jrRAe3/9t6r8ClL2e5DZO7+6mxjABO12CIwL4 PJjw== X-Gm-Message-State: AMke39ma/CjrUvVR7h6cLwwJMLamTOQTdZPL69SNEpLRjyfNcfglV8NRq+16KY4bSgc4tTikxDExLZGDf5x4wg== X-Received: by 10.55.66.68 with SMTP id p65mr15987589qka.187.1487688454026; Tue, 21 Feb 2017 06:47:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.181.202 with HTTP; Tue, 21 Feb 2017 06:47:33 -0800 (PST) In-Reply-To: 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: David Edelsohn Date: Tue, 21 Feb 2017 14:47:00 -0000 Message-ID: Subject: Re: Issue with Latest GDB on AIX with GCC-6.12 To: Nitish Kumar Mishra Cc: Pedro Alves , "gdb@sourceware.org" , Yao Qi Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-02/txt/msg00048.txt.bz2 Nitish, Patches should be sent to the gdb-patches mailing list with a new email thread. Please follow the format for email subject lines. configure is a generated file, so you must patch configure.ac and then be able to use the correct version of autoconf to regenerate the file. There already is a variable have_static_libs, so it may be more useful to re-use that variable than to create another one with much the same functionality. Thanks, David On Tue, Feb 21, 2017 at 12:00 AM, Nitish Kumar Mishra wrote: > Hi All ! > > The previous patch file has issues while patching. I mistakenly sent it. > I am attaching the updated one. > > Thanks and Regards > Nitish. > > On Mon, Feb 20, 2017 at 5:07 PM, Nitish Kumar Mishra > wrote: >> Hi All ! >> The proposed patch is tested on AIX-7.2 and Ubuntu-16.04 and it seems >> to be working fine. >> >> Thanks, >> Nitish. >> >> On Mon, Feb 20, 2017 at 4:55 PM, Nitish Kumar Mishra >> wrote: >>> Hi All ! >>> >>> Please find the patch attachment with this mail. >>> Any comments are more than welcome. >>> >>> Thanks, >>> Nitish >>> >>> On Mon, Feb 20, 2017 at 4:52 PM, Nitish Kumar Mishra >>> wrote: >>>> Hi All ! >>>> >>>> I have created a bug for this issue. The bug id is: 21187. >>>> I have created a patch for configure file in which new configure >>>> option --enable-staticlib and --disable-staticlib is implemented. >>>> By default the linking of GDB with libstdc++ and libgcc will be static. >>>> >>>> Attching the patch with the mail. >>>> >>>> On Mon, Feb 13, 2017 at 9:08 PM, Nitish Kumar Mishra >>>> wrote: >>>>> 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