From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) by sourceware.org (Postfix) with ESMTPS id 8F5653857806 for ; Thu, 10 Sep 2020 09:44:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8F5653857806 Received: by mail-ej1-x643.google.com with SMTP id z22so7754027ejl.7 for ; Thu, 10 Sep 2020 02:44:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sDIK7gDFpYhz+dcT75nSv9MAx9nopSsCxC8ufsLlp2M=; b=Lf6hR4f/m5MwibEU0kJ0/7JFmGsxCz6zMd20ksg5MyV5JfMjLrIrzb/P4cY+aOqMdT weo5bFb/klzpyUZsVaHzaeqAVsdYvLbiTN0IJsQjBqOIm5H1sxGkjwzjPDqZOGbXYVe8 vmjcocqG3rxELHutI3t9jckUUiz/xmn3iGM+YabIKMgYOOsBfXxHbijEaxochdvzY63x byg1HAQace7kwzcFuVUkq88NsTI6ylo72Ux2tg2YMY/IULlV+3G2KzvgK7K7cNndsOX6 frsSDKaSZHH5VYL+mTZW5XQ407BuU5VuXKl4HiHtb3Qk1SKBgwmo+Lo3IDPbe+UpfOTb 3uKw== X-Gm-Message-State: AOAM533kWke4MRpiu0q58N4wd05C47kTU6T93U5jxFjpuoKHoK3j8P0z KxKlGjTCE2TnouYmYI+2/d8iSkbdqCIbEEYeG5Y= X-Google-Smtp-Source: ABdhPJzOD1f71pIPQgCHnl2UPgKeJ79P4RuNsQ1NPLPQdKUN2GTPwiSK8d08xfjoADi1K9J+GTkOCz7T/C/Bz6GSrRE= X-Received: by 2002:a17:906:71c9:: with SMTP id i9mr7708709ejk.250.1599731089664; Thu, 10 Sep 2020 02:44:49 -0700 (PDT) MIME-Version: 1.0 References: <82361830-475f-85ab-11bb-c4d8a595754b@gmail.com> <4771abc3-6274-e582-c6b0-0c5166e44b17@gmail.com> In-Reply-To: From: Richard Biener Date: Thu, 10 Sep 2020 11:44:38 +0200 Message-ID: Subject: Re: [PATCH] Cygwin/MinGW: Do not version lto plugins To: JonY <10walls@gmail.com> Cc: Gcc Patch List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 09:44:51 -0000 On Thu, Sep 10, 2020 at 2:26 AM JonY <10walls@gmail.com> wrote: > > On 9/9/20 7:32 AM, JonY wrote: > > On 9/9/20 7:21 AM, Richard Biener wrote: > >> On Wed, Sep 9, 2020 at 2:28 AM JonY via Gcc-patches > >> wrote: > >>> > >>> Hello, > >>> > >>> The lto plugis are tied to the built GCC anyway, so there isn't much > >>> point to versioning them. > >> > >> In fact the lto plugins are not tied to the built GCCs very much, instead > >> we try to ensure compatibility so that a single plugin can be used with > >> multiple GCC versions. > >> > > > > I see, I was not aware of this. > > > >>> * gcc/config.host: Remove version string > >>> * lto-plugin/Makefile.am: Use libtool -avoid-version > >>> * lto-plugin/Makefile.in: Regenerate > >>> > >>> This patch has been in use with Cygwin gcc for a long time and should be > >>> pushed upstream. Patch OK? > >> > >> The libtool docs are not very specific here but does this affect the > >> result for Linux ELF platforms at all? > > > > With current builds: > > > > /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.la > > /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so > > /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so.0 > > /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so.0.0.0 > > > > With -avoid-version it will only generate liblto_plugin.so, from > > gcc/config.host, it is already what is loaded. > > > > I will do a native linux build to confirm this. > > > > I did a bootstrap build of gcc on Linux and it produced the following > after installing: > > libexec/gcc/x86_64-pc-linux-gnu/11.0.0/liblto_plugin.la > libexec/gcc/x86_64-pc-linux-gnu/11.0.0/liblto_plugin.so > > I tested with the following command: > > echo 'main(){}' | strace -f -o gcc.log -- ./inst/bin/gcc -xc - -v > -fuse-linker-plugin -o aa.out > > I can confirm liblto is still loaded correctly from the logs, likewise > renaming it away will cause an error. > > Seems to be fine on Linux. OK then. Thanks, Richard.