From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68018 invoked by alias); 18 Dec 2019 23:12:16 -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 68010 invoked by uid 89); 18 Dec 2019 23:12:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=accompanied, staticlibgcc, static-libgcc X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Dec 2019 23:12:15 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50087) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ihgT4-0006Fh-8I; Wed, 18 Dec 2019 16:02:50 -0500 Received: from [176.228.60.248] (port=1937 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ihgJO-00086b-Fp; Wed, 18 Dec 2019 15:52:50 -0500 Date: Wed, 18 Dec 2019 23:12:00 -0000 Message-Id: <83bls52w6e.fsf@gnu.org> From: Eli Zaretskii To: Christian Biesinger CC: gdb-patches@sourceware.org In-reply-to: (gdb-patches@sourceware.org) Subject: Re: [PATCH] Link to -lssp when available (fixes mingw build) References: <20191218181413.128412-1-cbiesinger@google.com> <83h81x323k.fsf@gnu.org> <83fthh310d.fsf@gnu.org> <83eex12zj1.fsf@gnu.org> <83d0cl2yqd.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00799.txt.bz2 > From: "Christian Biesinger via gdb-patches" > Date: Wed, 18 Dec 2019 14:40:42 -0600 > Cc: gdb-patches > > 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. > My msys2/mingw64 gcc depends on these DLLs outside of SYSTEM32: > libpython3.8.dll => /mingw64/bin/libpython3.8.dll (0x70840000) > libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x64940000) > libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x61440000) > libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc40000) In general, any binary that depends on some DLLs and comes with those DLLs needs to be accompanied by the sources of all the DLLs, to be compatible with GPL. In the above list, all the DLLs except Python are part of GCC, so as long as the GCC sources are available, the MinGW64 folks are okay. I don't know how they deal with the problem of providing the Python sources, though. For the binaries I produce, I always try to link statically against DLLs that come from GCC, because I don't want to distribute the humongous GCC sources, and I don't want to provide a binary distribution that is not self-contained (i.e. without those problematic DLLs).