Received: (at 27866) by debbugs.gnu.org; 9 Sep 2019 08:39:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Sep 09 04:39:11 2019 Received: from localhost ([127.0.0.1]:39503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1i7FCY-0004tC-Mu for submit <at> debbugs.gnu.org; Mon, 09 Sep 2019 04:39:11 -0400 Received: from mail8.parnet.fi ([77.234.108.134]:12702) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <martin@HIDDEN>) id 1i7FCT-0004sw-P5 for 27866 <at> debbugs.gnu.org; Mon, 09 Sep 2019 04:39:07 -0400 Received: from mail7.parnet.fi (mail7.parnet.fi [77.234.108.28]) by mail8.parnet.fi with ESMTP id x898d1tB029968-x898d1tD029968 (version=TLSv1.0 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 9 Sep 2019 11:39:01 +0300 Received: from foo.martin.st (host-96-177.parnet.fi [77.234.96.177]) by mail7.parnet.fi (8.13.8/8.13.8) with ESMTP id x898cxnd030397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Sep 2019 11:39:00 +0300 Date: Mon, 9 Sep 2019 11:38:59 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN> To: Bob Friesenhahn <bfriesen@HIDDEN> Subject: Re: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries In-Reply-To: <alpine.DEB.2.20.1908191337290.2829@HIDDEN> Message-ID: <alpine.DEB.2.20.1909091137460.6969@HIDDEN> References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN> <20180119221619.GM7217@vapier> <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN> <20180120015033.GE14915@vapier> <alpine.DEB.2.20.1802282253390.2163@HIDDEN> <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN> <alpine.DEB.2.20.1807231831380.20294@HIDDEN> <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN> <alpine.DEB.2.20.1908142339310.2829@HIDDEN> <alpine.DEB.2.20.1908151258290.2829@HIDDEN> <alpine.GSO.2.20.1908150752090.2070@HIDDEN> <alpine.DEB.2.20.1908151745090.2829@HIDDEN> <alpine.GSO.2.20.1908151010310.15088@HIDDEN> <alpine.DEB.2.20.1908191337290.2829@HIDDEN> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-358498663-1568018341=:6969" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27866 Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-358498663-1568018341=:6969 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 19 Aug 2019, Martin Storsjö wrote: > On Thu, 15 Aug 2019, Bob Friesenhahn wrote: > >> On Thu, 15 Aug 2019, Martin Storsjö wrote: >>> >>> But on Windows, the DLLs aren't allowed to have undefined references, so >>> that mechanism of deferring linking of certain libraries don't work there. >>> (And shouldn't this mechanism be sidestepped altogether if linking with >>> -no-undefined in general?) >> >> Libraries provided by the compiler should have a special status since they >> are built in a well-defined way and it should be possible to make >> assumptions about their suitability for use. The failure to ascribe this >> special status appears to be the problem here. > > I tried implementing this, see patch attached patch 2. Any comments or suggestions for the patches? // Martin --8323329-358498663-1568018341=:6969--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.Received: (at submit) by debbugs.gnu.org; 9 Sep 2019 08:39:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Sep 09 04:39:16 2019 Received: from localhost ([127.0.0.1]:39506 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1i7FCe-0004tY-7Z for submit <at> debbugs.gnu.org; Mon, 09 Sep 2019 04:39:16 -0400 Received: from lists.gnu.org ([209.51.188.17]:37846) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <martin@HIDDEN>) id 1i7FCc-0004tQ-7t for submit <at> debbugs.gnu.org; Mon, 09 Sep 2019 04:39:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55952) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <martin@HIDDEN>) id 1i7FCb-0007Nz-4z for bug-libtool@HIDDEN; Mon, 09 Sep 2019 04:39:14 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_LOW autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <martin@HIDDEN>) id 1i7FCZ-00071y-T0 for bug-libtool@HIDDEN; Mon, 09 Sep 2019 04:39:12 -0400 Received: from mail8.parnet.fi ([77.234.108.134]:39584) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <martin@HIDDEN>) id 1i7FCZ-0006zl-Km for bug-libtool@HIDDEN; Mon, 09 Sep 2019 04:39:11 -0400 Received: from mail7.parnet.fi (mail7.parnet.fi [77.234.108.28]) by mail8.parnet.fi with ESMTP id x898d1tB029968-x898d1tD029968 (version=TLSv1.0 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 9 Sep 2019 11:39:01 +0300 Received: from foo.martin.st (host-96-177.parnet.fi [77.234.96.177]) by mail7.parnet.fi (8.13.8/8.13.8) with ESMTP id x898cxnd030397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Sep 2019 11:39:00 +0300 Date: Mon, 9 Sep 2019 11:38:59 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN> To: Bob Friesenhahn <bfriesen@HIDDEN> Subject: Re: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries In-Reply-To: <alpine.DEB.2.20.1908191337290.2829@HIDDEN> Message-ID: <alpine.DEB.2.20.1909091137460.6969@HIDDEN> References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN> <20180119221619.GM7217@vapier> <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN> <20180120015033.GE14915@vapier> <alpine.DEB.2.20.1802282253390.2163@HIDDEN> <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN> <alpine.DEB.2.20.1807231831380.20294@HIDDEN> <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN> <alpine.DEB.2.20.1908142339310.2829@HIDDEN> <alpine.DEB.2.20.1908151258290.2829@HIDDEN> <alpine.GSO.2.20.1908150752090.2070@HIDDEN> <alpine.DEB.2.20.1908151745090.2829@HIDDEN> <alpine.GSO.2.20.1908151010310.15088@HIDDEN> <alpine.DEB.2.20.1908191337290.2829@HIDDEN> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-358498663-1568018341=:6969" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 77.234.108.134 X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.6 (--) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-358498663-1568018341=:6969 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail8.parnet.fi id x898d1tB029968-x898d1tD029968 On Mon, 19 Aug 2019, Martin Storsj=C3=B6 wrote: > On Thu, 15 Aug 2019, Bob Friesenhahn wrote: > >> On Thu, 15 Aug 2019, Martin Storsj=C3=B6 wrote: >>>=20 >>> But on Windows, the DLLs aren't allowed to have undefined references,= so=20 >>> that mechanism of deferring linking of certain libraries don't work t= here.=20 >>> (And shouldn't this mechanism be sidestepped altogether if linking wi= th=20 >>> -no-undefined in general?) >>=20 >> Libraries provided by the compiler should have a special status since = they=20 >> are built in a well-defined way and it should be possible to make=20 >> assumptions about their suitability for use. The failure to ascribe t= his=20 >> special status appears to be the problem here. > > I tried implementing this, see patch attached patch 2. Any comments or suggestions for the patches? // Martin --8323329-358498663-1568018341=:6969--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.Received: (at 27866) by debbugs.gnu.org; 19 Aug 2019 10:45:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 19 06:45:09 2019 Received: from localhost ([127.0.0.1]:59197 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hzf9t-0000yb-GV for submit <at> debbugs.gnu.org; Mon, 19 Aug 2019 06:45:09 -0400 Received: from mail8.parnet.fi ([77.234.108.134]:33744) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <martin@HIDDEN>) id 1hzf9r-0000y8-BP for 27866 <at> debbugs.gnu.org; Mon, 19 Aug 2019 06:45:04 -0400 Received: from mail7.parnet.fi (mail7.parnet.fi [77.234.108.28]) by mail8.parnet.fi with ESMTP id x7JAiwvi009066-x7JAiwvk009066 (version=TLSv1.0 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 19 Aug 2019 13:44:59 +0300 Received: from foo.martin.st (host-96-177.parnet.fi [77.234.96.177]) by mail7.parnet.fi (8.13.8/8.13.8) with ESMTP id x7JAivsT008808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2019 13:44:58 +0300 Date: Mon, 19 Aug 2019 13:44:57 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN> To: Bob Friesenhahn <bfriesen@HIDDEN> Subject: Re: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries In-Reply-To: <alpine.GSO.2.20.1908151010310.15088@HIDDEN> Message-ID: <alpine.DEB.2.20.1908191337290.2829@HIDDEN> References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN> <20180119221619.GM7217@vapier> <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN> <20180120015033.GE14915@vapier> <alpine.DEB.2.20.1802282253390.2163@HIDDEN> <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN> <alpine.DEB.2.20.1807231831380.20294@HIDDEN> <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN> <alpine.DEB.2.20.1908142339310.2829@HIDDEN> <alpine.DEB.2.20.1908151258290.2829@HIDDEN> <alpine.GSO.2.20.1908150752090.2070@HIDDEN> <alpine.DEB.2.20.1908151745090.2829@HIDDEN> <alpine.GSO.2.20.1908151010310.15088@HIDDEN> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1370878363-1566211498=:2829" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27866 Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1370878363-1566211498=:2829 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 15 Aug 2019, Bob Friesenhahn wrote: > On Thu, 15 Aug 2019, Martin Storsjö wrote: >> >> But on Windows, the DLLs aren't allowed to have undefined references, so >> that mechanism of deferring linking of certain libraries don't work there. >> (And shouldn't this mechanism be sidestepped altogether if linking with >> -no-undefined in general?) > > Libraries provided by the compiler should have a special status since they > are built in a well-defined way and it should be possible to make assumptions > about their suitability for use. The failure to ascribe this special status > appears to be the problem here. I tried implementing this, see patch attached patch 2. It's not exactly great to explicitly have to list libraries by name like libgcc* and libclang_rt*, but the existing general mechanisms like deplibs_check_method aren't really used fully here (if deplibs_check_method="file_magic ...", then the static library is just outright rejected without even inspecting it). Or should this case be extended to also try file_magic if that's what has been chosen, and then put the special case code for libclang_rt in e.g. func_win32_libid? (But that wouldn't work for the other mingw case that uses $OBJDUMP -f instead of func_win32_libid.) I also tried updating Manoj's original patch with the suggestions from Mike earlier in this discussion thread in attach patch 1. // Martin --8323329-1370878363-1566211498=:2829 Content-Type: text/x-diff; name=0001-Pick-up-clang_rt-static-archives-compiler-internal-l.patch Content-Transfer-Encoding: BASE64 Content-ID: <alpine.DEB.2.20.1908191344570.2829@HIDDEN> Content-Description: Content-Disposition: attachment; filename=0001-Pick-up-clang_rt-static-archives-compiler-internal-l.patch RnJvbSA4ZTg2MDdlOGE2OTAyYTJkMzc0YjNmNTQwODRjMmI2OGExYWRlNTQx IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogTWFub2ogR3VwdGEg PG1hbm9qZ3VwdGFAY2hyb21pdW0ub3JnPg0KRGF0ZTogV2VkLCAxMCBPY3Qg MjAxOCAxMDo1MDoyMyArMDMwMA0KU3ViamVjdDogW1BBVENIIDEvMl0gUGlj ayB1cCBjbGFuZ19ydCBzdGF0aWMgYXJjaGl2ZXMgY29tcGlsZXIgaW50ZXJu YWwNCiBsaWJyYXJpZXMNCg0KTGlidG9vbCBjaGVja3Mgb25seSBmb3IgbGli cmFyaWVzIGxpbmtlZCBhcyAtbCogd2hlbiB0cnlpbmcgdG8NCmZpbmQgaW50 ZXJuYWwgY29tcGlsZXIgbGlicmFyaWVzLiBDbGFuZywgaG93ZXZlciB1c2Vz IHRoZSBhYnNvbHV0ZQ0KcGF0aCB0byBsaW5rIGl0cyBpbnRlcm5hbCBsaWJy YXJpZXMgZS5nLiBjb21waWxlcl9ydC4gVGhpcyBwYXRjaA0KaGFuZGxlcyBj bGFuZydzIHN0YXRpY2FsbHkgbGlua2VkIGxpYnJhcmllcyB3aGVuIGZpbmRp bmcgaW50ZXJuYWwNCmNvbXBpbGVyIGxpYnJhcmllcy4NCmh0dHBzOi8vY3Ji dWcuY29tLzc0OTI2Mw0KaHR0cHM6Ly9kZWJidWdzLmdudS5vcmcvY2dpL2J1 Z3JlcG9ydC5jZ2k/YnVnPTI3ODY2DQotLS0NCiBtNC9saWJ0b29sLm00IHwg MyArKy0NCiAxIGZpbGUgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCAxIGRl bGV0aW9uKC0pDQoNCmRpZmYgLS1naXQgYS9tNC9saWJ0b29sLm00IGIvbTQv bGlidG9vbC5tNA0KaW5kZXggYjU1YTZlNTcuLmU2ZmMyOWJiIDEwMDY0NA0K LS0tIGEvbTQvbGlidG9vbC5tNA0KKysrIGIvbTQvbGlidG9vbC5tNA0KQEAg LTc1NTMsMTAgKzc1NTMsMTEgQEAgaWYgQUNfVFJZX0VWQUwoYWNfY29tcGls ZSk7IHRoZW4NCiAgICMgdGhlIGNvbmZ0ZXN0IG9iamVjdCBmaWxlLg0KICAg cHJlX3Rlc3Rfb2JqZWN0X2RlcHNfZG9uZT1ubw0KIA0KKyAgZXZhbCBzdGRf c2hyZXh0PVwiJHNocmV4dF9jbWRzXCINCiAgIGZvciBwIGluIGBldmFsICIk b3V0cHV0X3ZlcmJvc2VfbGlua19jbWQiYDsgZG8NCiAgICAgY2FzZSAkcHJl diRwIGluDQogDQotICAgIC1MKiB8IC1SKiB8IC1sKikNCisgICAgLUwqIHwg LVIqIHwgLWwqIHwgKi4ke2xpYmV4dH0gfCAqJHtzdGRfc2hyZXh0fSkNCiAg ICAgICAgIyBTb21lIGNvbXBpbGVycyBwbGFjZSBzcGFjZSBiZXR3ZWVuICIt e0wsUn0iIGFuZCB0aGUgcGF0aC4NCiAgICAgICAgIyBSZW1vdmUgdGhlIHNw YWNlLg0KICAgICAgICBpZiB0ZXN0IHgtTCA9ICIkcCIgfHwNCi0tIA0KMi4x Ny4xDQoNCg== --8323329-1370878363-1566211498=:2829 Content-Type: text/x-diff; name=0002-Allow-statically-linking-compiler-support-libraries-.patch Content-Transfer-Encoding: BASE64 Content-ID: <alpine.DEB.2.20.1908191344571.2829@HIDDEN> Content-Description: Content-Disposition: attachment; filename=0002-Allow-statically-linking-compiler-support-libraries-.patch RnJvbSBiOWY3N2NhZThjZmJlODUwZTU4Y2FjNjg2ZmNiNGQyNDZiNWJmYzUx IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogPT9VVEYtOD9xP01h cnRpbj0yMFN0b3Jzaj1DMz1CNj89IDxtYXJ0aW5AbWFydGluLnN0Pg0KRGF0 ZTogTW9uLCAxOSBBdWcgMjAxOSAxMzozNDo1MSArMDMwMA0KU3ViamVjdDog W1BBVENIIDIvMl0gQWxsb3cgc3RhdGljYWxseSBsaW5raW5nIGNvbXBpbGVy IHN1cHBvcnQgbGlicmFyaWVzIHdoZW4NCiBsaW5raW5nIGEgbGlicmFyeQ0K DQpGb3IgY2FzZXMgd2l0aCBkZXBsaWJzX2NoZWNrX21ldGhvZD0iZmlsZV9t YWdpYyAuLi4iIChhcyBpdCBpcyBmb3IgbWluZ3cpLA0KdGhlcmUgd2VyZSBw cmV2aW91c2x5IG5vIHdheSB0aGF0IGEgc3RhdGljIGxpYnJhcnkgY291bGQg YmUgYWNjZXB0ZWQNCmhlcmUuDQotLS0NCiBidWlsZC1hdXgvbHRtYWluLmlu IHwgMTEgKysrKysrKysrLS0NCiAxIGZpbGUgY2hhbmdlZCwgOSBpbnNlcnRp b25zKCspLCAyIGRlbGV0aW9ucygtKQ0KDQpkaWZmIC0tZ2l0IGEvYnVpbGQt YXV4L2x0bWFpbi5pbiBiL2J1aWxkLWF1eC9sdG1haW4uaW4NCmluZGV4IGUy ZmIyNjMzLi5kYjRkNzc1YyAxMDA2NDQNCi0tLSBhL2J1aWxkLWF1eC9sdG1h aW4uaW4NCisrKyBiL2J1aWxkLWF1eC9sdG1haW4uaW4NCkBAIC01ODcwLDgg KzU4NzAsMTUgQEAgZnVuY19tb2RlX2xpbmsgKCkNCiAJICBmaQ0KIAkgIGNh c2UgJGxpbmttb2RlIGluDQogCSAgbGliKQ0KLQkgICAgIyBMaW5raW5nIGNv bnZlbmllbmNlIG1vZHVsZXMgaW50byBzaGFyZWQgbGlicmFyaWVzIGlzIGFs bG93ZWQsDQotCSAgICAjIGJ1dCBsaW5raW5nIG90aGVyIHN0YXRpYyBsaWJy YXJpZXMgaXMgbm9uLXBvcnRhYmxlLg0KKwkgICAgIyBMaW5raW5nIGNvbnZl bmllbmNlIG1vZHVsZXMgYW5kIGNvbXBpbGVyIHByb3ZpZGVkIHN0YXRpYyBs aWJyYXJpZXMNCisJICAgICMgaW50byBzaGFyZWQgbGlicmFyaWVzIGlzIGFs bG93ZWQsIGJ1dCBsaW5raW5nIG90aGVyIHN0YXRpYw0KKwkgICAgIyBsaWJy YXJpZXMgaXMgbm9uLXBvcnRhYmxlLg0KKwkgICAgY2FzZSAkZGVwbGliIGlu DQorCSAgICAgICovbGliZ2NjKi4kbGliZXh0IHwgKi9saWJjbGFuZ19ydCou JGxpYmV4dCkNCisJCWRlcGxpYnM9IiRkZXBsaWIgJGRlcGxpYnMiDQorCQlj b250aW51ZQ0KKwkgICAgICA7Ow0KKwkgICAgZXNhYw0KIAkgICAgY2FzZSAi ICRkbHByZWNvbnZlbmllbmNlbGlicyAiIGluDQogCSAgICAqIiAkZGVwbGli ICIqKSA7Ow0KIAkgICAgKikNCi0tIA0KMi4xNy4xDQoNCg== --8323329-1370878363-1566211498=:2829--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.Received: (at submit) by debbugs.gnu.org; 19 Aug 2019 10:45:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 19 06:45:19 2019 Received: from localhost ([127.0.0.1]:59200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hzfA3-0000z3-IR for submit <at> debbugs.gnu.org; Mon, 19 Aug 2019 06:45:19 -0400 Received: from lists.gnu.org ([209.51.188.17]:41492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <martin@HIDDEN>) id 1hzf9y-0000yo-Lo for submit <at> debbugs.gnu.org; Mon, 19 Aug 2019 06:45:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49365) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <martin@HIDDEN>) id 1hzf9x-00060U-6F for bug-libtool@HIDDEN; Mon, 19 Aug 2019 06:45:10 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_LOW, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <martin@HIDDEN>) id 1hzf9v-0003tI-G8 for bug-libtool@HIDDEN; Mon, 19 Aug 2019 06:45:08 -0400 Received: from mail8.parnet.fi ([77.234.108.134]:60624) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <martin@HIDDEN>) id 1hzf9v-0003sX-3p for bug-libtool@HIDDEN; Mon, 19 Aug 2019 06:45:07 -0400 Received: from mail7.parnet.fi (mail7.parnet.fi [77.234.108.28]) by mail8.parnet.fi with ESMTP id x7JAiwvi009066-x7JAiwvk009066 (version=TLSv1.0 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 19 Aug 2019 13:44:59 +0300 Received: from foo.martin.st (host-96-177.parnet.fi [77.234.96.177]) by mail7.parnet.fi (8.13.8/8.13.8) with ESMTP id x7JAivsT008808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2019 13:44:58 +0300 Date: Mon, 19 Aug 2019 13:44:57 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN> To: Bob Friesenhahn <bfriesen@HIDDEN> Subject: Re: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries In-Reply-To: <alpine.GSO.2.20.1908151010310.15088@HIDDEN> Message-ID: <alpine.DEB.2.20.1908191337290.2829@HIDDEN> References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN> <20180119221619.GM7217@vapier> <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN> <20180120015033.GE14915@vapier> <alpine.DEB.2.20.1802282253390.2163@HIDDEN> <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN> <alpine.DEB.2.20.1807231831380.20294@HIDDEN> <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN> <alpine.DEB.2.20.1908142339310.2829@HIDDEN> <alpine.DEB.2.20.1908151258290.2829@HIDDEN> <alpine.GSO.2.20.1908150752090.2070@HIDDEN> <alpine.DEB.2.20.1908151745090.2829@HIDDEN> <alpine.GSO.2.20.1908151010310.15088@HIDDEN> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1370878363-1566211498=:2829" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 77.234.108.134 X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.3 (/) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1370878363-1566211498=:2829 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail8.parnet.fi id x7JAiwvi009066-x7JAiwvk009066 On Thu, 15 Aug 2019, Bob Friesenhahn wrote: > On Thu, 15 Aug 2019, Martin Storsj=C3=B6 wrote: >>=20 >> But on Windows, the DLLs aren't allowed to have undefined references, = so=20 >> that mechanism of deferring linking of certain libraries don't work th= ere.=20 >> (And shouldn't this mechanism be sidestepped altogether if linking wit= h=20 >> -no-undefined in general?) > > Libraries provided by the compiler should have a special status since t= hey=20 > are built in a well-defined way and it should be possible to make assum= ptions=20 > about their suitability for use. The failure to ascribe this special s= tatus=20 > appears to be the problem here. I tried implementing this, see patch attached patch 2. It's not exactly great to explicitly have to list libraries by name like=20 libgcc* and libclang_rt*, but the existing general mechanisms like=20 deplibs_check_method aren't really used fully here (if=20 deplibs_check_method=3D"file_magic ...", then the static library is just=20 outright rejected without even inspecting it). Or should this case be extended to also try file_magic if that's what has= =20 been chosen, and then put the special case code for libclang_rt in e.g.=20 func_win32_libid? (But that wouldn't work for the other mingw case that=20 uses $OBJDUMP -f instead of func_win32_libid.) I also tried updating Manoj's original patch with the suggestions from=20 Mike earlier in this discussion thread in attach patch 1. // Martin --8323329-1370878363-1566211498=:2829 Content-Type: text/x-diff; name=0001-Pick-up-clang_rt-static-archives-compiler-internal-l.patch Content-ID: <alpine.DEB.2.20.1908191344570.2829@HIDDEN> Content-Description: Content-Disposition: attachment; filename=0001-Pick-up-clang_rt-static-archives-compiler-internal-l.patch Content-Transfer-Encoding: BASE64 RnJvbSA4ZTg2MDdlOGE2OTAyYTJkMzc0YjNmNTQwODRjMmI2OGExYWRlNTQx IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogTWFub2ogR3VwdGEg PG1hbm9qZ3VwdGFAY2hyb21pdW0ub3JnPg0KRGF0ZTogV2VkLCAxMCBPY3Qg MjAxOCAxMDo1MDoyMyArMDMwMA0KU3ViamVjdDogW1BBVENIIDEvMl0gUGlj ayB1cCBjbGFuZ19ydCBzdGF0aWMgYXJjaGl2ZXMgY29tcGlsZXIgaW50ZXJu YWwNCiBsaWJyYXJpZXMNCg0KTGlidG9vbCBjaGVja3Mgb25seSBmb3IgbGli cmFyaWVzIGxpbmtlZCBhcyAtbCogd2hlbiB0cnlpbmcgdG8NCmZpbmQgaW50 ZXJuYWwgY29tcGlsZXIgbGlicmFyaWVzLiBDbGFuZywgaG93ZXZlciB1c2Vz IHRoZSBhYnNvbHV0ZQ0KcGF0aCB0byBsaW5rIGl0cyBpbnRlcm5hbCBsaWJy YXJpZXMgZS5nLiBjb21waWxlcl9ydC4gVGhpcyBwYXRjaA0KaGFuZGxlcyBj bGFuZydzIHN0YXRpY2FsbHkgbGlua2VkIGxpYnJhcmllcyB3aGVuIGZpbmRp bmcgaW50ZXJuYWwNCmNvbXBpbGVyIGxpYnJhcmllcy4NCmh0dHBzOi8vY3Ji dWcuY29tLzc0OTI2Mw0KaHR0cHM6Ly9kZWJidWdzLmdudS5vcmcvY2dpL2J1 Z3JlcG9ydC5jZ2k/YnVnPTI3ODY2DQotLS0NCiBtNC9saWJ0b29sLm00IHwg MyArKy0NCiAxIGZpbGUgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCAxIGRl bGV0aW9uKC0pDQoNCmRpZmYgLS1naXQgYS9tNC9saWJ0b29sLm00IGIvbTQv bGlidG9vbC5tNA0KaW5kZXggYjU1YTZlNTcuLmU2ZmMyOWJiIDEwMDY0NA0K LS0tIGEvbTQvbGlidG9vbC5tNA0KKysrIGIvbTQvbGlidG9vbC5tNA0KQEAg LTc1NTMsMTAgKzc1NTMsMTEgQEAgaWYgQUNfVFJZX0VWQUwoYWNfY29tcGls ZSk7IHRoZW4NCiAgICMgdGhlIGNvbmZ0ZXN0IG9iamVjdCBmaWxlLg0KICAg cHJlX3Rlc3Rfb2JqZWN0X2RlcHNfZG9uZT1ubw0KIA0KKyAgZXZhbCBzdGRf c2hyZXh0PVwiJHNocmV4dF9jbWRzXCINCiAgIGZvciBwIGluIGBldmFsICIk b3V0cHV0X3ZlcmJvc2VfbGlua19jbWQiYDsgZG8NCiAgICAgY2FzZSAkcHJl diRwIGluDQogDQotICAgIC1MKiB8IC1SKiB8IC1sKikNCisgICAgLUwqIHwg LVIqIHwgLWwqIHwgKi4ke2xpYmV4dH0gfCAqJHtzdGRfc2hyZXh0fSkNCiAg ICAgICAgIyBTb21lIGNvbXBpbGVycyBwbGFjZSBzcGFjZSBiZXR3ZWVuICIt e0wsUn0iIGFuZCB0aGUgcGF0aC4NCiAgICAgICAgIyBSZW1vdmUgdGhlIHNw YWNlLg0KICAgICAgICBpZiB0ZXN0IHgtTCA9ICIkcCIgfHwNCi0tIA0KMi4x Ny4xDQoNCg== --8323329-1370878363-1566211498=:2829 Content-Type: text/x-diff; name=0002-Allow-statically-linking-compiler-support-libraries-.patch Content-ID: <alpine.DEB.2.20.1908191344571.2829@HIDDEN> Content-Description: Content-Disposition: attachment; filename=0002-Allow-statically-linking-compiler-support-libraries-.patch Content-Transfer-Encoding: BASE64 RnJvbSBiOWY3N2NhZThjZmJlODUwZTU4Y2FjNjg2ZmNiNGQyNDZiNWJmYzUx IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogPT9VVEYtOD9xP01h cnRpbj0yMFN0b3Jzaj1DMz1CNj89IDxtYXJ0aW5AbWFydGluLnN0Pg0KRGF0 ZTogTW9uLCAxOSBBdWcgMjAxOSAxMzozNDo1MSArMDMwMA0KU3ViamVjdDog W1BBVENIIDIvMl0gQWxsb3cgc3RhdGljYWxseSBsaW5raW5nIGNvbXBpbGVy IHN1cHBvcnQgbGlicmFyaWVzIHdoZW4NCiBsaW5raW5nIGEgbGlicmFyeQ0K DQpGb3IgY2FzZXMgd2l0aCBkZXBsaWJzX2NoZWNrX21ldGhvZD0iZmlsZV9t YWdpYyAuLi4iIChhcyBpdCBpcyBmb3IgbWluZ3cpLA0KdGhlcmUgd2VyZSBw cmV2aW91c2x5IG5vIHdheSB0aGF0IGEgc3RhdGljIGxpYnJhcnkgY291bGQg YmUgYWNjZXB0ZWQNCmhlcmUuDQotLS0NCiBidWlsZC1hdXgvbHRtYWluLmlu IHwgMTEgKysrKysrKysrLS0NCiAxIGZpbGUgY2hhbmdlZCwgOSBpbnNlcnRp b25zKCspLCAyIGRlbGV0aW9ucygtKQ0KDQpkaWZmIC0tZ2l0IGEvYnVpbGQt YXV4L2x0bWFpbi5pbiBiL2J1aWxkLWF1eC9sdG1haW4uaW4NCmluZGV4IGUy ZmIyNjMzLi5kYjRkNzc1YyAxMDA2NDQNCi0tLSBhL2J1aWxkLWF1eC9sdG1h aW4uaW4NCisrKyBiL2J1aWxkLWF1eC9sdG1haW4uaW4NCkBAIC01ODcwLDgg KzU4NzAsMTUgQEAgZnVuY19tb2RlX2xpbmsgKCkNCiAJICBmaQ0KIAkgIGNh c2UgJGxpbmttb2RlIGluDQogCSAgbGliKQ0KLQkgICAgIyBMaW5raW5nIGNv bnZlbmllbmNlIG1vZHVsZXMgaW50byBzaGFyZWQgbGlicmFyaWVzIGlzIGFs bG93ZWQsDQotCSAgICAjIGJ1dCBsaW5raW5nIG90aGVyIHN0YXRpYyBsaWJy YXJpZXMgaXMgbm9uLXBvcnRhYmxlLg0KKwkgICAgIyBMaW5raW5nIGNvbnZl bmllbmNlIG1vZHVsZXMgYW5kIGNvbXBpbGVyIHByb3ZpZGVkIHN0YXRpYyBs aWJyYXJpZXMNCisJICAgICMgaW50byBzaGFyZWQgbGlicmFyaWVzIGlzIGFs bG93ZWQsIGJ1dCBsaW5raW5nIG90aGVyIHN0YXRpYw0KKwkgICAgIyBsaWJy YXJpZXMgaXMgbm9uLXBvcnRhYmxlLg0KKwkgICAgY2FzZSAkZGVwbGliIGlu DQorCSAgICAgICovbGliZ2NjKi4kbGliZXh0IHwgKi9saWJjbGFuZ19ydCou JGxpYmV4dCkNCisJCWRlcGxpYnM9IiRkZXBsaWIgJGRlcGxpYnMiDQorCQlj b250aW51ZQ0KKwkgICAgICA7Ow0KKwkgICAgZXNhYw0KIAkgICAgY2FzZSAi ICRkbHByZWNvbnZlbmllbmNlbGlicyAiIGluDQogCSAgICAqIiAkZGVwbGli ICIqKSA7Ow0KIAkgICAgKikNCi0tIA0KMi4xNy4xDQoNCg== --8323329-1370878363-1566211498=:2829--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.Received: (at 27866) by debbugs.gnu.org; 15 Aug 2019 21:07:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 15 17:07:03 2019 Received: from localhost ([127.0.0.1]:52524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hyMxb-0000YM-Jw for submit <at> debbugs.gnu.org; Thu, 15 Aug 2019 17:07:03 -0400 Received: from mail8.parnet.fi ([77.234.108.134]:55584) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <martin@HIDDEN>) id 1hyMxY-0000Xo-To for 27866 <at> debbugs.gnu.org; Thu, 15 Aug 2019 17:07:02 -0400 Received: from mail7.parnet.fi (mail7.parnet.fi [77.234.108.28]) by mail8.parnet.fi with ESMTP id x7FL6vOf013649-x7FL6vOh013649 (version=TLSv1.0 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 16 Aug 2019 00:06:57 +0300 Received: from foo.martin.st (host-96-177.parnet.fi [77.234.96.177]) by mail7.parnet.fi (8.13.8/8.13.8) with ESMTP id x7FL6ush031543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2019 00:06:57 +0300 Date: Fri, 16 Aug 2019 00:06:56 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN> To: Bob Friesenhahn <bfriesen@HIDDEN> Subject: Re: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries In-Reply-To: <alpine.GSO.2.20.1908151010310.15088@HIDDEN> Message-ID: <alpine.DEB.2.20.1908152359490.2829@HIDDEN> References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN> <20180119221619.GM7217@vapier> <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN> <20180120015033.GE14915@vapier> <alpine.DEB.2.20.1802282253390.2163@HIDDEN> <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN> <alpine.DEB.2.20.1807231831380.20294@HIDDEN> <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN> <alpine.DEB.2.20.1908142339310.2829@HIDDEN> <alpine.DEB.2.20.1908151258290.2829@HIDDEN> <alpine.GSO.2.20.1908150752090.2070@HIDDEN> <alpine.DEB.2.20.1908151745090.2829@HIDDEN> <alpine.GSO.2.20.1908151010310.15088@HIDDEN> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1563427953-1565903217=:2829" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27866 Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1563427953-1565903217=:2829 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 15 Aug 2019, Bob Friesenhahn wrote: > On Thu, 15 Aug 2019, Martin Storsjö wrote: >> >> But on Windows, the DLLs aren't allowed to have undefined references, so >> that mechanism of deferring linking of certain libraries don't work there. >> (And shouldn't this mechanism be sidestepped altogether if linking with >> -no-undefined in general?) > > Libraries provided by the compiler should have a special status since they > are built in a well-defined way and it should be possible to make assumptions > about their suitability for use. The failure to ascribe this special status > appears to be the problem here. Hmm, ok... Is there code in libtool that actually tries to make this distinction, that should be adjusted so that it triggers here as well, or is that just a general thing that would be sensible to have? >> Additionally, I don't know of any special options that need to be used to >> build code for a shared library on Windows (either MSVC or mingw), as e.g. >> -fPIC doesn't apply on windows at all. So given that, it seems to me that >> lt_cv_deplibs_check_method=pass_all on windows/mingw should be safe? > > Actually, Windows DLL code does often require special options so that symbols > are exposed and used in the correct way. It may be that GCC and Clang help > by automating symbol export and import in a way that compilers like Visual > Studio / MSVC do not. Right, yes, the use or lack of dllimport is an issue, yes. But that doesn't mean one can't/shouldn't link to static libraries when building a shared one either, it only implies that one has to link against one that matches the attributes used when compiling the calling code. And yes, GCC/Clang and ld.bfd and lld have special code that make most of this issue go away (making dllimport essentially unnecessary). > There are also often issues with exception handling since throwing > exceptions across a DLL boundary is a special case, which historically > has been handled in a couple of different ways by GCC. Yeah, that's also a big potential issue. But as far as I know, libtool doesn't actually check for either of these issues at the momemnt anyway, or does it? I.e. does the dependency check actually help detecting any of these issues specifically, or just refuse to link in static libraries in general (in certain cases) when building a shared one? // Martin --8323329-1563427953-1565903217=:2829--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.Received: (at submit) by debbugs.gnu.org; 15 Aug 2019 21:07:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 15 17:07:12 2019 Received: from localhost ([127.0.0.1]:52527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hyMxi-0000Yy-WA for submit <at> debbugs.gnu.org; Thu, 15 Aug 2019 17:07:12 -0400 Received: from lists.gnu.org ([209.51.188.17]:45702) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <martin@HIDDEN>) id 1hyMxh-0000Ym-B1 for submit <at> debbugs.gnu.org; Thu, 15 Aug 2019 17:07:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56452) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <martin@HIDDEN>) id 1hyMxf-000464-9M for bug-libtool@HIDDEN; Thu, 15 Aug 2019 17:07:09 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_LOW autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <martin@HIDDEN>) id 1hyMxd-0006pY-17 for bug-libtool@HIDDEN; Thu, 15 Aug 2019 17:07:06 -0400 Received: from mail8.parnet.fi ([77.234.108.134]:31466) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <martin@HIDDEN>) id 1hyMxc-0006pH-Nd for bug-libtool@HIDDEN; Thu, 15 Aug 2019 17:07:04 -0400 Received: from mail7.parnet.fi (mail7.parnet.fi [77.234.108.28]) by mail8.parnet.fi with ESMTP id x7FL6vOf013649-x7FL6vOh013649 (version=TLSv1.0 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 16 Aug 2019 00:06:57 +0300 Received: from foo.martin.st (host-96-177.parnet.fi [77.234.96.177]) by mail7.parnet.fi (8.13.8/8.13.8) with ESMTP id x7FL6ush031543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2019 00:06:57 +0300 Date: Fri, 16 Aug 2019 00:06:56 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN> To: Bob Friesenhahn <bfriesen@HIDDEN> Subject: Re: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries In-Reply-To: <alpine.GSO.2.20.1908151010310.15088@HIDDEN> Message-ID: <alpine.DEB.2.20.1908152359490.2829@HIDDEN> References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN> <20180119221619.GM7217@vapier> <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN> <20180120015033.GE14915@vapier> <alpine.DEB.2.20.1802282253390.2163@HIDDEN> <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN> <alpine.DEB.2.20.1807231831380.20294@HIDDEN> <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN> <alpine.DEB.2.20.1908142339310.2829@HIDDEN> <alpine.DEB.2.20.1908151258290.2829@HIDDEN> <alpine.GSO.2.20.1908150752090.2070@HIDDEN> <alpine.DEB.2.20.1908151745090.2829@HIDDEN> <alpine.GSO.2.20.1908151010310.15088@HIDDEN> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1563427953-1565903217=:2829" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 77.234.108.134 X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.6 (--) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1563427953-1565903217=:2829 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail8.parnet.fi id x7FL6vOf013649-x7FL6vOh013649 On Thu, 15 Aug 2019, Bob Friesenhahn wrote: > On Thu, 15 Aug 2019, Martin Storsj=C3=B6 wrote: >>=20 >> But on Windows, the DLLs aren't allowed to have undefined references, = so=20 >> that mechanism of deferring linking of certain libraries don't work th= ere.=20 >> (And shouldn't this mechanism be sidestepped altogether if linking wit= h=20 >> -no-undefined in general?) > > Libraries provided by the compiler should have a special status since t= hey=20 > are built in a well-defined way and it should be possible to make assum= ptions=20 > about their suitability for use. The failure to ascribe this special s= tatus=20 > appears to be the problem here. Hmm, ok... Is there code in libtool that actually tries to make this=20 distinction, that should be adjusted so that it triggers here as well, or= =20 is that just a general thing that would be sensible to have? >> Additionally, I don't know of any special options that need to be used= to=20 >> build code for a shared library on Windows (either MSVC or mingw), as = e.g.=20 >> -fPIC doesn't apply on windows at all. So given that, it seems to me t= hat=20 >> lt_cv_deplibs_check_method=3Dpass_all on windows/mingw should be safe? > > Actually, Windows DLL code does often require special options so that s= ymbols=20 > are exposed and used in the correct way. It may be that GCC and Clang = help=20 > by automating symbol export and import in a way that compilers like Vis= ual=20 > Studio / MSVC do not. Right, yes, the use or lack of dllimport is an issue, yes. But that=20 doesn't mean one can't/shouldn't link to static libraries when building a= =20 shared one either, it only implies that one has to link against one that=20 matches the attributes used when compiling the calling code. And yes, GCC/Clang and ld.bfd and lld have special code that make most of= =20 this issue go away (making dllimport essentially unnecessary). > There are also often issues with exception handling since throwing=20 > exceptions across a DLL boundary is a special case, which historically=20 > has been handled in a couple of different ways by GCC. Yeah, that's also a big potential issue. But as far as I know, libtool doesn't actually check for either of these=20 issues at the momemnt anyway, or does it? I.e. does the dependency check=20 actually help detecting any of these issues specifically, or just refuse=20 to link in static libraries in general (in certain cases) when building a= =20 shared one? // Martin --8323329-1563427953-1565903217=:2829--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.Received: (at 27866) by debbugs.gnu.org; 15 Aug 2019 15:20:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 15 11:20:15 2019 Received: from localhost ([127.0.0.1]:52238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hyHXy-0007Gi-P1 for submit <at> debbugs.gnu.org; Thu, 15 Aug 2019 11:20:15 -0400 Received: from smtp.simplesystems.org ([65.66.246.90]:62962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <bfriesen@HIDDEN>) id 1hyHXv-0007GA-SC for 27866 <at> debbugs.gnu.org; Thu, 15 Aug 2019 11:20:12 -0400 Received: from scrappy.simplesystems.org (scrappy.simplesystems.org [65.66.246.73]) by smtp.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id x7FFK3cI016442; Thu, 15 Aug 2019 10:20:03 -0500 (CDT) Date: Thu, 15 Aug 2019 10:20:03 -0500 (CDT) From: Bob Friesenhahn <bfriesen@HIDDEN> X-X-Sender: bfriesen@HIDDEN To: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN> Subject: Re: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries In-Reply-To: <alpine.DEB.2.20.1908151745090.2829@HIDDEN> Message-ID: <alpine.GSO.2.20.1908151010310.15088@HIDDEN> References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN> <20180119221619.GM7217@vapier> <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN> <20180120015033.GE14915@vapier> <alpine.DEB.2.20.1802282253390.2163@HIDDEN> <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN> <alpine.DEB.2.20.1807231831380.20294@HIDDEN> <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN> <alpine.DEB.2.20.1908142339310.2829@HIDDEN> <alpine.DEB.2.20.1908151258290.2829@HIDDEN> <alpine.GSO.2.20.1908150752090.2070@HIDDEN> <alpine.DEB.2.20.1908151745090.2829@HIDDEN> User-Agent: Alpine 2.20 (GSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="3735943886-341603450-1565882404=:15088" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (smtp.simplesystems.org [65.66.246.90]); Thu, 15 Aug 2019 10:20:04 -0500 (CDT) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 27866 Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3735943886-341603450-1565882404=:15088 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 15 Aug 2019, Martin Storsjö wrote: > > But on Windows, the DLLs aren't allowed to have undefined references, so that > mechanism of deferring linking of certain libraries don't work there. (And > shouldn't this mechanism be sidestepped altogether if linking with > -no-undefined in general?) Libraries provided by the compiler should have a special status since they are built in a well-defined way and it should be possible to make assumptions about their suitability for use. The failure to ascribe this special status appears to be the problem here. > Additionally, I don't know of any special options that need to be used to > build code for a shared library on Windows (either MSVC or mingw), as e.g. > -fPIC doesn't apply on windows at all. So given that, it seems to me that > lt_cv_deplibs_check_method=pass_all on windows/mingw should be safe? Actually, Windows DLL code does often require special options so that symbols are exposed and used in the correct way. It may be that GCC and Clang help by automating symbol export and import in a way that compilers like Visual Studio / MSVC do not. There are also often issues with exception handling since throwing exceptions across a DLL boundary is a special case, which historically has been handled in a couple of different ways by GCC. Bob -- Bob Friesenhahn bfriesen@HIDDEN, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt --3735943886-341603450-1565882404=:15088--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.Received: (at submit) by debbugs.gnu.org; 15 Aug 2019 15:20:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 15 11:20:31 2019 Received: from localhost ([127.0.0.1]:52241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hyHYF-0007HF-3V for submit <at> debbugs.gnu.org; Thu, 15 Aug 2019 11:20:31 -0400 Received: from lists.gnu.org ([209.51.188.17]:35327) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <bfriesen@HIDDEN>) id 1hyHYD-0007H8-FH for submit <at> debbugs.gnu.org; Thu, 15 Aug 2019 11:20:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36370) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <bfriesen@HIDDEN>) id 1hyHY8-0006S4-Cg for bug-libtool@HIDDEN; Thu, 15 Aug 2019 11:20:29 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <bfriesen@HIDDEN>) id 1hyHY3-0007em-LQ for bug-libtool@HIDDEN; Thu, 15 Aug 2019 11:20:24 -0400 Received: from smtp.simplesystems.org ([65.66.246.90]:44667) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <bfriesen@HIDDEN>) id 1hyHY1-0007cb-Pp for bug-libtool@HIDDEN; Thu, 15 Aug 2019 11:20:19 -0400 Received: from scrappy.simplesystems.org (scrappy.simplesystems.org [65.66.246.73]) by smtp.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id x7FFK3cI016442; Thu, 15 Aug 2019 10:20:03 -0500 (CDT) Date: Thu, 15 Aug 2019 10:20:03 -0500 (CDT) From: Bob Friesenhahn <bfriesen@HIDDEN> X-X-Sender: bfriesen@HIDDEN To: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN> Subject: Re: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries In-Reply-To: <alpine.DEB.2.20.1908151745090.2829@HIDDEN> Message-ID: <alpine.GSO.2.20.1908151010310.15088@HIDDEN> References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN> <20180119221619.GM7217@vapier> <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN> <20180120015033.GE14915@vapier> <alpine.DEB.2.20.1802282253390.2163@HIDDEN> <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN> <alpine.DEB.2.20.1807231831380.20294@HIDDEN> <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN> <alpine.DEB.2.20.1908142339310.2829@HIDDEN> <alpine.DEB.2.20.1908151258290.2829@HIDDEN> <alpine.GSO.2.20.1908150752090.2070@HIDDEN> <alpine.DEB.2.20.1908151745090.2829@HIDDEN> User-Agent: Alpine 2.20 (GSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="3735943886-341603450-1565882404=:15088" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (smtp.simplesystems.org [65.66.246.90]); Thu, 15 Aug 2019 10:20:04 -0500 (CDT) X-detected-operating-system: by eggs.gnu.org: GNU/Linux (Android) X-Received-From: 65.66.246.90 X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.4 (--) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3735943886-341603450-1565882404=:15088 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.simplesystems.org id x7FFK3cI016442 On Thu, 15 Aug 2019, Martin Storsj=C3=B6 wrote: > > But on Windows, the DLLs aren't allowed to have undefined references, s= o that=20 > mechanism of deferring linking of certain libraries don't work there. (= And=20 > shouldn't this mechanism be sidestepped altogether if linking with=20 > -no-undefined in general?) Libraries provided by the compiler should have a special status since=20 they are built in a well-defined way and it should be possible to make=20 assumptions about their suitability for use. The failure to ascribe=20 this special status appears to be the problem here. > Additionally, I don't know of any special options that need to be used = to=20 > build code for a shared library on Windows (either MSVC or mingw), as e= .g.=20 > -fPIC doesn't apply on windows at all. So given that, it seems to me th= at=20 > lt_cv_deplibs_check_method=3Dpass_all on windows/mingw should be safe? Actually, Windows DLL code does often require special options so that=20 symbols are exposed and used in the correct way. It may be that GCC=20 and Clang help by automating symbol export and import in a way that=20 compilers like Visual Studio / MSVC do not. There are also often=20 issues with exception handling since throwing exceptions across a DLL=20 boundary is a special case, which historically has been handled in a=20 couple of different ways by GCC. Bob --=20 Bob Friesenhahn bfriesen@HIDDEN, http://www.simplesystems.org/users/bfriesen= / GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.tx= t --3735943886-341603450-1565882404=:15088--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.Received: (at submit) by debbugs.gnu.org; 15 Aug 2019 14:57:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 15 10:57:03 2019 Received: from localhost ([127.0.0.1]:52206 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hyHBX-0004ap-EX for submit <at> debbugs.gnu.org; Thu, 15 Aug 2019 10:57:03 -0400 Received: from lists.gnu.org ([209.51.188.17]:35258) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <martin@HIDDEN>) id 1hyHBW-0004aV-Gp for submit <at> debbugs.gnu.org; Thu, 15 Aug 2019 10:57:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33143) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <martin@HIDDEN>) id 1hyHBS-0004rs-3t for bug-libtool@HIDDEN; Thu, 15 Aug 2019 10:57:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_LOW, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <martin@HIDDEN>) id 1hyHBN-0006OC-US for bug-libtool@HIDDEN; Thu, 15 Aug 2019 10:56:57 -0400 Received: from mail8.parnet.fi ([77.234.108.134]:19870) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <martin@HIDDEN>) id 1hyHBN-0006Mn-K3 for bug-libtool@HIDDEN; Thu, 15 Aug 2019 10:56:53 -0400 Received: from mail7.parnet.fi (mail7.parnet.fi [77.234.108.28]) by mail8.parnet.fi with ESMTP id x7FEukPj022640-x7FEukPl022640 (version=TLSv1.0 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 15 Aug 2019 17:56:46 +0300 Received: from foo.martin.st (host-96-177.parnet.fi [77.234.96.177]) by mail7.parnet.fi (8.13.8/8.13.8) with ESMTP id x7FEui4p016554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Aug 2019 17:56:45 +0300 Date: Thu, 15 Aug 2019 17:56:44 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN> To: Bob Friesenhahn <bfriesen@HIDDEN> Subject: Re: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries In-Reply-To: <alpine.GSO.2.20.1908150752090.2070@HIDDEN> Message-ID: <alpine.DEB.2.20.1908151745090.2829@HIDDEN> References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN> <20180119221619.GM7217@vapier> <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN> <20180120015033.GE14915@vapier> <alpine.DEB.2.20.1802282253390.2163@HIDDEN> <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN> <alpine.DEB.2.20.1807231831380.20294@HIDDEN> <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN> <alpine.DEB.2.20.1908142339310.2829@HIDDEN> <alpine.DEB.2.20.1908151258290.2829@HIDDEN> <alpine.GSO.2.20.1908150752090.2070@HIDDEN> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1541579280-1565881006=:2829" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 77.234.108.134 X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.6 (--) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1541579280-1565881006=:2829 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail8.parnet.fi id x7FEukPj022640-x7FEukPl022640 On Thu, 15 Aug 2019, Bob Friesenhahn wrote: > On Thu, 15 Aug 2019, Martin Storsj=C3=B6 wrote: >>=20 >> So, it basically boils down to, what the actual purpose of inspecting=20 >> dependency libs is (what real scenario does it protect from), as it br= eaks=20 >> linking to compiler_rt's builtins (which are referred to as an absolut= e=20 >> path to the .a file)? > > The purpose of inspecting dependency libs is that often code needs to b= e=20 > compiled with special options (e.g. for PIC code) in order to function = in=20 > shared libraries or DLLs. Code which was compiled properly can be incl= uded=20 > in the shared library but code which lacks the necessary options needs = to be=20 > saved for later and linked directly with the dependent program. Libtoo= l's=20 > ".la" files contain enough information that libtool can make the correc= t=20 > decision when a dependent program is linked. > > If code which is not prepared for use in a shared library is included i= nto=20 > the shared library, the linking may fail, or the program may crash, or = run=20 > very inefficiently. Ah, thanks for the explanation. Ok, if libtool has the ability to defer=20 the use of such libraries to the the executable instead of the shared=20 library, that's clearly neat. But on Windows, the DLLs aren't allowed to have undefined references, so=20 that mechanism of deferring linking of certain libraries don't work there= .=20 (And shouldn't this mechanism be sidestepped altogether if linking with=20 -no-undefined in general?) Additionally, I don't know of any special options that need to be used to= =20 build code for a shared library on Windows (either MSVC or mingw), as e.g= .=20 -fPIC doesn't apply on windows at all. So given that, it seems to me that= =20 lt_cv_deplibs_check_method=3Dpass_all on windows/mingw should be safe? > Since clang is intended to be gcc compatible, it would be most useful f= or=20 > clang and its linker to emulate the GNU equivalents closely enough that= =20 > existing build infrastructure does not need to change. Yes, that would of course be ideal, but for various reasons it doesn't=20 always happen to the full extent. In general, clang does link to libgcc just like gcc does, by passing=20 -L<gccdir> -lgcc, but when using compiler_rt, it does so by passing the=20 full absolute path to the static library instead. I started out making a patch for changing this some time ago, but there=20 were arguments against it; apparently it's deemed a safety feature to be=20 more exact in how the compiler_rt libraries are specified:=20 https://reviews.llvm.org/D51440 // Martin --8323329-1541579280-1565881006=:2829--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.Received: (at 27866) by debbugs.gnu.org; 15 Aug 2019 14:56:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 15 10:56:56 2019 Received: from localhost ([127.0.0.1]:52200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hyHBQ-0004a2-2U for submit <at> debbugs.gnu.org; Thu, 15 Aug 2019 10:56:56 -0400 Received: from mail8.parnet.fi ([77.234.108.134]:43988) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <martin@HIDDEN>) id 1hyHBK-0004Zc-E7 for 27866 <at> debbugs.gnu.org; Thu, 15 Aug 2019 10:56:52 -0400 Received: from mail7.parnet.fi (mail7.parnet.fi [77.234.108.28]) by mail8.parnet.fi with ESMTP id x7FEukPj022640-x7FEukPl022640 (version=TLSv1.0 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 15 Aug 2019 17:56:46 +0300 Received: from foo.martin.st (host-96-177.parnet.fi [77.234.96.177]) by mail7.parnet.fi (8.13.8/8.13.8) with ESMTP id x7FEui4p016554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Aug 2019 17:56:45 +0300 Date: Thu, 15 Aug 2019 17:56:44 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN> To: Bob Friesenhahn <bfriesen@HIDDEN> Subject: Re: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries In-Reply-To: <alpine.GSO.2.20.1908150752090.2070@HIDDEN> Message-ID: <alpine.DEB.2.20.1908151745090.2829@HIDDEN> References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN> <20180119221619.GM7217@vapier> <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN> <20180120015033.GE14915@vapier> <alpine.DEB.2.20.1802282253390.2163@HIDDEN> <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN> <alpine.DEB.2.20.1807231831380.20294@HIDDEN> <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN> <alpine.DEB.2.20.1908142339310.2829@HIDDEN> <alpine.DEB.2.20.1908151258290.2829@HIDDEN> <alpine.GSO.2.20.1908150752090.2070@HIDDEN> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1541579280-1565881006=:2829" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27866 Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1541579280-1565881006=:2829 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 15 Aug 2019, Bob Friesenhahn wrote: > On Thu, 15 Aug 2019, Martin Storsjö wrote: >> >> So, it basically boils down to, what the actual purpose of inspecting >> dependency libs is (what real scenario does it protect from), as it breaks >> linking to compiler_rt's builtins (which are referred to as an absolute >> path to the .a file)? > > The purpose of inspecting dependency libs is that often code needs to be > compiled with special options (e.g. for PIC code) in order to function in > shared libraries or DLLs. Code which was compiled properly can be included > in the shared library but code which lacks the necessary options needs to be > saved for later and linked directly with the dependent program. Libtool's > ".la" files contain enough information that libtool can make the correct > decision when a dependent program is linked. > > If code which is not prepared for use in a shared library is included into > the shared library, the linking may fail, or the program may crash, or run > very inefficiently. Ah, thanks for the explanation. Ok, if libtool has the ability to defer the use of such libraries to the the executable instead of the shared library, that's clearly neat. But on Windows, the DLLs aren't allowed to have undefined references, so that mechanism of deferring linking of certain libraries don't work there. (And shouldn't this mechanism be sidestepped altogether if linking with -no-undefined in general?) Additionally, I don't know of any special options that need to be used to build code for a shared library on Windows (either MSVC or mingw), as e.g. -fPIC doesn't apply on windows at all. So given that, it seems to me that lt_cv_deplibs_check_method=pass_all on windows/mingw should be safe? > Since clang is intended to be gcc compatible, it would be most useful for > clang and its linker to emulate the GNU equivalents closely enough that > existing build infrastructure does not need to change. Yes, that would of course be ideal, but for various reasons it doesn't always happen to the full extent. In general, clang does link to libgcc just like gcc does, by passing -L<gccdir> -lgcc, but when using compiler_rt, it does so by passing the full absolute path to the static library instead. I started out making a patch for changing this some time ago, but there were arguments against it; apparently it's deemed a safety feature to be more exact in how the compiler_rt libraries are specified: https://reviews.llvm.org/D51440 // Martin --8323329-1541579280-1565881006=:2829--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.Received: (at submit) by debbugs.gnu.org; 15 Aug 2019 13:02:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 15 09:02:14 2019 Received: from localhost ([127.0.0.1]:50812 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hyFOO-0005fO-Ot for submit <at> debbugs.gnu.org; Thu, 15 Aug 2019 09:02:14 -0400 Received: from lists.gnu.org ([209.51.188.17]:47350) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <bfriesen@HIDDEN>) id 1hyFON-0005fG-2z for submit <at> debbugs.gnu.org; Thu, 15 Aug 2019 09:02:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43394) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <bfriesen@HIDDEN>) id 1hyFOI-0004Wm-Eg for bug-libtool@HIDDEN; Thu, 15 Aug 2019 09:02:10 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <bfriesen@HIDDEN>) id 1hyFOA-0007fc-VV for bug-libtool@HIDDEN; Thu, 15 Aug 2019 09:02:06 -0400 Received: from smtp.simplesystems.org ([65.66.246.90]:37218) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <bfriesen@HIDDEN>) id 1hyFOA-0007eR-NH for bug-libtool@HIDDEN; Thu, 15 Aug 2019 09:01:58 -0400 Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by smtp.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id x7FD1lVs012824; Thu, 15 Aug 2019 08:01:47 -0500 (CDT) Date: Thu, 15 Aug 2019 08:01:47 -0500 (CDT) From: Bob Friesenhahn <bfriesen@HIDDEN> X-X-Sender: bfriesen@HIDDEN To: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN> Subject: Re: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries In-Reply-To: <alpine.DEB.2.20.1908151258290.2829@HIDDEN> Message-ID: <alpine.GSO.2.20.1908150752090.2070@HIDDEN> References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN> <20180119221619.GM7217@vapier> <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN> <20180120015033.GE14915@vapier> <alpine.DEB.2.20.1802282253390.2163@HIDDEN> <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN> <alpine.DEB.2.20.1807231831380.20294@HIDDEN> <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN> <alpine.DEB.2.20.1908142339310.2829@HIDDEN> <alpine.DEB.2.20.1908151258290.2829@HIDDEN> User-Agent: Alpine 2.20 (GSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-559023410-332568753-1565874107=:2070" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (smtp.simplesystems.org [65.66.246.90]); Thu, 15 Aug 2019 08:01:47 -0500 (CDT) X-detected-operating-system: by eggs.gnu.org: GNU/Linux (Android) X-Received-From: 65.66.246.90 X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.4 (--) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-332568753-1565874107=:2070 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.simplesystems.org id x7FD1lVs012824 On Thu, 15 Aug 2019, Martin Storsj=C3=B6 wrote: > > So, it basically boils down to, what the actual purpose of inspecting=20 > dependency libs is (what real scenario does it protect from), as it bre= aks=20 > linking to compiler_rt's builtins (which are referred to as an absolute= path=20 > to the .a file)? The purpose of inspecting dependency libs is that often code needs to=20 be compiled with special options (e.g. for PIC code) in order to=20 function in shared libraries or DLLs. Code which was compiled=20 properly can be included in the shared library but code which lacks=20 the necessary options needs to be saved for later and linked directly=20 with the dependent program. Libtool's ".la" files contain enough=20 information that libtool can make the correct decision when a=20 dependent program is linked. If code which is not prepared for use in a shared library is included=20 into the shared library, the linking may fail, or the program may=20 crash, or run very inefficiently. Since clang is intended to be gcc compatible, it would be most useful=20 for clang and its linker to emulate the GNU equivalents closely enough=20 that existing build infrastructure does not need to change. Bob --=20 Bob Friesenhahn bfriesen@HIDDEN, http://www.simplesystems.org/users/bfriesen= / GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.tx= t ---559023410-332568753-1565874107=:2070--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.Received: (at 27866) by debbugs.gnu.org; 15 Aug 2019 13:01:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 15 09:01:58 2019 Received: from localhost ([127.0.0.1]:50808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hyFOA-0005eZ-Dl for submit <at> debbugs.gnu.org; Thu, 15 Aug 2019 09:01:58 -0400 Received: from smtp.simplesystems.org ([65.66.246.90]:61686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <bfriesen@HIDDEN>) id 1hyFO8-0005eL-Eo for 27866 <at> debbugs.gnu.org; Thu, 15 Aug 2019 09:01:57 -0400 Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by smtp.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id x7FD1lVs012824; Thu, 15 Aug 2019 08:01:47 -0500 (CDT) Date: Thu, 15 Aug 2019 08:01:47 -0500 (CDT) From: Bob Friesenhahn <bfriesen@HIDDEN> X-X-Sender: bfriesen@HIDDEN To: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN> Subject: Re: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries In-Reply-To: <alpine.DEB.2.20.1908151258290.2829@HIDDEN> Message-ID: <alpine.GSO.2.20.1908150752090.2070@HIDDEN> References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN> <20180119221619.GM7217@vapier> <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN> <20180120015033.GE14915@vapier> <alpine.DEB.2.20.1802282253390.2163@HIDDEN> <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN> <alpine.DEB.2.20.1807231831380.20294@HIDDEN> <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN> <alpine.DEB.2.20.1908142339310.2829@HIDDEN> <alpine.DEB.2.20.1908151258290.2829@HIDDEN> User-Agent: Alpine 2.20 (GSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-559023410-332568753-1565874107=:2070" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (smtp.simplesystems.org [65.66.246.90]); Thu, 15 Aug 2019 08:01:47 -0500 (CDT) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 27866 Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-332568753-1565874107=:2070 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 15 Aug 2019, Martin Storsjö wrote: > > So, it basically boils down to, what the actual purpose of inspecting > dependency libs is (what real scenario does it protect from), as it breaks > linking to compiler_rt's builtins (which are referred to as an absolute path > to the .a file)? The purpose of inspecting dependency libs is that often code needs to be compiled with special options (e.g. for PIC code) in order to function in shared libraries or DLLs. Code which was compiled properly can be included in the shared library but code which lacks the necessary options needs to be saved for later and linked directly with the dependent program. Libtool's ".la" files contain enough information that libtool can make the correct decision when a dependent program is linked. If code which is not prepared for use in a shared library is included into the shared library, the linking may fail, or the program may crash, or run very inefficiently. Since clang is intended to be gcc compatible, it would be most useful for clang and its linker to emulate the GNU equivalents closely enough that existing build infrastructure does not need to change. Bob -- Bob Friesenhahn bfriesen@HIDDEN, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ---559023410-332568753-1565874107=:2070--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.Received: (at 27866) by debbugs.gnu.org; 15 Aug 2019 10:00:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 15 06:00:42 2019 Received: from localhost ([127.0.0.1]:50671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hyCYk-0007Of-FW for submit <at> debbugs.gnu.org; Thu, 15 Aug 2019 06:00:42 -0400 Received: from mail8.parnet.fi ([77.234.108.134]:25348) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <martin@HIDDEN>) id 1hyCYg-0007OU-Ca for 27866 <at> debbugs.gnu.org; Thu, 15 Aug 2019 06:00:40 -0400 Received: from mail7.parnet.fi (mail7.parnet.fi [77.234.108.28]) by mail8.parnet.fi with ESMTP id x7FA0Zoe024260-x7FA0Zog024260 (version=TLSv1.0 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 15 Aug 2019 13:00:35 +0300 Received: from foo.martin.st (host-96-177.parnet.fi [77.234.96.177]) by mail7.parnet.fi (8.13.8/8.13.8) with ESMTP id x7FA0YXR004258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Aug 2019 13:00:34 +0300 Date: Thu, 15 Aug 2019 13:00:33 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN> To: Manoj Gupta <manojgupta@HIDDEN> Subject: Re: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries In-Reply-To: <alpine.DEB.2.20.1908142339310.2829@HIDDEN> Message-ID: <alpine.DEB.2.20.1908151258290.2829@HIDDEN> References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN> <20180119221619.GM7217@vapier> <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN> <20180120015033.GE14915@vapier> <alpine.DEB.2.20.1802282253390.2163@HIDDEN> <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN> <alpine.DEB.2.20.1807231831380.20294@HIDDEN> <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN> <alpine.DEB.2.20.1908142339310.2829@HIDDEN> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1106129995-1565863235=:2829" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27866 Cc: Pavel Raiskup <praiskup@HIDDEN>, Mike Frysinger <vapier@HIDDEN>, 27866 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1106129995-1565863235=:2829 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 14 Aug 2019, Martin Storsjö wrote: > by manually setting this: > > lt_cv_deplibs_check_method=pass_all > > In other projects that don't set this, linking with libtool prints this > warning: > > *** Warning: Trying to link with static lib archive > C:/code/llvm-mingw/lib/clang/9.0.0/lib/windows/libclang_rt.builtins-x86_64.a. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have > *** because the file extensions .a of this argument makes me believe > *** that it is just a static archive that I should not use here. > > Manoj, did you run into this issue anywhere? I see that libtool always sets lt_cv_deplibs_check_method=pass_all on Linux, so that's probably why you haven't run into it. So, it basically boils down to, what the actual purpose of inspecting dependency libs is (what real scenario does it protect from), as it breaks linking to compiler_rt's builtins (which are referred to as an absolute path to the .a file)? // Martin --8323329-1106129995-1565863235=:2829--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.
Received: (at 27866) by debbugs.gnu.org; 14 Aug 2019 20:46:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 14 16:46:13 2019
Received: from localhost ([127.0.0.1]:49764 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1hy09s-0000R2-O6
for submit <at> debbugs.gnu.org; Wed, 14 Aug 2019 16:46:13 -0400
Received: from mail8.parnet.fi ([77.234.108.134]:45370)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <martin@HIDDEN>) id 1hy09p-0000Qk-Ie
for 27866 <at> debbugs.gnu.org; Wed, 14 Aug 2019 16:46:11 -0400
Received: from mail7.parnet.fi (mail7.parnet.fi [77.234.108.28])
by mail8.parnet.fi with ESMTP id x7EKk6wd028665-x7EKk6wf028665
(version=TLSv1.0 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Wed, 14 Aug 2019 23:46:06 +0300
Received: from foo.martin.st (host-96-177.parnet.fi [77.234.96.177])
by mail7.parnet.fi (8.13.8/8.13.8) with ESMTP id x7EKk5PK005276
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Wed, 14 Aug 2019 23:46:05 +0300
Date: Wed, 14 Aug 2019 23:46:04 +0300 (EEST)
From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN>
To: Manoj Gupta <manojgupta@HIDDEN>
Subject: Re: bug#27866: Handle clang's internal libraries when finding
compiler's internal libraries
In-Reply-To: <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN>
Message-ID: <alpine.DEB.2.20.1908142339310.2829@HIDDEN>
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
<20180119221619.GM7217@vapier>
<CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN>
<20180120015033.GE14915@vapier>
<alpine.DEB.2.20.1802282253390.2163@HIDDEN>
<CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN>
<alpine.DEB.2.20.1807231831380.20294@HIDDEN>
<CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-738303422-1565815566=:2829"
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 27866
Cc: Pavel Raiskup <praiskup@HIDDEN>, Mike Frysinger <vapier@HIDDEN>,
27866 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--8323329-738303422-1565815566=:2829
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Hi Manoj, Mike, Pavel and others,
While this isn't yet fixed upstream, I noted that this fix isn't enough
for me in mingw setups.
I've mostly been running into this issue in trying to compile VLC, where
this fix has been enough, but with other projects the issue remains. The
root cause for this seems to be that VLC overrides one libtool decision
here,
http://git.videolan.org/?p=vlc.git;a=blob;f=configure.ac;h=4aef56f06e3d16c8fe378055155126943d7ed69#l526
by manually setting this:
lt_cv_deplibs_check_method=pass_all
In other projects that don't set this, linking with libtool prints this
warning:
*** Warning: Trying to link with static lib archive C:/code/llvm-mingw/lib/clang/9.0.0/lib/windows/libclang_rt.builtins-x86_64.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because the file extensions .a of this argument makes me believe
*** that it is just a static archive that I should not use here.
Manoj, did you run into this issue anywhere?
I'm able to work around it by patching libtool to do essentially the same,
to set lt_cv_deplibs_check_method to pass_all, e.g. like this:
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index b55a6e57..c1eebf4c 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3487,17 +3487,7 @@ cygwin*)
;;
mingw* | pw32*)
- # Base MSYS/MinGW do not provide the 'file' command needed by
- # func_win32_libid shell function, so use a weaker test based on 'objdump',
- # unless we find 'file', for example because we are cross-compiling.
- if ( file / ) >/dev/null 2>&1; then
- lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
- lt_cv_file_magic_cmd='func_win32_libid'
- else
- # Keep this pattern in sync with the one in func_win32_libid.
- lt_cv_deplibs_check_method='file_magic file format (pei*-i386(.*architecture: i386)?|pe-arm-wince|pe-x86-64)'
- lt_cv_file_magic_cmd='$OBJDUMP -f'
- fi
+ lt_cv_deplibs_check_method=pass_all
;;
cegcc*)
However, this doesn't seem ideal. Is there any other way around it, to
link against a literal path to an .a file while building a shared library?
// Martin
On Mon, 23 Jul 2018, Manoj Gupta wrote:
> Mike,
>
> Do you know who can commit this?
>
> On Mon, Jul 23, 2018 at 8:33 AM, Martin Storsjö <martin@HIDDEN> wrote:
>> Mike and Manoj,
>>
>> Another gentle ping on this subject...
>>
>> // Martin
>>
>>
>> On Sat, 17 Mar 2018, Manoj Gupta wrote:
>>
>>> Mike,
>>> Any ideas who can commit this to upstream libtool?
>>>
>>> On Wed, Feb 28, 2018 at 12:55 PM, Martin Storsjö
>>> <martin@HIDDEN> wrote:
>>> On Fri, 19 Jan 2018, Mike Frysinger wrote:
>>>
>>> On 19 Jan 2018 17:34, Manoj
>>> Gupta wrote:
>>> I think that both .a
>>> and .so libraries
>>> should be handled
>>> here. Will
>>> *.${libext}
>>> handle both cases?
>>>
>>>
>>> libext is only "a". for shared
>>> libs, it can be calculated from
>>> shrext_cmds.
>>> eval
>>> std_shrext=\"$shrext_cmds\"
>>> -L* | -R* | -l* | *.${libext} |
>>> *${std_shrext})
>>>
>>> that would only support libs
>>> that end in ".so". but maybe
>>> that's OK.
>>>
>>>
>>> Gentle ping - I'm also running into this
>>> issue, and would like to have a canonical
>>> fix for it upstream.
>>>
>>> // Martin
>>>
>>>
>>>
>>
>
--8323329-738303422-1565815566=:2829--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.
Received: (at 27866) by debbugs.gnu.org; 23 Jul 2018 16:16:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 23 12:16:04 2018
Received: from localhost ([127.0.0.1]:54262 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1fhdVE-0007so-0b
for submit <at> debbugs.gnu.org; Mon, 23 Jul 2018 12:16:04 -0400
Received: from mail-ua0-f169.google.com ([209.85.217.169]:45354)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manojgupta@HIDDEN>) id 1fhdVB-0007s3-GO
for 27866 <at> debbugs.gnu.org; Mon, 23 Jul 2018 12:16:02 -0400
Received: by mail-ua0-f169.google.com with SMTP id k8-v6so773854uaq.12
for <27866 <at> debbugs.gnu.org>; Mon, 23 Jul 2018 09:16:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=zmu11DUwvtpVIOX8vnmWCufhWSFOjlijtG6WwEwBB0U=;
b=Uu2UisJPqQGHBGhscpdmN0eZgDr1IVB6SgD1uUkNhAO67jaAGoPjk2BisA9sGUfT7T
0CCwO33vjzlsZLmB0RXmwXTwanVePc/M5LZO4MbLasx3QdsW8LqgflHdVyIpRKzRY3o6
iScEXCo99xWsLuOfJ+NkZ5cClRzKW1/Ep2MzU=
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:content-transfer-encoding;
bh=zmu11DUwvtpVIOX8vnmWCufhWSFOjlijtG6WwEwBB0U=;
b=n7WLUqhZ3w3DPAA4U2KYVhf12/OlqO+dqZqFoRsZL4ffC/MiERPXc4iYlEO7Cd1Rop
EN5+1wbqlxYEmJHAj03FAHPTmseguYT6epIHccJ5+WGZrPUgxfOwl+/zPnyjM0NBL1do
h6aYv+zsVea7pcJM+8fmUjWDMhP2feVtv4PfvUp0YMiqSUjSPZn5zbLFBDCeASC3cypM
7JhNt3hCNDU22/DH0ZqXhBxfG9KkwzvVBy9Y9D5EnZvYzTm9g88ZIB1/NPZI4SUfUEHj
0IsbxpuMUqf5YFoIHdx5W2vEyl1NA9k0deAAdQJItg3+OhA+ZMWm8K72e40gHaiWN3Cm
8Ipg==
X-Gm-Message-State: AOUpUlG1oPxoGEFAhr2za6xqgxHS1Hc8dm9vVtTaj2ICInao7pqa8O4d
eipDrIbDFcDd4vcwTbjixcMrGW/xE1C2moOYYZHJtQ==
X-Google-Smtp-Source: AAOMgpeu063q3fo7jDl1p+OPdKyJ7CEquEtMB5JmJSK/n+Qmu28wAd0lCK0nuq4cuXN69SUO1C03DZXFMlbOHQJMkHk=
X-Received: by 2002:a9f:2187:: with SMTP id 7-v6mr9773977uac.49.1532362555741;
Mon, 23 Jul 2018 09:15:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab0:47e5:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 09:15:55
-0700 (PDT)
In-Reply-To: <alpine.DEB.2.20.1807231831380.20294@HIDDEN>
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
<20180119221619.GM7217@vapier>
<CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN>
<20180120015033.GE14915@vapier>
<alpine.DEB.2.20.1802282253390.2163@HIDDEN>
<CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN>
<alpine.DEB.2.20.1807231831380.20294@HIDDEN>
From: Manoj Gupta <manojgupta@HIDDEN>
Date: Mon, 23 Jul 2018 09:15:55 -0700
Message-ID: <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@HIDDEN>
Subject: Re: bug#27866: Handle clang's internal libraries when finding
compiler's internal libraries
To: =?UTF-8?Q?Martin_Storsj=C3=B6?= <martin@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 27866
Cc: 27866 <at> debbugs.gnu.org, Mike Frysinger <vapier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Mike,
Do you know who can commit this?
On Mon, Jul 23, 2018 at 8:33 AM, Martin Storsj=C3=B6 <martin@HIDDEN> wro=
te:
> Mike and Manoj,
>
> Another gentle ping on this subject...
>
> // Martin
>
>
> On Sat, 17 Mar 2018, Manoj Gupta wrote:
>
>> Mike,
>> Any ideas who can commit this to upstream libtool?
>>
>> On Wed, Feb 28, 2018 at 12:55 PM, Martin Storsj=C3=B6
>> <martin@HIDDEN> wrote:
>> On Fri, 19 Jan 2018, Mike Frysinger wrote:
>>
>> On 19 Jan 2018 17:34, Manoj
>> Gupta wrote:
>> I think that both .a
>> and .so libraries
>> should be handled
>> here. Will
>> *.${libext}
>> handle both cases?
>>
>>
>> libext is only "a". for shared
>> libs, it can be calculated from
>> shrext_cmds.
>> eval
>> std_shrext=3D\"$shrext_cmds\"
>> -L* | -R* | -l* | *.${libext} |
>> *${std_shrext})
>>
>> that would only support libs
>> that end in ".so". but maybe
>> that's OK.
>>
>>
>> Gentle ping - I'm also running into this
>> issue, and would like to have a canonical
>> fix for it upstream.
>>
>> // Martin
>>
>>
>>
>
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.
Received: (at 27866) by debbugs.gnu.org; 23 Jul 2018 15:33:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 23 11:33:32 2018
Received: from localhost ([127.0.0.1]:54243 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1fhcq4-0006rQ-CL
for submit <at> debbugs.gnu.org; Mon, 23 Jul 2018 11:33:32 -0400
Received: from mail6.parnet.fi ([77.234.108.70]:34797)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <martin@HIDDEN>) id 1fhcq2-0006rI-Ga
for 27866 <at> debbugs.gnu.org; Mon, 23 Jul 2018 11:33:31 -0400
Received: from mail7.parnet.fi (mail7.parnet.fi [77.234.108.28])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mail6.parnet.fi (XCS) with ESMTPS id C95AE2494B5F3638;
Mon, 23 Jul 2018 18:33:29 +0300 (EEST)
Received: from foo.martin.st (host-97-36.parnet.fi [77.234.97.36])
by mail7.parnet.fi (8.13.8/8.13.8) with ESMTP id w6NFXS7v016674
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Mon, 23 Jul 2018 18:33:28 +0300
Date: Mon, 23 Jul 2018 18:33:28 +0300 (EEST)
From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN>
To: Manoj Gupta <manojgupta@HIDDEN>
Subject: Re: bug#27866: Handle clang's internal libraries when finding
compiler's internal libraries
In-Reply-To: <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN>
Message-ID: <alpine.DEB.2.20.1807231831380.20294@HIDDEN>
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
<20180119221619.GM7217@vapier>
<CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN>
<20180120015033.GE14915@vapier>
<alpine.DEB.2.20.1802282253390.2163@HIDDEN>
<CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1302527676-1532360009=:20294"
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 27866
Cc: 27866 <at> debbugs.gnu.org, Mike Frysinger <vapier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--8323329-1302527676-1532360009=:20294
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Mike and Manoj,
Another gentle ping on this subject...
// Martin
On Sat, 17 Mar 2018, Manoj Gupta wrote:
> Mike,
> Any ideas who can commit this to upstream libtool?
>
> On Wed, Feb 28, 2018 at 12:55 PM, Martin Storsjö
> <martin@HIDDEN> wrote:
> On Fri, 19 Jan 2018, Mike Frysinger wrote:
>
> On 19 Jan 2018 17:34, Manoj
> Gupta wrote:
> I think that both .a
> and .so libraries
> should be handled
> here. Will
> *.${libext}
> handle both cases?
>
>
> libext is only "a". for shared
> libs, it can be calculated from
> shrext_cmds.
> eval
> std_shrext=\"$shrext_cmds\"
> -L* | -R* | -l* | *.${libext} |
> *${std_shrext})
>
> that would only support libs
> that end in ".so". but maybe
> that's OK.
>
>
> Gentle ping - I'm also running into this
> issue, and would like to have a canonical
> fix for it upstream.
>
> // Martin
>
>
>
>
--8323329-1302527676-1532360009=:20294--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.
Received: (at 27866) by debbugs.gnu.org; 18 Mar 2018 02:39:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 17 22:39:11 2018
Received: from localhost ([127.0.0.1]:38905 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1exOE3-0004WF-8A
for submit <at> debbugs.gnu.org; Sat, 17 Mar 2018 22:39:11 -0400
Received: from mail-wm0-f52.google.com ([74.125.82.52]:35697)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manojgupta@HIDDEN>) id 1exOE0-0004W2-PL
for 27866 <at> debbugs.gnu.org; Sat, 17 Mar 2018 22:39:09 -0400
Received: by mail-wm0-f52.google.com with SMTP id 5so9537935wmh.0
for <27866 <at> debbugs.gnu.org>; Sat, 17 Mar 2018 19:39:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=SnUyvfVQtlZA8WqfDe5jO8ZMFzCTGv9RxYH80T9oD+k=;
b=DNoFBQVOpVZ5CpOyYuW9pXhVAvvl03zjNLGW5r4Et5XQ3ZUu+GNT997IkuiZfqIYSF
cPwuv7wWh9lN1wPwuO+NY2EcMwUUucCb78DKAijEmBfKn2i8UZ1B236b5+AeGpHz9pkZ
ix7Igy/QtpoXQG17yVwfw7cVZqQQvX70MFKhw=
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=SnUyvfVQtlZA8WqfDe5jO8ZMFzCTGv9RxYH80T9oD+k=;
b=rUNgfsiqLzE+1JmFsjhXF1MrOHNsz3+a7NYY2YNHhe9vc3+pvlUHST3m7YKqFg8TlH
zInke648/qRpb1yLw8jkJiNQvFU1Mj21MrNATVhtSIMnTaPJ8cvHUk94K3ugX0Ltdc9G
m+ptr4aWohHSouIr1ULMAxssIyuRmFl682M2eCNsn6/tOF/SgBYOYwJypr4DnlyDt+m3
gvPmbS5zkHPXHPogjIxQfyQ/aj4u7TZzVm2vEl0BoIW9Gm7XGWTmbuGPF0LofB3sXm7b
6+AKd7dJfjwkSwpJpLQFJEzIyQX2yizCbApM8i9+BeARgN1CIGbW3MtEhpyTP62uVbQY
SNpg==
X-Gm-Message-State: AElRT7FBXSczteaCupFgE4RP1jee1ErcoZZzDjr+kor8EMO7R1/QGQbj
Y5pG8Lv4D9UeTWu1kaP31D16+yVn9JxO3UI3NleAHQ==
X-Google-Smtp-Source: AG47ELvRmrL8dVZ6RMdj6AQ3nZQlx861evUzP3Jsm+aA8thZhLVMwj1sZ6qdLGoksNdkHhmeqa7GGp3f6YKmyiSsQm0=
X-Received: by 10.28.215.67 with SMTP id o64mr5192049wmg.159.1521340742725;
Sat, 17 Mar 2018 19:39:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.171.76 with HTTP; Sat, 17 Mar 2018 19:39:02 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.20.1802282253390.2163@HIDDEN>
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
<20180119221619.GM7217@vapier>
<CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN>
<20180120015033.GE14915@vapier>
<alpine.DEB.2.20.1802282253390.2163@HIDDEN>
From: Manoj Gupta <manojgupta@HIDDEN>
Date: Sat, 17 Mar 2018 19:39:02 -0700
Message-ID: <CAAMbb07cJWrDkQa2Goo5O7vbyAXoVh61VGGa6k1raHZUbXdc=Q@HIDDEN>
Subject: Re: bug#27866: Handle clang's internal libraries when finding
compiler's internal libraries
To: =?UTF-8?Q?Martin_Storsj=C3=B6?= <martin@HIDDEN>
Content-Type: multipart/alternative; boundary="001a114676748d81a50567a6be81"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 27866
Cc: 27866 <at> debbugs.gnu.org, Mike Frysinger <vapier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
--001a114676748d81a50567a6be81
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Mike,
Any ideas who can commit this to upstream libtool?
On Wed, Feb 28, 2018 at 12:55 PM, Martin Storsj=C3=B6 <martin@HIDDEN> wr=
ote:
> On Fri, 19 Jan 2018, Mike Frysinger wrote:
>
> On 19 Jan 2018 17:34, Manoj Gupta wrote:
>>
>>> I think that both .a and .so libraries should be handled here. Will
>>> *.${libext}
>>> handle both cases?
>>>
>>
>> libext is only "a". for shared libs, it can be calculated from
>> shrext_cmds.
>> eval std_shrext=3D\"$shrext_cmds\"
>> -L* | -R* | -l* | *.${libext} | *${std_shrext})
>>
>> that would only support libs that end in ".so". but maybe that's OK.
>>
>
> Gentle ping - I'm also running into this issue, and would like to have a
> canonical fix for it upstream.
>
> // Martin
>
--001a114676748d81a50567a6be81
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Mike,<div><br></div><div>Any ideas who can commit this to =
upstream libtool?</div></div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Wed, Feb 28, 2018 at 12:55 PM, Martin Storsj=C3=B6 <span dir=
=3D"ltr"><<a href=3D"mailto:martin@HIDDEN" target=3D"_blank">martin@m=
artin.st</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">On Fri, 19 Jan 2018, Mike Frysinger wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 19 Jan 2018 17:34, Manoj Gupta wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I think that both .a and .so libraries should be handled here. Will *.${lib=
ext}<br>
handle both cases?<br>
</blockquote>
<br>
libext is only "a".=C2=A0 for shared libs, it can be calculated f=
rom shrext_cmds.<br>
=C2=A0eval std_shrext=3D\"$shrext_cmds\"<br>
=C2=A0-L* | -R* | -l* | *.${libext} | *${std_shrext})<br>
<br>
that would only support libs that end in ".so".=C2=A0 but maybe t=
hat's OK.<br>
</blockquote>
<br></span>
Gentle ping - I'm also running into this issue, and would like to have =
a canonical fix for it upstream.<span class=3D"HOEnZb"><font color=3D"#8888=
88"><br>
<br>
// Martin<br>
</font></span></blockquote></div><br></div>
--001a114676748d81a50567a6be81--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.
Received: (at 27866) by debbugs.gnu.org; 28 Feb 2018 21:12:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 28 16:12:56 2018
Received: from localhost ([127.0.0.1]:37923 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1er920-0006Uc-8E
for submit <at> debbugs.gnu.org; Wed, 28 Feb 2018 16:12:56 -0500
Received: from mail7.parnet.fi ([77.234.108.28]:42741)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <martin@HIDDEN>) id 1er8lS-00065O-6B
for 27866 <at> debbugs.gnu.org; Wed, 28 Feb 2018 15:55:51 -0500
Received: from foo.martin.st (host-97-36.parnet.fi [77.234.97.36])
by mail7.parnet.fi (8.13.8/8.13.8) with ESMTP id w1SKtlul024294
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Wed, 28 Feb 2018 22:55:47 +0200
Date: Wed, 28 Feb 2018 22:55:47 +0200 (EET)
From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@HIDDEN>
To: Mike Frysinger <vapier@HIDDEN>
Subject: Re: bug#27866: Handle clang's internal libraries when finding
compiler's internal libraries
In-Reply-To: <20180120015033.GE14915@vapier>
Message-ID: <alpine.DEB.2.20.1802282253390.2163@HIDDEN>
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
<20180119221619.GM7217@vapier>
<CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN>
<20180120015033.GE14915@vapier>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 27866
X-Mailman-Approved-At: Wed, 28 Feb 2018 16:12:54 -0500
Cc: Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)
On Fri, 19 Jan 2018, Mike Frysinger wrote:
> On 19 Jan 2018 17:34, Manoj Gupta wrote:
>> I think that both .a and .so libraries should be handled here. Will *.${libext}
>> handle both cases?
>
> libext is only "a". for shared libs, it can be calculated from shrext_cmds.
> eval std_shrext=\"$shrext_cmds\"
> -L* | -R* | -l* | *.${libext} | *${std_shrext})
>
> that would only support libs that end in ".so". but maybe that's OK.
Gentle ping - I'm also running into this issue, and would like to have a
canonical fix for it upstream.
// Martin
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.
Received: (at 27866) by debbugs.gnu.org; 20 Jan 2018 01:50:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 19 20:50:42 2018
Received: from localhost ([127.0.0.1]:35418 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1eciIs-0006wb-1n
for submit <at> debbugs.gnu.org; Fri, 19 Jan 2018 20:50:42 -0500
Received: from smtp.gentoo.org ([140.211.166.183]:45728)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <vapier@HIDDEN>) id 1eciIq-0006wM-9t
for 27866 <at> debbugs.gnu.org; Fri, 19 Jan 2018 20:50:40 -0500
Received: from vapier (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with SMTP id B896A335C31;
Sat, 20 Jan 2018 01:50:33 +0000 (UTC)
Date: Fri, 19 Jan 2018 20:50:33 -0500
From: Mike Frysinger <vapier@HIDDEN>
To: Manoj Gupta <manojgupta@HIDDEN>
Subject: Re: bug#27866: Handle clang's internal libraries when finding
compiler's internal libraries
Message-ID: <20180120015033.GE14915@vapier>
Mail-Followup-To: Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
<20180119221619.GM7217@vapier>
<CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="HWvPVVuAAfuRc6SZ"
Content-Disposition: inline
In-Reply-To: <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN>
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 27866
Cc: 27866 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)
--HWvPVVuAAfuRc6SZ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
On 19 Jan 2018 17:34, Manoj Gupta wrote:
> I think that both .a and .so libraries should be handled here. Will *.${libext}
> handle both cases?
libext is only "a". for shared libs, it can be calculated from shrext_cmds.
eval std_shrext=\"$shrext_cmds\"
-L* | -R* | -l* | *.${libext} | *${std_shrext})
that would only support libs that end in ".so". but maybe that's OK.
-mike
--HWvPVVuAAfuRc6SZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAlpioGkACgkQQWM7n+g3
9YGd4Q//dFeWXYLRa/NDK8abkLLMMZaeNpws7Sln7+t8WAL3dZdeuejq0eVeVHy9
oanmLZIOSMcJk6c/+umpPvDRerXeZ+989uukDYWanhWk5fGXVsYHHYKOUjOiQWq1
AJm1mGAuT4OG5WMztriUPZf4XIrAcZUfpH5DFQb3yaHqtOHEASNwYZCQ0TboDrk5
XUvz1WCpSHU8330JTZ0ZpnRbpy68wokJdD4f9FfdFJEz4WXY5nyrcMInxsvIXn5B
KcB5r4GAZgjubydtMYIENKmmsffkbIy9G4jtY9Fb7QMXauaXut85YDNqb9sdT7T9
GvBwFDCk9+9YT4F/QN6JrZlTD9E9Ep3UNzFFK913SDFq/7ZhdXle9fjWlXBxQQTY
OM9TXWqeu8Ey2yuBIgCQT/tkGOY51Xc6liIKG1W2ZyyrP5hnR+NF/xIUl6Uq+Toy
zsz+Lmay0ddZuUyBnttVnc7jyG5Q2XP0RNweGdE18ddK5NjgWZ01M139/yPSbdYt
6h3Hlpl2IDPWpD2YBWlJ5rJgOZgdTS/6s9PPEBBoIyzRMnK5jwliFEQV5F+3cgMM
Uam8OA7J3HFs9eXfW/HzI3RVZPZuv65miEhez1YCfW/jg0RxRgg8gEXVxTPKjxP8
UistSgkixYnpIjyBDKPcAkDW90SZGJV05tHyaZPVWctIRcIaWlA=
=9Ecq
-----END PGP SIGNATURE-----
--HWvPVVuAAfuRc6SZ--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.
Received: (at 27866) by debbugs.gnu.org; 20 Jan 2018 01:35:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 19 20:35:06 2018
Received: from localhost ([127.0.0.1]:35414 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1eci3m-0006bA-DT
for submit <at> debbugs.gnu.org; Fri, 19 Jan 2018 20:35:06 -0500
Received: from mail-wr0-f172.google.com ([209.85.128.172]:40890)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manojgupta@HIDDEN>) id 1eci3k-0006aW-OY
for 27866 <at> debbugs.gnu.org; Fri, 19 Jan 2018 20:35:05 -0500
Received: by mail-wr0-f172.google.com with SMTP id 100so3118565wrb.7
for <27866 <at> debbugs.gnu.org>; Fri, 19 Jan 2018 17:35:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=aONODDchTYhiOOzKS8Don3HlXIrECy9aazWuzw/vKxw=;
b=k3BM8yEU01Szt4oeJZBeiqzNZ3xmCf1U1BxJp3X4AbJTQKlbib60E1H1jAcAOKzEXz
6Lv1pYs5UEEz8SByNm8tVIksavo47Bg1VMOvKdujqr0eoINF9K0SZO8kDonnSTI5/RqO
ooEPESwsG86PnDnx7AyDVun3FOdhwYoDGAnOg=
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;
bh=aONODDchTYhiOOzKS8Don3HlXIrECy9aazWuzw/vKxw=;
b=pHalsSho+fg9jWamPbyhCuQ3myuUB/tI5EgbZzCbwAdOUqj9m9jIhVxU/Fm3PT3YU+
LvylWhO49w6PG4gUfPUZJp9Er8tRJ4kEyKYKm1BbMzeObDPkmMZFn3KsQdxVX8OAiR9f
AlGoMG1Ee0ikNYevPmIPVrJ+X0uJGWT7XEmYOsDv9BHOXDzf+rXMa0Dz/NORVbst4IrY
B2ICsL05RfEZ56aLuFhUbO3uKdA9CR+rmJOv/WQKH1ZcP79di1n2GAhaYG1zCXE0MI/z
2e5pU1oHp4bPB3WHnNK6qoBOZGLA5pUilhsIPTOy9xJH+0H1Xv0P/MByEomYJhAIYQTY
DdjQ==
X-Gm-Message-State: AKwxytcXONT0ID2m+v7xAc3t4iae51pU+T9mLihQ8oZMJkWNtDRlI4KU
ZyH+nqcYvoLYNZhYeaw21Iq8BjCB62wu5V/ZMaDIWg==
X-Google-Smtp-Source: AH8x2274XqdQbxntr7Sk7fkX/BWTJWkNYmejFIXoGBAsVd6OWRK2g5ddYwv7tsHv7yOo6bKe7r5PyVD0Z7MNa9SaUGc=
X-Received: by 10.223.164.86 with SMTP id e22mr276955wra.19.1516412099022;
Fri, 19 Jan 2018 17:34:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.164.201 with HTTP; Fri, 19 Jan 2018 17:34:58 -0800 (PST)
In-Reply-To: <20180119221619.GM7217@vapier>
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
<20180119221619.GM7217@vapier>
From: Manoj Gupta <manojgupta@HIDDEN>
Date: Fri, 19 Jan 2018 17:34:58 -0800
Message-ID: <CAAMbb076HLyhPLb32BpgUiYbeUDZo+GYnwma9DRwRnud+PF5Mg@HIDDEN>
Subject: Re: bug#27866: Handle clang's internal libraries when finding
compiler's internal libraries
To: Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="f403045f1bd67ee70605632b3471"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 27866
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
--f403045f1bd67ee70605632b3471
Content-Type: text/plain; charset="UTF-8"
I think that both .a and .so libraries should be handled here. Will *.${libext}
handle both cases?
On Fri, Jan 19, 2018 at 2:16 PM, Mike Frysinger <vapier@HIDDEN> wrote:
> On 28 Jul 2017 13:36, Manoj Gupta wrote:
> > This is Manoj working on ChromeOS. I am facing a problem trying to build
> it
> > with clang with its own internal library (compiler-rt) since some
> packages
> > like mesa fail to build. The root cause is clang uses an absolute path to
> > link its internal libraries which libtool does not recognize.
> >
> > e.g. clang++ -rtlib=compiler-rt main.cpp -v shows use of
> > /usr/lib64/clang/5.0.0/lib/linux/libclang_rt.builtins-x86_64.a
> >
> > Libtool currently relies on "-lname" pattern to find the internal
> > libraries. And this does not work if some code is compiled using +
> > compiler-rt.
> > The issue was discovered in building mesa graphics library which uses
> > -nostdlib flag and relies on libtool to pass the additionally required
> > compiler internal libraries.
> >
> > I have a sample fix below for fixing this for clang.
> >
> > +--- a/m4/libtool.m4
> > ++++ b/m4/libtool.m4
> > +@@ -7531,7 +7544,7 @@
> > + for p in `eval "$output_verbose_link_cmd"`; do
> > + case $prev$p in
> > +
> > +- -L* | -R* | -l*)
> > ++ -L* | -R* | -l* | *clang_rt*.a)
> > + # Some compilers place space between "-{L,R}" and the path.
> > + # Remove the space.
> > + if test x-L = "$p" ||
> > +
>
> i don't think hardcoding any specific library is correct, especially with
> an expansive glob like this.
>
> i wonder if leveraging libext would be a bad idea here.
> -L* | -R* | -l* | *.${libext})
> -mike
>
--f403045f1bd67ee70605632b3471
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think that both .a and .so libraries should be handled h=
ere. Will=C2=A0<span style=3D"font-size:12.8px">*.${libext} handle both cas=
es?</span></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n Fri, Jan 19, 2018 at 2:16 PM, Mike Frysinger <span dir=3D"ltr"><<a hre=
f=3D"mailto:vapier@HIDDEN" target=3D"_blank">vapier@HIDDEN</a>><=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">On 28 Jul 2017 13:36, Manoj=
Gupta wrote:<br>
> This is Manoj working on ChromeOS. I am facing a problem trying to bui=
ld it<br>
> with clang with its own internal library (compiler-rt) since some pack=
ages<br>
> like mesa fail to build. The root cause is clang uses an absolute path=
to<br>
> link its internal libraries which libtool does not recognize.<br>
><br>
> e.g. clang++ -rtlib=3Dcompiler-rt main.cpp -v shows use of<br>
> /usr/lib64/clang/5.0.0/lib/<wbr>linux/libclang_rt.builtins-<wbr>x86_64=
.a<br>
><br>
> Libtool currently relies on "-lname" pattern to find the int=
ernal<br>
> libraries. And this does not work if some code is compiled using +<br>
> compiler-rt.<br>
> The issue was discovered in building mesa graphics library which uses<=
br>
> -nostdlib flag=C2=A0 and relies on libtool to pass the additionally re=
quired<br>
> compiler internal libraries.<br>
><br>
> I have a sample fix below for fixing this for clang.<br>
><br>
> +--- a/m4/libtool.m4<br>
> ++++ b/m4/libtool.m4<br>
> +@@ -7531,7 +7544,7 @@<br>
> +=C2=A0 =C2=A0for p in `eval "$output_verbose_link_cmd"`; do=
<br>
> +=C2=A0 =C2=A0 =C2=A0case $prev$p in<br>
> +<br>
> +-=C2=A0 =C2=A0 -L* | -R* | -l*)<br>
> ++=C2=A0 =C2=A0 -L* | -R* | -l* | *clang_rt*.a)<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 # Some compilers place space between &quo=
t;-{L,R}" and the path.<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 # Remove the space.<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 if test x-L =3D "$p" ||<br>
> +<br>
<br>
i don't think hardcoding any specific library is correct, especially wi=
th<br>
an expansive glob like this.<br>
<br>
i wonder if leveraging libext would be a bad idea here.<br>
=C2=A0 =C2=A0 -L* | -R* | -l* | *.${libext})<br>
<span class=3D"HOEnZb"><font color=3D"#888888">-mike<br>
</font></span></blockquote></div><br></div>
--f403045f1bd67ee70605632b3471--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.
Received: (at 27866) by debbugs.gnu.org; 19 Jan 2018 22:16:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 19 17:16:29 2018
Received: from localhost ([127.0.0.1]:35331 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ecexY-0001Qg-Sj
for submit <at> debbugs.gnu.org; Fri, 19 Jan 2018 17:16:29 -0500
Received: from smtp.gentoo.org ([140.211.166.183]:60212)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <vapier@HIDDEN>) id 1ecexW-0001QM-Jw
for 27866 <at> debbugs.gnu.org; Fri, 19 Jan 2018 17:16:27 -0500
Received: from vapier (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with SMTP id 0268A335C07;
Fri, 19 Jan 2018 22:16:19 +0000 (UTC)
Date: Fri, 19 Jan 2018 17:16:19 -0500
From: Mike Frysinger <vapier@HIDDEN>
To: Manoj Gupta <manojgupta@HIDDEN>
Subject: Re: bug#27866: Handle clang's internal libraries when finding
compiler's internal libraries
Message-ID: <20180119221619.GM7217@vapier>
Mail-Followup-To: Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="8m/hfNLtAhX2NvnO"
Content-Disposition: inline
In-Reply-To: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 27866
Cc: 27866 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)
--8m/hfNLtAhX2NvnO
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 28 Jul 2017 13:36, Manoj Gupta wrote:
> This is Manoj working on ChromeOS. I am facing a problem trying to build =
it
> with clang with its own internal library (compiler-rt) since some packages
> like mesa fail to build. The root cause is clang uses an absolute path to
> link its internal libraries which libtool does not recognize.
>=20
> e.g. clang++ -rtlib=3Dcompiler-rt main.cpp -v shows use of
> /usr/lib64/clang/5.0.0/lib/linux/libclang_rt.builtins-x86_64.a
>=20
> Libtool currently relies on "-lname" pattern to find the internal
> libraries. And this does not work if some code is compiled using +
> compiler-rt.
> The issue was discovered in building mesa graphics library which uses
> -nostdlib flag and relies on libtool to pass the additionally required
> compiler internal libraries.
>=20
> I have a sample fix below for fixing this for clang.
>=20
> +--- a/m4/libtool.m4
> ++++ b/m4/libtool.m4
> +@@ -7531,7 +7544,7 @@
> + for p in `eval "$output_verbose_link_cmd"`; do
> + case $prev$p in
> +
> +- -L* | -R* | -l*)
> ++ -L* | -R* | -l* | *clang_rt*.a)
> + # Some compilers place space between "-{L,R}" and the path.
> + # Remove the space.
> + if test x-L =3D "$p" ||
> +
i don't think hardcoding any specific library is correct, especially with
an expansive glob like this.
i wonder if leveraging libext would be a bad idea here.
-L* | -R* | -l* | *.${libext})
-mike
--8m/hfNLtAhX2NvnO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAlpibjMACgkQQWM7n+g3
9YFyQQ/8Cug7ZUs1wlhJ3XdGsH06shOjM18iyNKNX3CHsN7A0F41H2G/7/3qAaCt
3WumkJH+NMXGD+MtQVLNzpXpJWB9loz9PQ7MuPyV11v78h1AP13aSTj9HarY1d41
OjF+wSQzIDuCT9QfNejI/p2C3NKUhr4KA1FJ8QxL4OrrMCLhJ9ySZzKYhnPK1Op9
EIr103h322lHIJ95GFq3gMo/7d3cdqUEixZ2YufgnVsiVbjoanrsAPZ7QKgZ6p76
CgOq2wl0YeML+WXR6rjqyBiC1FvBdA7/oEhu4p2Xc1npbpbpOmQPZ9+KW2xRrngd
jCm9WZe/oJGAM+Z2ru7p+AZhCdS08ewpPI4EiorH1ktHSrGgN4xq0YCMYvhhuPiO
0bXGnOOhIo53HcvLlXNMDTEcUrsldrpM7W40SToiUvUrghAiRbs12d+r4cElqqbT
dd9MxBs9yFVtFc+Y8omF+6C+sFoIekq52BjGoKlYHU+CntaMf5UL56HP9yOSYFd/
SFS+cgVP6fLcy10dSa/yuWh4RaSXnZvRMFR6TGmbsqucFij/q2YePcOaN0iytRYQ
XRwUfFoEd1kEeeev8qT829jaL89B3uenGaVDq8hH6/kkhNBbiNR4djJ7ss5Tfz9v
qoPDxWUr3CWJRgbdLwMvXh/aVZDTJ5h0QX3WKMAo3n60/HygZik=
=GRQx
-----END PGP SIGNATURE-----
--8m/hfNLtAhX2NvnO--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.Received: (at 27866) by debbugs.gnu.org; 19 Jan 2018 00:49:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 18 19:49:31 2018 Received: from localhost ([127.0.0.1]:33882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ecKs7-0001GR-Al for submit <at> debbugs.gnu.org; Thu, 18 Jan 2018 19:49:31 -0500 Received: from mail-wr0-f181.google.com ([209.85.128.181]:38186) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manojgupta@HIDDEN>) id 1ecKmi-00017s-Cn for 27866 <at> debbugs.gnu.org; Thu, 18 Jan 2018 19:43:56 -0500 Received: by mail-wr0-f181.google.com with SMTP id x1so48610wrb.5 for <27866 <at> debbugs.gnu.org>; Thu, 18 Jan 2018 16:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=rwNLC7m+0vKlMKZIQo9vt/AjtC4V6ezx2doBeoaiWwo=; b=KLbIrViOp7wtWizKPUm+bP8s+wMMRKKeD3+I7OxRCTtHDVqCMaOWLaQRWZ47xPJ33y RZabgOhSXetL6Jw8q2Seu/e8Qd4k7TdP2OtHIfocsKWH1v9jd+nUBhmAItOjfB5ZHoge 72nqSbXqKS+nj32IVUp86XOFq7Qstj+OjwW30= 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; bh=rwNLC7m+0vKlMKZIQo9vt/AjtC4V6ezx2doBeoaiWwo=; b=NQyK6OaxCh6RzL7oPICfnnBh50UYI+DAVAMwUYnadqTBZzyWzLxLDqKyFxIt7O3ry4 oAYq7ex1oMG0GkPyGOIaY6lsnLTWqQ88x7V+EBagOUWYDaW/XzOQNzuL5EkApC8xH3qj la8g0GhZe/fcvO5ijmx6DomQUasaUZ3rhq6Tkb9asIeoTWtSpE6SEg1zFsteO95E05rt Zr/bwIaNbmsu5JqPCI3krjDrqL+ygXvRKuuD1ggFB9pPxJ6bYsjIpXZLlU99iCB9t3dZ /rvFyaxcJrSbqIGEO7QTrtamlZw5+o2vwWr68dLMMCe58rj+6GYdDOjj+MJT89774vOD Rmcw== X-Gm-Message-State: AKwxytcw3Fu1FH7d33dBtoBJe60VnHAk/ReFhLoJc3BaNxJvFw9/X0lz QGdVgf27ifXFsxLOal68xqb5ZYg0UtmsZOw+mN9RTlGh X-Google-Smtp-Source: ACJfBosRpFR62EPi7eL8+JksY3O8lSEdIRP07uEvoKhjPtqWbKQ7aqFb/HGdSzNLWF5LJ34z3WJe2DY8itAfDCnMReA= X-Received: by 10.223.148.38 with SMTP id 35mr8256778wrq.127.1516322630531; Thu, 18 Jan 2018 16:43:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.177.2 with HTTP; Thu, 18 Jan 2018 16:43:50 -0800 (PST) In-Reply-To: <CAAMbb04cvjrMh=R7=SK0_PcUWq_WHXxgBG9jwsh+O8v0yuwzpg@HIDDEN> References: <CAAMbb04cvjrMh=R7=SK0_PcUWq_WHXxgBG9jwsh+O8v0yuwzpg@HIDDEN> From: Manoj Gupta <manojgupta@HIDDEN> Date: Thu, 18 Jan 2018 16:43:50 -0800 Message-ID: <CAAMbb04Co-xpJcARSNgyZ63q9MJFqbvKt23M98ba8bZqCipk8g@HIDDEN> Subject: Re: Updated patch to make the match less expensive To: 27866 <at> debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a114cb408c210860563165fec" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 27866 X-Mailman-Approved-At: Thu, 18 Jan 2018 19:49:29 -0500 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) --001a114cb408c210860563165fec Content-Type: text/plain; charset="UTF-8" Friendly ping. This issue keeps on biting us since many packages ship a copy of libtool.m4 file. Can some one look at the patch? Thanks, --001a114cb408c210860563165fec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">Frie= ndly ping.</div><div class=3D"gmail_quote">This issue keeps on biting us si= nce many packages ship a copy of libtool.m4 file. Can some one look at the = patch?</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"= >Thanks,</div><br></div></div> --001a114cb408c210860563165fec--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.
Received: (at 27866) by debbugs.gnu.org; 28 Jul 2017 21:57:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 28 17:57:56 2017
Received: from localhost ([127.0.0.1]:60444 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1dbDGd-0002TJ-Sz
for submit <at> debbugs.gnu.org; Fri, 28 Jul 2017 17:57:56 -0400
Received: from mail-io0-f175.google.com ([209.85.223.175]:36463)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manojgupta@HIDDEN>) id 1dbDFp-0002Rd-Tb
for 27866 <at> debbugs.gnu.org; Fri, 28 Jul 2017 17:57:06 -0400
Received: by mail-io0-f175.google.com with SMTP id g35so61820690ioi.3
for <27866 <at> debbugs.gnu.org>; Fri, 28 Jul 2017 14:57:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google;
h=mime-version:from:date:message-id:subject:to;
bh=rPm+F6Efsxl3DzZB0jv6t03t3B2zUpuWSMktkGm4J/s=;
b=XQmjjqCq/+x40W1cX9jt8fv1GlLzTTlE/tofc4MSZcm7CLtSGy6CaLsWzuUZd9p05M
0hIdgXRHczQbiKT3jh0U+xi2Ey8T2KSGKFvw6+IJvaqauMYlKZx3EaeHXa4eRXFrjR8s
8aQvo9guBIBTNTf5Oqq67aR2ZzqTu4AyAUtQE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=rPm+F6Efsxl3DzZB0jv6t03t3B2zUpuWSMktkGm4J/s=;
b=hUtrEDI1MrctdP0xR+4mIlH59Ksr9TXi/3j6jBfcv9+t0ZwQEi/V20UFq2yYS2KvCO
tlMCYkMRmFwoZreibNms8kiuV6PBDQU5RuEddVwknq6Odvp/yiy5LiitltMeaTsXg6U6
9n32cBuL7BPWngH1rBIP277P7wqUAUSPBmoGSsQ9YHr4XcYZx6i7mknIs5FdgyI8x2Vz
caVdLBJl/mE07WFh+eHV6hZAFbu+q8Csi8aWU0/9HBlGpNe037Rn3r5xnioP4IBopMCO
T/uxgRdrQbGI5O5NAZkreHYN4DSMiqVKQ3sq5HWEwVtzcsd2yYafvJTS59fGKU3eNGNq
9enA==
X-Gm-Message-State: AIVw110TYrI434HV4cxDc0HaZUsXvwnkFvtsxPEyOZRCzxgwkCv699Oh
T5S2xWh03QKEGA1+7O58Y7Om2oT+mfYhOl/dDw==
X-Received: by 10.107.161.206 with SMTP id k197mr10409132ioe.91.1501279020044;
Fri, 28 Jul 2017 14:57:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.162.65 with HTTP; Fri, 28 Jul 2017 14:56:59 -0700 (PDT)
From: Manoj Gupta <manojgupta@HIDDEN>
Date: Fri, 28 Jul 2017 14:56:59 -0700
Message-ID: <CAAMbb04cvjrMh=R7=SK0_PcUWq_WHXxgBG9jwsh+O8v0yuwzpg@HIDDEN>
Subject: Updated patch to make the match less expensive
To: 27866 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="001a1140f988b2e607055567c2dd"
X-Spam-Score: -2.8 (--)
X-Debbugs-Envelope-To: 27866
X-Mailman-Approved-At: Fri, 28 Jul 2017 17:57:54 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.8 (--)
--001a1140f988b2e607055567c2dd
Content-Type: text/plain; charset="UTF-8"
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -7531,7 +7544,7 @@
for p in `eval "$output_verbose_link_cmd"`; do
case $prev$p in
- -L* | -R* | -l*)
+ -L* | -R* | -l* | */libclang_rt.*.a)
# Some compilers place space between "-{L,R}" and the path.
# Remove the space.
if test x-L = "$p" ||
--001a1140f988b2e607055567c2dd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>--- a/m4/libtool.m4</div><div>+++ b/m4/libtool.m4</di=
v><div>@@ -7531,7 +7544,7 @@</div><div>=C2=A0 =C2=A0for p in `eval "$o=
utput_verbose_link_cmd"`; do</div><div>=C2=A0 =C2=A0 =C2=A0case $prev$=
p in</div><div><br></div><div>- =C2=A0 =C2=A0-L* | -R* | -l*)</div><div>+ =
=C2=A0 =C2=A0-L* | -R* | -l* | */libclang_rt.*.a)</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 # Some compilers place space between "-{L,R}" and t=
he path.</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 # Remove the space.</div><di=
v>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if test x-L =3D "$p" ||</div></div>
--001a1140f988b2e607055567c2dd--
bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.
Received: (at submit) by debbugs.gnu.org; 28 Jul 2017 21:04:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 28 17:04:26 2017
Received: from localhost ([127.0.0.1]:60410 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1dbCQr-0001Ej-2t
for submit <at> debbugs.gnu.org; Fri, 28 Jul 2017 17:04:26 -0400
Received: from eggs.gnu.org ([208.118.235.92]:33895)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manojgupta@HIDDEN>) id 1dbC0H-0000RU-68
for submit <at> debbugs.gnu.org; Fri, 28 Jul 2017 16:36:57 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <manojgupta@HIDDEN>) id 1dbC0A-0001lq-HT
for submit <at> debbugs.gnu.org; Fri, 28 Jul 2017 16:36:51 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
T_DKIM_INVALID autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:51336)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
(Exim 4.71) (envelope-from <manojgupta@HIDDEN>)
id 1dbC0A-0001ll-EH
for submit <at> debbugs.gnu.org; Fri, 28 Jul 2017 16:36:50 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:53088)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <manojgupta@HIDDEN>) id 1dbC08-0001Qt-RS
for bug-libtool@HIDDEN; Fri, 28 Jul 2017 16:36:50 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <manojgupta@HIDDEN>) id 1dbC07-0001kG-J7
for bug-libtool@HIDDEN; Fri, 28 Jul 2017 16:36:48 -0400
Received: from mail-io0-x22c.google.com ([2607:f8b0:4001:c06::22c]:33316)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
(Exim 4.71) (envelope-from <manojgupta@HIDDEN>)
id 1dbC07-0001jA-Bm
for bug-libtool@HIDDEN; Fri, 28 Jul 2017 16:36:47 -0400
Received: by mail-io0-x22c.google.com with SMTP id j32so73235150iod.0
for <bug-libtool@HIDDEN>; Fri, 28 Jul 2017 13:36:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google;
h=mime-version:from:date:message-id:subject:to;
bh=8cRYrT0jDHUT9tFee80gAKmX3Zw9/h7G36AWYM5ncPk=;
b=D7rekQ6REtRXuqA/r3wJcOeJ60vUbVYJ0JZgHfLaj6ifegp/hRqe/yi7HGfje84K+c
ps7KXLZpXHe6xK1iL012DpyPkVCW5/q0CnoJiQ/r6YdoIBbGAOGj57htD1hYiVy74rp5
9iyhH6Ll2WSsSdZ0640HY+Zwoka5cY1JJ08Ro=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=8cRYrT0jDHUT9tFee80gAKmX3Zw9/h7G36AWYM5ncPk=;
b=Rxg6clY/einJ0LqvLMdkVcFpRlohQ6LFUcdgyrkrlh7LtYGKKFRKC7uB83HF/GB905
OBJ+kyCfsfLsxs/nm1e/j2BK+lUYoLYwK0jrB8WOy/OMrGwkX83Mhg4qGeu8JdpWEc6/
cQcGTSrJ9rYLDeH/1bJ1vCjmqZUVxc/3zFE+qloh6GOL8sjfjKKnHTYCsxsiT85kMmHw
xQFZGzQ9j6udBoXuHWSe4elv06rag2lRRy9tg9XVcq9msk/bR39FNVSWN5E7PgiMbSQC
Ch5x50uY8mF9iifeXf7vpVQQUqkUIlRMiKxhcR4wehh5z3XIP7AkuWB20yrNqa1zRDMY
BN4g==
X-Gm-Message-State: AIVw111iHaqvos8+BgkmFidFwhAQ2qd1mHofXcx8EobU4QHL49+gCqwh
9YdlKps4vbf0GSCNt4CK9PblpKMtonjPnLPVWA==
X-Received: by 10.107.161.206 with SMTP id k197mr10178018ioe.91.1501274203683;
Fri, 28 Jul 2017 13:36:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.162.65 with HTTP; Fri, 28 Jul 2017 13:36:43 -0700 (PDT)
From: Manoj Gupta <manojgupta@HIDDEN>
Date: Fri, 28 Jul 2017 13:36:43 -0700
Message-ID: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
Subject: Handle clang's internal libraries when finding compiler's internal
libraries
To: bug-libtool@HIDDEN
Content-Type: multipart/alternative; boundary="001a1140f9889f11d5055566a301"
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
recognized.
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.3 (----)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Fri, 28 Jul 2017 17:04:24 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.3 (----)
--001a1140f9889f11d5055566a301
Content-Type: text/plain; charset="UTF-8"
Hi,
This is Manoj working on ChromeOS. I am facing a problem trying to build it
with clang with its own internal library (compiler-rt) since some packages
like mesa fail to build. The root cause is clang uses an absolute path to
link its internal libraries which libtool does not recognize.
e.g. clang++ -rtlib=compiler-rt main.cpp -v shows use of
/usr/lib64/clang/5.0.0/lib/linux/libclang_rt.builtins-x86_64.a
Libtool currently relies on "-lname" pattern to find the internal
libraries. And this does not work if some code is compiled using +
compiler-rt.
The issue was discovered in building mesa graphics library which uses
-nostdlib flag and relies on libtool to pass the additionally required
compiler internal libraries.
I have a sample fix below for fixing this for clang.
+--- a/m4/libtool.m4
++++ b/m4/libtool.m4
+@@ -7531,7 +7544,7 @@
+ for p in `eval "$output_verbose_link_cmd"`; do
+ case $prev$p in
+
+- -L* | -R* | -l*)
++ -L* | -R* | -l* | *clang_rt*.a)
+ # Some compilers place space between "-{L,R}" and the path.
+ # Remove the space.
+ if test x-L = "$p" ||
+
Please let me know if this is an appropriate fix.
Thanks,
Manoj
Sample linker command line when called by clang with compiler-rt:
"/usr/bin/x86_64-pc-linux-gnu-ld" --build-id --eh-frame-hdr -m elf_x86_64
-dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x/../../../../lib64/crt1.o
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x/../../../../lib64/crti.o
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x/crtbegin.o
-L/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x
-L/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x/../../../../lib64
-L/usr/bin/../lib64 -L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x/../../../../x86_64-pc-linux-gnu/lib
-L/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x/../../..
-L/usr/bin/../lib -L/lib -L/usr/lib /tmp/main-6b0bb5.o -lc++ -lm
/usr/lib64/clang/5.0.0/lib/linux/libclang_rt.builtins-x86_64.a -lgcc_eh -lc
/usr/lib64/clang/5.0.0/lib/linux/libclang_rt.builtins-x86_64.a -lgcc_eh
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x/crtend.o
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x/../../../../lib64/crtn.o
Thanks,
Manoj
--001a1140f9889f11d5055566a301
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<div><br></div><div>This is Manoj working on ChromeOS. =
I am facing a problem trying to build it with clang with its own internal l=
ibrary (compiler-rt) since some packages like mesa fail to build. The root =
cause is clang uses an absolute path to link its internal libraries which l=
ibtool does not recognize.</div><div><br></div><div>e.g. clang++ -rtlib=3Dc=
ompiler-rt main.cpp -v shows use of /usr/lib64/clang/5.0.0/lib/linux/libcla=
ng_rt.builtins-x86_64.a=C2=A0</div><div><br></div><div>Libtool currently re=
lies on "-lname" pattern to find the internal libraries. And this=
does not work if some code is compiled using + compiler-rt.</div><div>The =
issue was discovered in building mesa graphics library which uses -nostdlib=
flag =C2=A0and relies on libtool to pass the additionally required compile=
r internal libraries.</div><div><br></div><div>I have a sample fix below fo=
r fixing this for clang.</div><div><br></div><div><div>+--- a/m4/libtool.m4=
</div><div>++++ b/m4/libtool.m4</div><div>+@@ -7531,7 +7544,7 @@</div><div>=
+ =C2=A0 for p in `eval "$output_verbose_link_cmd"`; do</div><div=
>+ =C2=A0 =C2=A0 case $prev$p in</div><div>+</div><div>+- =C2=A0 =C2=A0-L* =
| -R* | -l*)</div><div>++ =C2=A0 =C2=A0-L* | -R* | -l* | *clang_rt*.a)</div=
><div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0# Some compilers place space between &qu=
ot;-{L,R}" and the path.</div><div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0# Remo=
ve the space.</div><div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0if test x-L =3D "=
$p" ||</div><div>+</div></div><div><br></div><div>Please let me know i=
f this is an appropriate fix.</div><div><br></div><div>Thanks,</div><div>Ma=
noj</div><div><br></div><div>Sample linker command line when called by clan=
g with compiler-rt:</div><div><br></div><div>=C2=A0"/usr/bin/x86_64-pc=
-linux-gnu-ld" --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker=
/lib64/ld-linux-x86-64.so.2 -o a.out /usr/bin/../lib64/gcc/x86_64-pc-linux=
-gnu/4.9.x/../../../../lib64/crt1.o /usr/bin/../lib64/gcc/x86_64-pc-linux-g=
nu/4.9.x/../../../../lib64/crti.o /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu=
/4.9.x/crtbegin.o -L/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x -L/usr/=
bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x/../../../../lib64 -L/usr/bin/../=
lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/bin/../lib64/gcc/x86_64-pc=
-linux-gnu/4.9.x/../../../../x86_64-pc-linux-gnu/lib -L/usr/bin/../lib64/gc=
c/x86_64-pc-linux-gnu/4.9.x/../../.. -L/usr/bin/../lib -L/lib -L/usr/lib /t=
mp/main-6b0bb5.o -lc++ -lm /usr/lib64/clang/5.0.0/lib/linux/libclang_rt.bui=
ltins-x86_64.a -lgcc_eh -lc /usr/lib64/clang/5.0.0/lib/linux/libclang_rt.bu=
iltins-x86_64.a -lgcc_eh /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x/cr=
tend.o /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x/../../../../lib64/cr=
tn.o</div><div><br></div><div><br></div><div>Thanks,</div><div>Manoj</div><=
/div>
--001a1140f9889f11d5055566a301--
Manoj Gupta <manojgupta@HIDDEN>:bug-libtool@HIDDEN.
Full text available.bug-libtool@HIDDEN:bug#27866; Package libtool.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.