From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112718 invoked by alias); 19 Dec 2019 14:19:55 -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 112398 invoked by uid 89); 19 Dec 2019 14:19:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT autolearn=ham version=3.3.1 spammy=disaster, recipe, lowlevel, low-level X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (207.211.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Dec 2019 14:19:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576765192; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qGNHhiXv+vydQ8cD7qCq90XtY0MTMH8Mf+T+IeDgO6U=; b=ZUkc1cfg0xZUK20trPLmnm84H60k6ztqpxvhqXqOO4/UlO/FsSrMY1O4b4iBIw7pbqx6ql Lg5ap/MniKFncegNszzVb2m114IsxHkqfaMhFqVMd9EbEtDwV00DmhBvqfjXi79meUuAck jUuFmzsgVtVetMc8Kf6SYFMEESKMjz0= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-131-e-L4v9VTMZeGVy1tYqYJIQ-1; Thu, 19 Dec 2019 09:19:50 -0500 Received: by mail-ed1-f69.google.com with SMTP id d21so3589235edy.3 for ; Thu, 19 Dec 2019 06:19:50 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id d7sm376054edv.90.2019.12.19.06.19.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Dec 2019 06:19:47 -0800 (PST) Subject: Re: [PATCH] Link to -lssp when available (fixes mingw build) To: Christian Biesinger , Eli Zaretskii References: <20191218181413.128412-1-cbiesinger@google.com> <83h81x323k.fsf@gnu.org> <83fthh310d.fsf@gnu.org> <83eex12zj1.fsf@gnu.org> <83d0cl2yqd.fsf@gnu.org> <83bls52w6e.fsf@gnu.org> Cc: gdb-patches From: Pedro Alves Message-ID: <6f19911a-405e-77b5-e543-4fbb8ee80d8a@redhat.com> Date: Thu, 19 Dec 2019 14:19:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-12/txt/msg00814.txt.bz2 On 12/18/19 11:23 PM, Christian Biesinger via gdb-patches wrote: > On Wed, Dec 18, 2019 at 5:12 PM Eli Zaretskii wrote: >> >>> From: "Christian Biesinger via gdb-patches" >>> Date: Wed, 18 Dec 2019 14:40:42 -0600 >>> Cc: gdb-patches a lot of >>> >>> BTW -- you mentioned a licensing issue with depending on DLLs. Doesn't >>> libstdc++ and perhaps others have the same issue? Or does mingw.org >>> link it statically? >> >> libstdc++ and libgcc DLLs indeed have the same problem. Which is why >> I mentioned the fact that the binary of GDB 9.0.90 produced by the >> MinGW build had dependencies on these two. I solved that locally by >> linking with "CXX='g++ -static-libstdc++ -static-libgcc'", but I >> thought Pedro once said these dependencies shouldn't happen, and I >> still hope we could understand why they suddenly appeared. > > Hm, I wonder why Pedro said that. GDB uses good amounts of the C++ > standard library, so I would totally expect libstdc++ to appear. There's some confusion going on here. We must certainly link with libstdc++ somehow. The only question is whether we link to the dynamic or static version. What I've said in the past is that GDB inherited the -static-libstdc++ and -static-libgcc from GCC, due to the shared top level configure: https://sourceware.org/ml/gdb-patches/2019-07/msg00040.html Linking with static versions of the runtime is problematic if we also link with some other library that is itself linked with a different libstdc++. Multiple versions of libstc++/libgcc in a program is a recipe for disaster, such as for example C++ exceptions not working properly. Discussions about this started a few years ago when we switched to C++. E.g.: https://sourceware.org/ml/gdb-patches/2017-02/msg00705.html That is why the top level configure was recently changed to avoid the -static-libstc++/-static-libgcc: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00287.html Note that the patch added a new --with-static-standard-libraries configure switch which you can use to get back the previous behavior of linking with the static versions of the standard libraries. I think a NEWS entry for that switch would be helpful, though. > I don't really know what libgcc is used for. libgcc is GCC's low-level runtime library. It's an essential part of any program compiled by GCC: https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html Thanks, Pedro Alves