GNU logs - #27866, boring messages

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Manoj Gupta <manojgupta@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Fri, 28 Jul 2017 21:05:02 +0000
Resent-Message-ID: <handler.27866.B.15012758664763 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: 27866 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-libtool@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.15012758664763
          (code B ref -1); Fri, 28 Jul 2017 21:05:02 +0000
Received: (at submit) by debbugs.gnu.org; 28 Jul 2017 21:04:26 +0000
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>
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-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 &quot;-lname&quot; 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 &quot;$output_verbose_link_cmd&quot;`; 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}&quot; 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 &quot;=
$p&quot; ||</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&quot;/usr/bin/x86_64-pc=
-linux-gnu-ld&quot; --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--

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Manoj Gupta <manojgupta@HIDDEN>
Subject: bug#27866: Acknowledgement (Handle clang's internal libraries
 when finding compiler's internal libraries)
Message-ID: <handler.27866.B.15012758664763.ack <at> debbugs.gnu.org>
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
X-Gnu-PR-Message: ack 27866
X-Gnu-PR-Package: libtool
Reply-To: 27866 <at> debbugs.gnu.org
Date: Fri, 28 Jul 2017 21:05:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-libtool@HIDDEN

If you wish to submit further information on this problem, please
send it to 27866 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
27866: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D27866
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Updated patch to make the match less expensive
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
In-Reply-To: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
Resent-From: Manoj Gupta <manojgupta@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Fri, 28 Jul 2017 21:58:01 +0000
Resent-Message-ID: <handler.27866.B27866.15012790769509 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: 27866 <at> debbugs.gnu.org
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.15012790769509
          (code B ref 27866); Fri, 28 Jul 2017 21:58:01 +0000
Received: (at 27866) by debbugs.gnu.org; 28 Jul 2017 21:57:56 +0000
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>
Content-Type: multipart/alternative; boundary="001a1140f988b2e607055567c2dd"
X-Spam-Score: -2.8 (--)
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 &quot;$o=
utput_verbose_link_cmd&quot;`; 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 &quot;-{L,R}&quot; 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 &quot;$p&quot; ||</div></div>

--001a1140f988b2e607055567c2dd--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Updated patch to make the match less expensive
Resent-From: Manoj Gupta <manojgupta@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Fri, 19 Jan 2018 00:50:02 +0000
Resent-Message-ID: <handler.27866.B27866.15163229714869 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: 27866 <at> debbugs.gnu.org
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.15163229714869
          (code B ref 27866); Fri, 19 Jan 2018 00:50:02 +0000
Received: (at 27866) by debbugs.gnu.org; 19 Jan 2018 00:49:31 +0000
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>
Content-Type: multipart/alternative; boundary="001a114cb408c210860563165fec"
X-Spam-Score: 0.0 (/)
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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Mike Frysinger <vapier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Fri, 19 Jan 2018 22:17:02 +0000
Resent-Message-ID: <handler.27866.B27866.15164001895503 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Manoj Gupta <manojgupta@HIDDEN>
Cc: 27866 <at> debbugs.gnu.org
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.15164001895503
          (code B ref 27866); Fri, 19 Jan 2018 22:17:02 +0000
Received: (at 27866) by debbugs.gnu.org; 19 Jan 2018 22:16:29 +0000
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>
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Manoj Gupta <manojgupta@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sat, 20 Jan 2018 01:36:01 +0000
Resent-Message-ID: <handler.27866.B27866.151641210725372 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.151641210725372
          (code B ref 27866); Sat, 20 Jan 2018 01:36:01 +0000
Received: (at 27866) by debbugs.gnu.org; 20 Jan 2018 01:35:07 +0000
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>
Content-Type: multipart/alternative; boundary="f403045f1bd67ee70605632b3471"
X-Spam-Score: 0.0 (/)
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">&lt;<a hre=
f=3D"mailto:vapier@HIDDEN" target=3D"_blank">vapier@HIDDEN</a>&gt;<=
/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>
&gt; This is Manoj working on ChromeOS. I am facing a problem trying to bui=
ld it<br>
&gt; with clang with its own internal library (compiler-rt) since some pack=
ages<br>
&gt; like mesa fail to build. The root cause is clang uses an absolute path=
 to<br>
&gt; link its internal libraries which libtool does not recognize.<br>
&gt;<br>
&gt; e.g. clang++ -rtlib=3Dcompiler-rt main.cpp -v shows use of<br>
&gt; /usr/lib64/clang/5.0.0/lib/<wbr>linux/libclang_rt.builtins-<wbr>x86_64=
.a<br>
&gt;<br>
&gt; Libtool currently relies on &quot;-lname&quot; pattern to find the int=
ernal<br>
&gt; libraries. And this does not work if some code is compiled using +<br>
&gt; compiler-rt.<br>
&gt; The issue was discovered in building mesa graphics library which uses<=
br>
&gt; -nostdlib flag=C2=A0 and relies on libtool to pass the additionally re=
quired<br>
&gt; compiler internal libraries.<br>
&gt;<br>
&gt; I have a sample fix below for fixing this for clang.<br>
&gt;<br>
&gt; +--- a/m4/libtool.m4<br>
&gt; ++++ b/m4/libtool.m4<br>
&gt; +@@ -7531,7 +7544,7 @@<br>
&gt; +=C2=A0 =C2=A0for p in `eval &quot;$output_verbose_link_cmd&quot;`; do=
<br>
&gt; +=C2=A0 =C2=A0 =C2=A0case $prev$p in<br>
&gt; +<br>
&gt; +-=C2=A0 =C2=A0 -L* | -R* | -l*)<br>
&gt; ++=C2=A0 =C2=A0 -L* | -R* | -l* | *clang_rt*.a)<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 # Some compilers place space between &quo=
t;-{L,R}&quot; and the path.<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 # Remove the space.<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 if test x-L =3D &quot;$p&quot; ||<br>
&gt; +<br>
<br>
i don&#39;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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Mike Frysinger <vapier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sat, 20 Jan 2018 01:51:01 +0000
Resent-Message-ID: <handler.27866.B27866.151641304226702 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Manoj Gupta <manojgupta@HIDDEN>
Cc: 27866 <at> debbugs.gnu.org
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.151641304226702
          (code B ref 27866); Sat, 20 Jan 2018 01:51:01 +0000
Received: (at 27866) by debbugs.gnu.org; 20 Jan 2018 01:50:42 +0000
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>
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Wed, 28 Feb 2018 21:13:01 +0000
Resent-Message-ID: <handler.27866.B27866.151985237624966 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Mike Frysinger <vapier@HIDDEN>
Cc: Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.151985237624966
          (code B ref 27866); Wed, 28 Feb 2018 21:13:01 +0000
Received: (at 27866) by debbugs.gnu.org; 28 Feb 2018 21:12:56 +0000
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: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
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-Mailman-Approved-At: Wed, 28 Feb 2018 16:12:54 -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.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

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Manoj Gupta <manojgupta@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sun, 18 Mar 2018 02:40:02 +0000
Resent-Message-ID: <handler.27866.B27866.152134075117379 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Cc: 27866 <at> debbugs.gnu.org, Mike Frysinger <vapier@HIDDEN>
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.152134075117379
          (code B ref 27866); Sun, 18 Mar 2018 02:40:02 +0000
Received: (at 27866) by debbugs.gnu.org; 18 Mar 2018 02:39:11 +0000
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>
Content-Type: multipart/alternative; boundary="001a114676748d81a50567a6be81"
X-Spam-Score: -0.0 (/)
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">&lt;<a href=3D"mailto:martin@HIDDEN" target=3D"_blank">martin@m=
artin.st</a>&gt;</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 &quot;a&quot;.=C2=A0 for shared libs, it can be calculated f=
rom shrext_cmds.<br>
=C2=A0eval std_shrext=3D\&quot;$shrext_cmds\&quot;<br>
=C2=A0-L* | -R* | -l* | *.${libext} | *${std_shrext})<br>
<br>
that would only support libs that end in &quot;.so&quot;.=C2=A0 but maybe t=
hat&#39;s OK.<br>
</blockquote>
<br></span>
Gentle ping - I&#39;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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Mon, 23 Jul 2018 15:34:01 +0000
Resent-Message-ID: <handler.27866.B27866.153236001226381 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Manoj Gupta <manojgupta@HIDDEN>
Cc: 27866 <at> debbugs.gnu.org, Mike Frysinger <vapier@HIDDEN>
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.153236001226381
          (code B ref 27866); Mon, 23 Jul 2018 15:34:01 +0000
Received: (at 27866) by debbugs.gnu.org; 23 Jul 2018 15:33:32 +0000
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: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Manoj Gupta <manojgupta@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Mon, 23 Jul 2018 16:17:02 +0000
Resent-Message-ID: <handler.27866.B27866.153236256430310 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Cc: 27866 <at> debbugs.gnu.org, Mike Frysinger <vapier@HIDDEN>
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.153236256430310
          (code B ref 27866); Mon, 23 Jul 2018 16:17:02 +0000
Received: (at 27866) by debbugs.gnu.org; 23 Jul 2018 16:16:04 +0000
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
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
>>
>>
>>
>

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Wed, 14 Aug 2019 20:47:02 +0000
Resent-Message-ID: <handler.27866.B27866.15658155741683 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Manoj Gupta <manojgupta@HIDDEN>
Cc: Pavel Raiskup <praiskup@HIDDEN>, Mike Frysinger <vapier@HIDDEN>, 27866 <at> debbugs.gnu.org
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.15658155741683
          (code B ref 27866); Wed, 14 Aug 2019 20:47:02 +0000
Received: (at 27866) by debbugs.gnu.org; 14 Aug 2019 20:46:14 +0000
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: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 15 Aug 2019 10:01:02 +0000
Resent-Message-ID: <handler.27866.B27866.156586324228442 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Manoj Gupta <manojgupta@HIDDEN>
Cc: Pavel Raiskup <praiskup@HIDDEN>, Mike Frysinger <vapier@HIDDEN>, 27866 <at> debbugs.gnu.org
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.156586324228442
          (code B ref 27866); Thu, 15 Aug 2019 10:01:02 +0000
Received: (at 27866) by debbugs.gnu.org; 15 Aug 2019 10:00:42 +0000
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: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Bob Friesenhahn <bfriesen@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 15 Aug 2019 13:02:01 +0000
Resent-Message-ID: <handler.27866.B27866.156587411821739 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Cc: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.156587411821739
          (code B ref 27866); Thu, 15 Aug 2019 13:02:01 +0000
Received: (at 27866) by debbugs.gnu.org; 15 Aug 2019 13:01:58 +0000
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
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Bob Friesenhahn <bfriesen@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 15 Aug 2019 13:03:02 +0000
Resent-Message-ID: <handler.27866.B.156587413521792 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Cc: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.156587413521792
          (code B ref -1); Thu, 15 Aug 2019 13:03:02 +0000
Received: (at submit) by debbugs.gnu.org; 15 Aug 2019 13:02:15 +0000
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
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 15 Aug 2019 14:57:02 +0000
Resent-Message-ID: <handler.27866.B27866.156588101617614 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Bob Friesenhahn <bfriesen@HIDDEN>
Cc: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.156588101617614
          (code B ref 27866); Thu, 15 Aug 2019 14:57:02 +0000
Received: (at 27866) by debbugs.gnu.org; 15 Aug 2019 14:56:56 +0000
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: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 15 Aug 2019 14:58:01 +0000
Resent-Message-ID: <handler.27866.B.156588102317674 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Bob Friesenhahn <bfriesen@HIDDEN>
Cc: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.156588102317674
          (code B ref -1); Thu, 15 Aug 2019 14:58:01 +0000
Received: (at submit) by debbugs.gnu.org; 15 Aug 2019 14:57:03 +0000
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: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Bob Friesenhahn <bfriesen@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 15 Aug 2019 15:21:02 +0000
Resent-Message-ID: <handler.27866.B.156588243127981 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Cc: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.156588243127981
          (code B ref -1); Thu, 15 Aug 2019 15:21:02 +0000
Received: (at submit) by debbugs.gnu.org; 15 Aug 2019 15:20:31 +0000
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
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Bob Friesenhahn <bfriesen@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 15 Aug 2019 15:21:03 +0000
Resent-Message-ID: <handler.27866.B27866.156588241527950 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Cc: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.156588241527950
          (code B ref 27866); Thu, 15 Aug 2019 15:21:03 +0000
Received: (at 27866) by debbugs.gnu.org; 15 Aug 2019 15:20:15 +0000
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
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 15 Aug 2019 21:08:02 +0000
Resent-Message-ID: <handler.27866.B.15659032322177 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Bob Friesenhahn <bfriesen@HIDDEN>
Cc: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.15659032322177
          (code B ref -1); Thu, 15 Aug 2019 21:08:02 +0000
Received: (at submit) by debbugs.gnu.org; 15 Aug 2019 21:07:12 +0000
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: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 15 Aug 2019 21:08:02 +0000
Resent-Message-ID: <handler.27866.B27866.15659032242136 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Bob Friesenhahn <bfriesen@HIDDEN>
Cc: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.15659032242136
          (code B ref 27866); Thu, 15 Aug 2019 21:08:02 +0000
Received: (at 27866) by debbugs.gnu.org; 15 Aug 2019 21:07:04 +0000
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: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Mon, 19 Aug 2019 10:46:02 +0000
Resent-Message-ID: <handler.27866.B.15662115193793 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Bob Friesenhahn <bfriesen@HIDDEN>
Cc: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.15662115193793
          (code B ref -1); Mon, 19 Aug 2019 10:46:02 +0000
Received: (at submit) by debbugs.gnu.org; 19 Aug 2019 10:45:19 +0000
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: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Mon, 19 Aug 2019 10:46:03 +0000
Resent-Message-ID: <handler.27866.B27866.15662115093765 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Bob Friesenhahn <bfriesen@HIDDEN>
Cc: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.15662115093765
          (code B ref 27866); Mon, 19 Aug 2019 10:46:03 +0000
Received: (at 27866) by debbugs.gnu.org; 19 Aug 2019 10:45:09 +0000
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: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Mon, 09 Sep 2019 08:40:02 +0000
Resent-Message-ID: <handler.27866.B.156801835618824 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Bob Friesenhahn <bfriesen@HIDDEN>
Cc: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.156801835618824
          (code B ref -1); Mon, 09 Sep 2019 08:40:02 +0000
Received: (at submit) by debbugs.gnu.org; 9 Sep 2019 08:39:16 +0000
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: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Mon, 09 Sep 2019 08:40:02 +0000
Resent-Message-ID: <handler.27866.B27866.156801835118802 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Bob Friesenhahn <bfriesen@HIDDEN>
Cc: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.156801835118802
          (code B ref 27866); Mon, 09 Sep 2019 08:40:02 +0000
Received: (at 27866) by debbugs.gnu.org; 9 Sep 2019 08:39:11 +0000
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: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
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-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--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 03 Mar 2022 12:30:02 +0000
Resent-Message-ID: <handler.27866.B.164631056823942 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: alex.ameen.tx@HIDDEN
Cc: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org, bfriesen@HIDDEN
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN, Bob Friesenhahn <bfriesen@HIDDEN>
Received: via spool by submit <at> debbugs.gnu.org id=B.164631056823942
          (code B ref -1); Thu, 03 Mar 2022 12:30:02 +0000
Received: (at submit) by debbugs.gnu.org; 3 Mar 2022 12:29:28 +0000
Received: from localhost ([127.0.0.1]:41612 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nPkaG-0006E5-65
	for submit <at> debbugs.gnu.org; Thu, 03 Mar 2022 07:29:28 -0500
Received: from lists.gnu.org ([209.51.188.17]:46462)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <martin@HIDDEN>) id 1nPkaE-0006Dy-JO
 for submit <at> debbugs.gnu.org; Thu, 03 Mar 2022 07:29:27 -0500
Received: from eggs.gnu.org ([209.51.188.92]:42684)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <martin@HIDDEN>) id 1nPkaE-0003vu-C1
 for bug-libtool@HIDDEN; Thu, 03 Mar 2022 07:29:26 -0500
Received: from mail8.parnet.fi ([77.234.108.134]:52502)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <martin@HIDDEN>) id 1nPka8-0002Kd-GE
 for bug-libtool@HIDDEN; Thu, 03 Mar 2022 07:29:22 -0500
Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21])
 by mail8.parnet.fi  with ESMTP id 223CT6vQ025615-223CT6vR025615;
 Thu, 3 Mar 2022 14:29:06 +0200
Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187])
 by mail9.parnet.fi (Postfix) with ESMTPS id 684C1A142C;
 Thu,  3 Mar 2022 14:29:05 +0200 (EET)
Date: Thu, 3 Mar 2022 14:29:04 +0200 (EET)
From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
In-Reply-To: <alpine.DEB.2.20.1908191337290.2829@HIDDEN>
Message-ID: <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@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>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-12831252-1646310546=:1823"
X-FE-Policy-ID: 3:14:2:SYSTEM
Received-SPF: pass client-ip=77.234.108.134; envelope-from=martin@HIDDEN;
 helo=mail8.parnet.fi
X-Spam_score_int: -25
X-Spam_score: -2.6
X-Spam_bar: --
X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.7 (-)
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.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-12831252-1646310546=:1823
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

Hi Alex,

I've understood you're a new maintainer of libtool. Can you have a look at 
this bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27866)?

In the last few posts, there's a couple patches attached. They have been 
used downstream within e.g. MSYS2 since a couple years:

https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011-Pick-up-clang_rt-static-archives-compiler-internal-l.patch

https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013-Allow-statically-linking-compiler-support-libraries-.patch

// Martin


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.
>
> 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.

--8323329-12831252-1646310546=:1823--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 03 Mar 2022 12:30:03 +0000
Resent-Message-ID: <handler.27866.B27866.164631055923919 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: alex.ameen.tx@HIDDEN
Cc: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org, bfriesen@HIDDEN
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN, Bob Friesenhahn <bfriesen@HIDDEN>
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.164631055923919
          (code B ref 27866); Thu, 03 Mar 2022 12:30:03 +0000
Received: (at 27866) by debbugs.gnu.org; 3 Mar 2022 12:29:19 +0000
Received: from localhost ([127.0.0.1]:41609 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nPka6-0006Dj-RR
	for submit <at> debbugs.gnu.org; Thu, 03 Mar 2022 07:29:19 -0500
Received: from mail8.parnet.fi ([77.234.108.134]:14050)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <martin@HIDDEN>) id 1nPka3-0006DT-3n
 for 27866 <at> debbugs.gnu.org; Thu, 03 Mar 2022 07:29:16 -0500
Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21])
 by mail8.parnet.fi  with ESMTP id 223CT6vQ025615-223CT6vR025615;
 Thu, 3 Mar 2022 14:29:06 +0200
Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187])
 by mail9.parnet.fi (Postfix) with ESMTPS id 684C1A142C;
 Thu,  3 Mar 2022 14:29:05 +0200 (EET)
Date: Thu, 3 Mar 2022 14:29:04 +0200 (EET)
From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
In-Reply-To: <alpine.DEB.2.20.1908191337290.2829@HIDDEN>
Message-ID: <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@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>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-12831252-1646310546=:1823"
X-FE-Policy-ID: 3:14:2:SYSTEM
X-Spam-Score: -0.7 (/)
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-12831252-1646310546=:1823
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

Hi Alex,

I've understood you're a new maintainer of libtool. Can you have a look at 
this bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27866)?

In the last few posts, there's a couple patches attached. They have been 
used downstream within e.g. MSYS2 since a couple years:

https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011-Pick-up-clang_rt-static-archives-compiler-internal-l.patch

https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013-Allow-statically-linking-compiler-support-libraries-.patch

// Martin


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.
>
> 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.

--8323329-12831252-1646310546=:1823--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Shea Levy <shea@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Fri, 06 May 2022 10:07:01 +0000
Resent-Message-ID: <handler.27866.B.165183157019931 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org, bfriesen@HIDDEN, martin@HIDDEN, alex.ameen.tx@HIDDEN
X-Debbugs-Original-To: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN, Bob Friesenhahn <bfriesen@HIDDEN>, Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>, alex.ameen.tx@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.165183157019931
          (code B ref -1); Fri, 06 May 2022 10:07:01 +0000
Received: (at submit) by debbugs.gnu.org; 6 May 2022 10:06:10 +0000
Received: from localhost ([127.0.0.1]:47167 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nmuqf-0005BN-Du
	for submit <at> debbugs.gnu.org; Fri, 06 May 2022 06:06:09 -0400
Received: from lists.gnu.org ([209.51.188.17]:54854)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <shea@HIDDEN>) id 1nmukH-0004zp-Li
 for submit <at> debbugs.gnu.org; Fri, 06 May 2022 05:59:34 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:44790)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <shea@HIDDEN>) id 1nmukH-0006iM-CX
 for bug-libtool@HIDDEN; Fri, 06 May 2022 05:59:33 -0400
Received: from smtprelay0018.hostedemail.com ([216.40.44.18]:44581
 helo=relay4.hostedemail.com)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <shea@HIDDEN>) id 1nmukF-0006ap-KA
 for bug-libtool@HIDDEN; Fri, 06 May 2022 05:59:32 -0400
Received: from omf04.hostedemail.com (a10.router.float.18 [10.200.18.1])
 by unirelay12.hostedemail.com (Postfix) with ESMTP id B18A6120BA6;
 Fri,  6 May 2022 09:59:29 +0000 (UTC)
Received: from [HIDDEN] (Authenticated sender: shea@HIDDEN) by
 omf04.hostedemail.com (Postfix) with ESMTPA id 1C79C20028; 
 Fri,  6 May 2022 09:59:29 +0000 (UTC)
From: Shea Levy <shea@HIDDEN>
In-Reply-To: <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@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>
 <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@HIDDEN>
Date: Fri, 06 May 2022 05:59:28 -0400
Message-ID: <8735hnj81r.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"
X-Spam-Status: No, score=-4.59
X-Stat-Signature: boyym9p6nfui7donbzkfji6djex5fi1c
X-Rspamd-Server: rspamout08
X-Rspamd-Queue-Id: 1C79C20028
X-Session-Marker: 7368656140736865616C6576792E636F6D
X-Session-ID: U2FsdGVkX1+aoLpkNLPOAXibB0/F0+Hf2WDyJsceJVc=
X-HE-Tag: 1651831169-15401
Received-SPF: pass client-ip=216.40.44.18; envelope-from=shea@HIDDEN;
 helo=relay4.hostedemail.com
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01,
 UNPARSEABLE_RELAY=0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.4 (-)
X-Mailman-Approved-At: Fri, 06 May 2022 06:06:08 -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.4 (--)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

Is there any status on this?

Thanks,
Shea

Martin Storsj=C3=B6 <martin@HIDDEN> writes:

> Hi Alex,

> I've understood you're a new maintainer of libtool. Can you have a look a=
t this bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D27866)?

> In the last few posts, there's a couple patches attached. They have been =
used downstream within e.g. MSYS2 since a couple years:

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJGBAEBCAAwFiEE6ESKvwKkwnxgMLnaXAvWlX2G/icFAmJ08YASHHNoZWFAc2hl
YWxldnkuY29tAAoJEFwL1pV9hv4nOUcP/RB4dnltE6gRFuSh+w6BDSYe6c0sl8cw
Wo65QHNuPZEWgDhXsx9ZsxadKqjGzT4iiVF1a1ljHBwpAViYiSOPF9LA8wVYRYeh
GsCZArzKLJp2ZaqPQvQ3y0cyBFhoBzuGjmXf+xswMEMPmgBA3E4qoBjtTOKaaFZT
zypG9bBfYkMZrDHkL/GO2DfHTCCRAKZPXgVH13Hf9izkB8c/KORJlejcCEcdDr1F
fX9golIse7QXcUr5BKO9qGJ9rHdPT+sEUHM542oFytC64gFxDpxURRn08BJgem1r
JkVm0gTkkWvfBThDB3bhLbQD9yJuoQvMxJNpC/CfdqO9b5Y56ab8bqoOF1aO9sJQ
6lPB3NVi/+o3xODi6u2xaL5pvlUurGi4HDt35p6P/XBy6y8kWTPE4hIcAlIhbY+c
Sd9dWPJ1+Nl6nMhLUQUDUFXAK0Uocv4IoOPEVxIAsdcdmC5NG4PGBbenjs6w3OeB
Hc/20cBYAoO6Bsa5c8eC3dKsCoOU/ZHXUak6CSW0G8XGaOvEbI+knzBDNhGs82iD
wCaI01zFqiMfSfL7oAoFuYqyhIRXIUzVvPoNBx/V9LeKnqfmIR4t66sABIXSOP2C
ZoewqV+bmYmIFqs2ECcmG9pQSZaivfhz7IMqOBXZArFZImQeS8bxV70tT8Uav19C
LSGa1keGJA/R
=Gefu
-----END PGP SIGNATURE-----
--=-=-=--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Shea Levy <shea@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Fri, 06 May 2022 10:07:02 +0000
Resent-Message-ID: <handler.27866.B27866.165183157019937 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org, bfriesen@HIDDEN, martin@HIDDEN, alex.ameen.tx@HIDDEN
X-Debbugs-Original-To: Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN, Bob Friesenhahn <bfriesen@HIDDEN>, Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>, alex.ameen.tx@HIDDEN
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.165183157019937
          (code B ref 27866); Fri, 06 May 2022 10:07:02 +0000
Received: (at 27866) by debbugs.gnu.org; 6 May 2022 10:06:10 +0000
Received: from localhost ([127.0.0.1]:47169 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nmuqf-0005BQ-Um
	for submit <at> debbugs.gnu.org; Fri, 06 May 2022 06:06:10 -0400
Received: from relay5.hostedemail.com ([64.99.140.39]:3019)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <shea@HIDDEN>) id 1nmukJ-0004zl-MR
 for 27866 <at> debbugs.gnu.org; Fri, 06 May 2022 05:59:35 -0400
Received: from omf04.hostedemail.com (a10.router.float.18 [10.200.18.1])
 by unirelay12.hostedemail.com (Postfix) with ESMTP id B18A6120BA6;
 Fri,  6 May 2022 09:59:29 +0000 (UTC)
Received: from [HIDDEN] (Authenticated sender: shea@HIDDEN) by
 omf04.hostedemail.com (Postfix) with ESMTPA id 1C79C20028; 
 Fri,  6 May 2022 09:59:29 +0000 (UTC)
From: Shea Levy <shea@HIDDEN>
In-Reply-To: <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@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>
 <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@HIDDEN>
Date: Fri, 06 May 2022 05:59:28 -0400
Message-ID: <8735hnj81r.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"
X-Spam-Status: No, score=-4.59
X-Stat-Signature: boyym9p6nfui7donbzkfji6djex5fi1c
X-Rspamd-Server: rspamout08
X-Rspamd-Queue-Id: 1C79C20028
X-Session-Marker: 7368656140736865616C6576792E636F6D
X-Session-ID: U2FsdGVkX1+aoLpkNLPOAXibB0/F0+Hf2WDyJsceJVc=
X-HE-Tag: 1651831169-15401
X-Spam-Score: -0.0 (/)
X-Mailman-Approved-At: Fri, 06 May 2022 06:06:08 -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: -1.0 (-)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

Is there any status on this?

Thanks,
Shea

Martin Storsj=C3=B6 <martin@HIDDEN> writes:

> Hi Alex,

> I've understood you're a new maintainer of libtool. Can you have a look a=
t this bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D27866)?

> In the last few posts, there's a couple patches attached. They have been =
used downstream within e.g. MSYS2 since a couple years:

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJGBAEBCAAwFiEE6ESKvwKkwnxgMLnaXAvWlX2G/icFAmJ08YASHHNoZWFAc2hl
YWxldnkuY29tAAoJEFwL1pV9hv4nOUcP/RB4dnltE6gRFuSh+w6BDSYe6c0sl8cw
Wo65QHNuPZEWgDhXsx9ZsxadKqjGzT4iiVF1a1ljHBwpAViYiSOPF9LA8wVYRYeh
GsCZArzKLJp2ZaqPQvQ3y0cyBFhoBzuGjmXf+xswMEMPmgBA3E4qoBjtTOKaaFZT
zypG9bBfYkMZrDHkL/GO2DfHTCCRAKZPXgVH13Hf9izkB8c/KORJlejcCEcdDr1F
fX9golIse7QXcUr5BKO9qGJ9rHdPT+sEUHM542oFytC64gFxDpxURRn08BJgem1r
JkVm0gTkkWvfBThDB3bhLbQD9yJuoQvMxJNpC/CfdqO9b5Y56ab8bqoOF1aO9sJQ
6lPB3NVi/+o3xODi6u2xaL5pvlUurGi4HDt35p6P/XBy6y8kWTPE4hIcAlIhbY+c
Sd9dWPJ1+Nl6nMhLUQUDUFXAK0Uocv4IoOPEVxIAsdcdmC5NG4PGBbenjs6w3OeB
Hc/20cBYAoO6Bsa5c8eC3dKsCoOU/ZHXUak6CSW0G8XGaOvEbI+knzBDNhGs82iD
wCaI01zFqiMfSfL7oAoFuYqyhIRXIUzVvPoNBx/V9LeKnqfmIR4t66sABIXSOP2C
ZoewqV+bmYmIFqs2ECcmG9pQSZaivfhz7IMqOBXZArFZImQeS8bxV70tT8Uav19C
LSGa1keGJA/R
=Gefu
-----END PGP SIGNATURE-----
--=-=-=--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Alex Ameen <alex.ameen.tx@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sun, 08 May 2022 20:38:02 +0000
Resent-Message-ID: <handler.27866.B.165204226311861 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Shea Levy <shea@HIDDEN>
Cc: praiskup@HIDDEN, 27866 <at> debbugs.gnu.org, martin@HIDDEN, bfriesen@HIDDEN, manojgupta@HIDDEN
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, bug-libtool@HIDDEN, Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>, 27866 <at> debbugs.gnu.org, Bob Friesenhahn <bfriesen@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>
Received: via spool by submit <at> debbugs.gnu.org id=B.165204226311861
          (code B ref -1); Sun, 08 May 2022 20:38:02 +0000
Received: (at submit) by debbugs.gnu.org; 8 May 2022 20:37:43 +0000
Received: from localhost ([127.0.0.1]:55324 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nnnew-00035F-PN
	for submit <at> debbugs.gnu.org; Sun, 08 May 2022 16:37:43 -0400
Received: from lists.gnu.org ([209.51.188.17]:60106)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <alex.ameen.tx@HIDDEN>) id 1nnneu-000355-Ui
 for submit <at> debbugs.gnu.org; Sun, 08 May 2022 16:37:41 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:56228)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <alex.ameen.tx@HIDDEN>)
 id 1nnneu-0006uL-M5
 for bug-libtool@HIDDEN; Sun, 08 May 2022 16:37:40 -0400
Received: from mail-vs1-xe2b.google.com ([2607:f8b0:4864:20::e2b]:41885)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <alex.ameen.tx@HIDDEN>)
 id 1nnnet-0004Dk-0Y
 for bug-libtool@HIDDEN; Sun, 08 May 2022 16:37:40 -0400
Received: by mail-vs1-xe2b.google.com with SMTP id w124so12100835vsb.8
 for <bug-libtool@HIDDEN>; Sun, 08 May 2022 13:37:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=3frgN6QwJB5aM/F9aB+2OPvKuOgx4/B2ZGCaXwyyu1k=;
 b=eneJsfi1nWKbtU8WAjZ2y28r/tBD3THuD+9hPsre3bkBh2Bf9L8qWrWjyIiVYORo/+
 RTDny3szv450uYAAv3JAAQ1jV/oye4PsN1+gVstZFQabbQQCQo1rK2ON4qvZh7gPU7zS
 bwkwXaMEZvAIMV1fAyRaHxMcv5DsnizAfTzMRDhvCJpptqv5hjJ5/xPM9Qt1bPYStKvu
 hVIi1R1iZFPhAup7hvEwyTbtAjQ12/j1ZxkUbHGRYTeybeb+VSOxtiuJFOUp/CfyQUIV
 4rjYiMPXPqfrHbUinET+nxmdCxc8xyLI83SbZD7S4uKSc7tsTtPJftohH2lg5gKiem7P
 sCvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=3frgN6QwJB5aM/F9aB+2OPvKuOgx4/B2ZGCaXwyyu1k=;
 b=YYxu8EYmJvcw71adr2/N6fLh5LmzNhnzu2zqeMioh3eSw0mpPXzDs17vVsn9cXEu7I
 mNuqNWYV0Cq94y/VfB0XJBTjknL3VccfZG4DgRgYgzyHKvt4aSOX9xJeBCQWTIGBGxJ+
 DwJBArYPJGxt3K4zHX0yZLgiNPOiepktWYpC0mypth5qpSrCkSWsmZj+wITMI1mTF4rp
 9/gYUhSkDej8CjvQjT8uwqYfAqCCvNuuZ//KdjQbduafgxjMNWj4ahAE43m6MEIKEEMm
 HFIrAkmErt/JxwPw0Rlnw/JohrbOUP31gNSxVUnDFbLytNxDGoCQ129P2DOIC+d9wFWx
 3A2Q==
X-Gm-Message-State: AOAM530DVgrCCxjkQXNwsyBrZSErkhNe318JquhItmkUQvTKTdd47d7U
 o6HSeu/xMVyyXkL7/Vjq0b5c24DNDEMGKhofWuk=
X-Google-Smtp-Source: ABdhPJwg0tvjh1BjS/K+xzk++X2fbT4RG2FkdK0hl1JPY0yqlXg849vWczHe/7J5scjFH3N7V6Vv/HXix8XMWJ4/bBo=
X-Received: by 2002:a05:6102:2929:b0:32d:6662:72e2 with SMTP id
 cz41-20020a056102292900b0032d666272e2mr6681078vsb.56.1652042257636; Sun, 08
 May 2022 13:37:37 -0700 (PDT)
MIME-Version: 1.0
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>
 <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@HIDDEN>
 <8735hnj81r.fsf@HIDDEN>
In-Reply-To: <8735hnj81r.fsf@HIDDEN>
From: Alex Ameen <alex.ameen.tx@HIDDEN>
Date: Sun, 8 May 2022 15:37:26 -0500
Message-ID: <CAKgHvytMXrPB5JPYUJramA_J0M7Pa1=cySic5=CapuSkkMnGxQ@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000eba0e105de860f70"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e2b;
 envelope-from=alex.ameen.tx@HIDDEN; helo=mail-vs1-xe2b.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
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.3 (--)

--000000000000eba0e105de860f70
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

No not yet. Was traveling for Mother's Day, but I can look at it this week
or next weekend.

On Fri, May 6, 2022, 4:59 AM Shea Levy <shea@HIDDEN> wrote:

> Hi all,
>
> Is there any status on this?
>
> Thanks,
> Shea
>
> Martin Storsj=C3=B6 <martin@HIDDEN> writes:
>
> > Hi Alex,
>
> > I've understood you're a new maintainer of libtool. Can you have a look
> at this bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D27866)?
>
> > In the last few posts, there's a couple patches attached. They have bee=
n
> used downstream within e.g. MSYS2 since a couple years:
>

--000000000000eba0e105de860f70
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">No not yet. Was traveling for Mother&#39;s Day, but I can=
 look at it this week or next weekend.=C2=A0</div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, May 6, 2022, 4:59 AM Sh=
ea Levy &lt;<a href=3D"mailto:shea@HIDDEN">shea@HIDDEN</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Is there any status on this?<br>
<br>
Thanks,<br>
Shea<br>
<br>
Martin Storsj=C3=B6 &lt;<a href=3D"mailto:martin@HIDDEN" target=3D"_blan=
k" rel=3D"noreferrer">martin@HIDDEN</a>&gt; writes:<br>
<br>
&gt; Hi Alex,<br>
<br>
&gt; I&#39;ve understood you&#39;re a new maintainer of libtool. Can you ha=
ve a look at this bug (<a href=3D"https://debbugs.gnu.org/cgi/bugreport.cgi=
?bug=3D27866" rel=3D"noreferrer noreferrer" target=3D"_blank">https://debbu=
gs.gnu.org/cgi/bugreport.cgi?bug=3D27866</a>)?<br>
<br>
&gt; In the last few posts, there&#39;s a couple patches attached. They hav=
e been used downstream within e.g. MSYS2 since a couple years:<br>
</blockquote></div>

--000000000000eba0e105de860f70--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Alex Ameen <alex.ameen.tx@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sun, 08 May 2022 20:38:02 +0000
Resent-Message-ID: <handler.27866.B27866.165204227911890 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Shea Levy <shea@HIDDEN>
Cc: praiskup@HIDDEN, 27866 <at> debbugs.gnu.org, martin@HIDDEN, bfriesen@HIDDEN, manojgupta@HIDDEN
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, bug-libtool@HIDDEN, Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>, 27866 <at> debbugs.gnu.org, Bob Friesenhahn <bfriesen@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.165204227911890
          (code B ref 27866); Sun, 08 May 2022 20:38:02 +0000
Received: (at 27866) by debbugs.gnu.org; 8 May 2022 20:37:59 +0000
Received: from localhost ([127.0.0.1]:55327 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nnnfD-00035h-7n
	for submit <at> debbugs.gnu.org; Sun, 08 May 2022 16:37:59 -0400
Received: from mail-vs1-f54.google.com ([209.85.217.54]:46036)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <alex.ameen.tx@HIDDEN>) id 1nnnex-000351-8g
 for 27866 <at> debbugs.gnu.org; Sun, 08 May 2022 16:37:58 -0400
Received: by mail-vs1-f54.google.com with SMTP id e19so12087959vsu.12
 for <27866 <at> debbugs.gnu.org>; Sun, 08 May 2022 13:37:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=3frgN6QwJB5aM/F9aB+2OPvKuOgx4/B2ZGCaXwyyu1k=;
 b=eneJsfi1nWKbtU8WAjZ2y28r/tBD3THuD+9hPsre3bkBh2Bf9L8qWrWjyIiVYORo/+
 RTDny3szv450uYAAv3JAAQ1jV/oye4PsN1+gVstZFQabbQQCQo1rK2ON4qvZh7gPU7zS
 bwkwXaMEZvAIMV1fAyRaHxMcv5DsnizAfTzMRDhvCJpptqv5hjJ5/xPM9Qt1bPYStKvu
 hVIi1R1iZFPhAup7hvEwyTbtAjQ12/j1ZxkUbHGRYTeybeb+VSOxtiuJFOUp/CfyQUIV
 4rjYiMPXPqfrHbUinET+nxmdCxc8xyLI83SbZD7S4uKSc7tsTtPJftohH2lg5gKiem7P
 sCvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=3frgN6QwJB5aM/F9aB+2OPvKuOgx4/B2ZGCaXwyyu1k=;
 b=fhwfzBauheuAfzfzBK3EBTfTaosmh4fVx8bs+FRjY5/Qr2TIZ/VGeekfJpxN6YjmEX
 57KYiO5UfEzXyAZEwSqudvbsRQ8BohCcFyoYjMfBV1lwxXBwPksTqVD1otDw3h9Rdfpo
 G12y7a9PyHeOM/HDjq1Et/5A1F2OLSj6pPba3IigsgZQZgN4lRyRLEj72fpLBvbqwZPr
 4WqE8vRaeWlNtX1wFQyIQ0fSg++W6aJKrVKueqq8sQRkq2jO5dt2iGDSH6M4giS0QTTl
 l4dNhNXZs0pnbeufJX0nkK//T6VQKLLvCjd+xjgZ3E7Mtemfa/QCmqLdZVIwDvf9z3i4
 Pz/g==
X-Gm-Message-State: AOAM5318zcm85PXZHv/ClKkq3rtwAc/+uFt4RBrGZl3UmtzbsG0yyyh2
 8j7SXSwEnoe0SqtDqlgYSsm7PtxcIRsUnrY3/dA=
X-Google-Smtp-Source: ABdhPJwg0tvjh1BjS/K+xzk++X2fbT4RG2FkdK0hl1JPY0yqlXg849vWczHe/7J5scjFH3N7V6Vv/HXix8XMWJ4/bBo=
X-Received: by 2002:a05:6102:2929:b0:32d:6662:72e2 with SMTP id
 cz41-20020a056102292900b0032d666272e2mr6681078vsb.56.1652042257636; Sun, 08
 May 2022 13:37:37 -0700 (PDT)
MIME-Version: 1.0
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>
 <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@HIDDEN>
 <8735hnj81r.fsf@HIDDEN>
In-Reply-To: <8735hnj81r.fsf@HIDDEN>
From: Alex Ameen <alex.ameen.tx@HIDDEN>
Date: Sun, 8 May 2022 15:37:26 -0500
Message-ID: <CAKgHvytMXrPB5JPYUJramA_J0M7Pa1=cySic5=CapuSkkMnGxQ@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000eba0e105de860f70"
X-Spam-Score: 0.0 (/)
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 (-)

--000000000000eba0e105de860f70
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

No not yet. Was traveling for Mother's Day, but I can look at it this week
or next weekend.

On Fri, May 6, 2022, 4:59 AM Shea Levy <shea@HIDDEN> wrote:

> Hi all,
>
> Is there any status on this?
>
> Thanks,
> Shea
>
> Martin Storsj=C3=B6 <martin@HIDDEN> writes:
>
> > Hi Alex,
>
> > I've understood you're a new maintainer of libtool. Can you have a look
> at this bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D27866)?
>
> > In the last few posts, there's a couple patches attached. They have bee=
n
> used downstream within e.g. MSYS2 since a couple years:
>

--000000000000eba0e105de860f70
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">No not yet. Was traveling for Mother&#39;s Day, but I can=
 look at it this week or next weekend.=C2=A0</div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, May 6, 2022, 4:59 AM Sh=
ea Levy &lt;<a href=3D"mailto:shea@HIDDEN">shea@HIDDEN</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Is there any status on this?<br>
<br>
Thanks,<br>
Shea<br>
<br>
Martin Storsj=C3=B6 &lt;<a href=3D"mailto:martin@HIDDEN" target=3D"_blan=
k" rel=3D"noreferrer">martin@HIDDEN</a>&gt; writes:<br>
<br>
&gt; Hi Alex,<br>
<br>
&gt; I&#39;ve understood you&#39;re a new maintainer of libtool. Can you ha=
ve a look at this bug (<a href=3D"https://debbugs.gnu.org/cgi/bugreport.cgi=
?bug=3D27866" rel=3D"noreferrer noreferrer" target=3D"_blank">https://debbu=
gs.gnu.org/cgi/bugreport.cgi?bug=3D27866</a>)?<br>
<br>
&gt; In the last few posts, there&#39;s a couple patches attached. They hav=
e been used downstream within e.g. MSYS2 since a couple years:<br>
</blockquote></div>

--000000000000eba0e105de860f70--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Alex Ameen <alex.ameen.tx@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sun, 15 May 2022 18:34:01 +0000
Resent-Message-ID: <handler.27866.B.165263960824597 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: shea@HIDDEN, praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org, bfriesen@HIDDEN, martin@HIDDEN
X-Debbugs-Original-To: Shea Levy <shea@HIDDEN>, Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN, Bob Friesenhahn <bfriesen@HIDDEN>, Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Received: via spool by submit <at> debbugs.gnu.org id=B.165263960824597
          (code B ref -1); Sun, 15 May 2022 18:34:01 +0000
Received: (at submit) by debbugs.gnu.org; 15 May 2022 18:33:28 +0000
Received: from localhost ([127.0.0.1]:50605 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nqJ3X-0006Od-T4
	for submit <at> debbugs.gnu.org; Sun, 15 May 2022 14:33:28 -0400
Received: from lists.gnu.org ([209.51.188.17]:49196)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <alex.ameen.tx@HIDDEN>) id 1nqJ3W-0006OX-Rj
 for submit <at> debbugs.gnu.org; Sun, 15 May 2022 14:33:27 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:42988)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <alex.ameen.tx@HIDDEN>)
 id 1nqJ3W-0000M4-Ff
 for bug-libtool@HIDDEN; Sun, 15 May 2022 14:33:26 -0400
Received: from mail-oa1-x33.google.com ([2001:4860:4864:20::33]:46488)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <alex.ameen.tx@HIDDEN>)
 id 1nqJ3U-0007i2-PG
 for bug-libtool@HIDDEN; Sun, 15 May 2022 14:33:26 -0400
Received: by mail-oa1-x33.google.com with SMTP id
 586e51a60fabf-d39f741ba0so17153338fac.13
 for <bug-libtool@HIDDEN>; Sun, 15 May 2022 11:33:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=message-id:date:mime-version:user-agent:subject:content-language:to
 :references:from:in-reply-to:content-transfer-encoding;
 bh=Mou633cJMkOgjICNorP/kjhNYW/n6D4cTANcMVoMdiQ=;
 b=WNcagEyXz5ykhq5ZTyDAN/0En7W5rNmP9nqmIQ6dJCCxYYYdGNSE0OZoOICm/bv2qH
 UrDypV2RRBGCNOYM1aBAOPIIlH+61/fX+zmZm51H+0u3P232b5CzYsNPO6lBMZr0OSSx
 25ElRoanOOgNruMn5XyYN4i1HC62vz0ji2Koh4K36QBKNEuEszOYuImY9NEpBwm6T/i7
 9Ih4j4u/nYWCSoDCR+uEjG9cYL/ikMbCNQWRDvNmrXFjhZ/eKJCXPccfOoFrzAIyavoU
 1irWr7G4ZmB6IGsTUo2sljP6Mmo2dSAPlfurS9vxiBxFd8Bl/BBdjG7jUdN12DNzNoK1
 Bu1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:message-id:date:mime-version:user-agent:subject
 :content-language:to:references:from:in-reply-to
 :content-transfer-encoding;
 bh=Mou633cJMkOgjICNorP/kjhNYW/n6D4cTANcMVoMdiQ=;
 b=V+6hj96yYr6J9ymDf5AfC3KKrYRZHUWFxeIE/tuofC3n+M7ROrTyU7gF6lbLTT33nb
 AdY6OqH1Qb+hTSXhHaUvLERDQSA8oUfkCe/oJIOhuN3T4fizR7jwbQDeD5iOb6xkhqVc
 6xkrPxWx1hStPq3lwR/3K5awXLJKejtQSHB7SZ27hO7vLBmlb8U0bmuuCDStFh3l2R1A
 tzEkSDiriq7j23CN4oV8rzeIsUlo3CQJf6pl2ElvizZ7CMsVPfGhBpcoDaoRHEJyurPp
 xxWo66C9+6IZY98B+iuK2DLKjUtRElFsCPDOnAcBSFfg97wYSNP+17BIZAe7XUkZcU6f
 GBoA==
X-Gm-Message-State: AOAM531F/2RGbnB+Jw9bJ+7YgG/hDELdjPHMIlRdOqbUCjlopSLOeu4h
 P+R/7/oeXyGRlO4LdgE753o=
X-Google-Smtp-Source: ABdhPJwSTTaLzU4w/hP0ZWeS8bKQHDGzTFuSCGo6WNMC55sOKV9+7PV7Q1ea8hLpn4xB50ZLeV5EUg==
X-Received: by 2002:a05:6870:c390:b0:f1:6a3a:227b with SMTP id
 g16-20020a056870c39000b000f16a3a227bmr5243447oao.142.1652639602916; 
 Sun, 15 May 2022 11:33:22 -0700 (PDT)
Received: from [192.168.88.252] ([98.156.163.55])
 by smtp.gmail.com with ESMTPSA id
 e4-20020a056870450400b000e686d1386dsm4078951oao.7.2022.05.15.11.33.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 May 2022 11:33:22 -0700 (PDT)
Message-ID: <9f84eb26-d083-01ef-cc07-cc8bb586c1c1@HIDDEN>
Date: Sun, 15 May 2022 13:33:21 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Content-Language: en-US
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>
 <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@HIDDEN>
 <8735hnj81r.fsf@HIDDEN>
From: Alex Ameen <alex.ameen.tx@HIDDEN>
In-Reply-To: <8735hnj81r.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=2001:4860:4864:20::33;
 envelope-from=alex.ameen.tx@HIDDEN; helo=mail-oa1-x33.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
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.3 (--)

Earlier this week I read through the thread, and created a patch based 
on the ones posted. This was checked if you would like to experiment 
with it.

What I did notice was that this change has a wider effect than the 
problem statement initially suggests. I'm not crazy about the way it has 
a conditional behavior for two specific libraries since it is an ad-hoc 
solution directed at two compiler-collections, as opposed to a general 
purpose solution; but for the time being I see this as a practical change.

As a side effect this change should also resolve issues with certain 
flag-specs such as `-fsanitize' which is nice; but the impact of unknown 
side effects is something I expect will rear its head in the near 
future. With that in mind, I think this is a necessary change, but I 
want to express up front that "I'm confident this will break a lot of 
existing builds, and I consider this to be a first draft".

I would greatly appreciate y'all taking this for a spin on any available 
projects you have to get a sense of how it will behave "in the field". 
This change really effects "unspecified behavior" that the test-suite 
isn't designed to audit, but nonetheless has a practical effect on users.

On 5/6/22 04:59, Shea Levy wrote:
> Hi all,
>
> Is there any status on this?
>
> Thanks,
> Shea
>
> Martin Storsjö <martin@HIDDEN> writes:
>
>> Hi Alex,
>> I've understood you're a new maintainer of libtool. Can you have a look at this bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27866)?
>> In the last few posts, there's a couple patches attached. They have been used downstream within e.g. MSYS2 since a couple years:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Alex Ameen <alex.ameen.tx@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sun, 15 May 2022 18:34:01 +0000
Resent-Message-ID: <handler.27866.B27866.165263961224613 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: shea@HIDDEN, praiskup@HIDDEN, manojgupta@HIDDEN, 27866 <at> debbugs.gnu.org, bfriesen@HIDDEN, martin@HIDDEN
X-Debbugs-Original-To: Shea Levy <shea@HIDDEN>, Pavel Raiskup <praiskup@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>, 27866 <at> debbugs.gnu.org, bug-libtool@HIDDEN, Bob Friesenhahn <bfriesen@HIDDEN>, Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.165263961224613
          (code B ref 27866); Sun, 15 May 2022 18:34:01 +0000
Received: (at 27866) by debbugs.gnu.org; 15 May 2022 18:33:32 +0000
Received: from localhost ([127.0.0.1]:50608 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nqJ3c-0006Ou-6g
	for submit <at> debbugs.gnu.org; Sun, 15 May 2022 14:33:32 -0400
Received: from mail-oa1-f54.google.com ([209.85.160.54]:36723)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <alex.ameen.tx@HIDDEN>) id 1nqJ3Y-0006OS-Ky
 for 27866 <at> debbugs.gnu.org; Sun, 15 May 2022 14:33:28 -0400
Received: by mail-oa1-f54.google.com with SMTP id
 586e51a60fabf-edeb6c3642so17220547fac.3
 for <27866 <at> debbugs.gnu.org>; Sun, 15 May 2022 11:33:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=message-id:date:mime-version:user-agent:subject:content-language:to
 :references:from:in-reply-to:content-transfer-encoding;
 bh=Mou633cJMkOgjICNorP/kjhNYW/n6D4cTANcMVoMdiQ=;
 b=WNcagEyXz5ykhq5ZTyDAN/0En7W5rNmP9nqmIQ6dJCCxYYYdGNSE0OZoOICm/bv2qH
 UrDypV2RRBGCNOYM1aBAOPIIlH+61/fX+zmZm51H+0u3P232b5CzYsNPO6lBMZr0OSSx
 25ElRoanOOgNruMn5XyYN4i1HC62vz0ji2Koh4K36QBKNEuEszOYuImY9NEpBwm6T/i7
 9Ih4j4u/nYWCSoDCR+uEjG9cYL/ikMbCNQWRDvNmrXFjhZ/eKJCXPccfOoFrzAIyavoU
 1irWr7G4ZmB6IGsTUo2sljP6Mmo2dSAPlfurS9vxiBxFd8Bl/BBdjG7jUdN12DNzNoK1
 Bu1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:message-id:date:mime-version:user-agent:subject
 :content-language:to:references:from:in-reply-to
 :content-transfer-encoding;
 bh=Mou633cJMkOgjICNorP/kjhNYW/n6D4cTANcMVoMdiQ=;
 b=0dk3lqC41TBBYLjopHrtUxyVdy3LRThX1KuVzLam+ZJYbykQ2+q1fRnCNjeDaetW6t
 6+Q2jqp/nNRgAHwA2OyxBrh+fNbPDsXnFn6mM8yuU2nC2fR0Xr5Mh34VgF2bE0DsQuZL
 jUDNVwcD0Y3EyVp6RdhvLHgn3tvbsX3Oij1mVuku5UUHYV3m+Dv+qYew9x4pIeaZf2zu
 sR0jsewkgV2m1EOV5k19qZ80LDkkJAaq5tepTWv63Nwcwo10SZvusrLdUyw8iXEdTVMp
 E/FhB7NPA3EiJbQeMqPLhOU/QCxlvQnl2xfDbYj0kC2/kPhWFrxrE8JxJu+9L2wsbkuS
 xtlw==
X-Gm-Message-State: AOAM532RyfubSNWrcS0NI1JT6eRUDc65LncNC4otyVzV1OwZNo9TS8rp
 7lVaczaODBt+5agc+UQx/1M=
X-Google-Smtp-Source: ABdhPJwSTTaLzU4w/hP0ZWeS8bKQHDGzTFuSCGo6WNMC55sOKV9+7PV7Q1ea8hLpn4xB50ZLeV5EUg==
X-Received: by 2002:a05:6870:c390:b0:f1:6a3a:227b with SMTP id
 g16-20020a056870c39000b000f16a3a227bmr5243447oao.142.1652639602916; 
 Sun, 15 May 2022 11:33:22 -0700 (PDT)
Received: from [192.168.88.252] ([98.156.163.55])
 by smtp.gmail.com with ESMTPSA id
 e4-20020a056870450400b000e686d1386dsm4078951oao.7.2022.05.15.11.33.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 May 2022 11:33:22 -0700 (PDT)
Message-ID: <9f84eb26-d083-01ef-cc07-cc8bb586c1c1@HIDDEN>
Date: Sun, 15 May 2022 13:33:21 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Content-Language: en-US
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>
 <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@HIDDEN>
 <8735hnj81r.fsf@HIDDEN>
From: Alex Ameen <alex.ameen.tx@HIDDEN>
In-Reply-To: <8735hnj81r.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.0 (/)
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 (-)

Earlier this week I read through the thread, and created a patch based 
on the ones posted. This was checked if you would like to experiment 
with it.

What I did notice was that this change has a wider effect than the 
problem statement initially suggests. I'm not crazy about the way it has 
a conditional behavior for two specific libraries since it is an ad-hoc 
solution directed at two compiler-collections, as opposed to a general 
purpose solution; but for the time being I see this as a practical change.

As a side effect this change should also resolve issues with certain 
flag-specs such as `-fsanitize' which is nice; but the impact of unknown 
side effects is something I expect will rear its head in the near 
future. With that in mind, I think this is a necessary change, but I 
want to express up front that "I'm confident this will break a lot of 
existing builds, and I consider this to be a first draft".

I would greatly appreciate y'all taking this for a spin on any available 
projects you have to get a sense of how it will behave "in the field". 
This change really effects "unspecified behavior" that the test-suite 
isn't designed to audit, but nonetheless has a practical effect on users.

On 5/6/22 04:59, Shea Levy wrote:
> Hi all,
>
> Is there any status on this?
>
> Thanks,
> Shea
>
> Martin Storsjö <martin@HIDDEN> writes:
>
>> Hi Alex,
>> I've understood you're a new maintainer of libtool. Can you have a look at this bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27866)?
>> In the last few posts, there's a couple patches attached. They have been used downstream within e.g. MSYS2 since a couple years:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sun, 15 May 2022 20:22:02 +0000
Resent-Message-ID: <handler.27866.B.165264611611341 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Alex Ameen <alex.ameen.tx@HIDDEN>
Cc: praiskup@HIDDEN, 27866 <at> debbugs.gnu.org, shea@HIDDEN, bfriesen@HIDDEN, manojgupta@HIDDEN
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, bug-libtool@HIDDEN, Shea Levy <shea@HIDDEN>, 27866 <at> debbugs.gnu.org, Bob Friesenhahn <bfriesen@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>
Received: via spool by submit <at> debbugs.gnu.org id=B.165264611611341
          (code B ref -1); Sun, 15 May 2022 20:22:02 +0000
Received: (at submit) by debbugs.gnu.org; 15 May 2022 20:21:56 +0000
Received: from localhost ([127.0.0.1]:50828 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nqKkW-0002wr-Ap
	for submit <at> debbugs.gnu.org; Sun, 15 May 2022 16:21:56 -0400
Received: from lists.gnu.org ([209.51.188.17]:60700)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <martin@HIDDEN>) id 1nqKkU-0002wk-UU
 for submit <at> debbugs.gnu.org; Sun, 15 May 2022 16:21:55 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:59422)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <martin@HIDDEN>) id 1nqKkU-0007TP-PO
 for bug-libtool@HIDDEN; Sun, 15 May 2022 16:21:54 -0400
Received: from mail8.parnet.fi ([77.234.108.134]:13118)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <martin@HIDDEN>) id 1nqKkS-0006AS-1h
 for bug-libtool@HIDDEN; Sun, 15 May 2022 16:21:54 -0400
Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21])
 by mail8.parnet.fi  with ESMTP id 24FKLbMw002715-24FKLbMx002715;
 Sun, 15 May 2022 23:21:37 +0300
Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187])
 by mail9.parnet.fi (Postfix) with ESMTPS id 15F53A150B;
 Sun, 15 May 2022 23:21:36 +0300 (EEST)
Date: Sun, 15 May 2022 23:21:35 +0300 (EEST)
From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
In-Reply-To: <9f84eb26-d083-01ef-cc07-cc8bb586c1c1@HIDDEN>
Message-ID: <63a4df41-93c8-c54-307c-2bff6edb3589@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>
 <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@HIDDEN>
 <8735hnj81r.fsf@HIDDEN>
 <9f84eb26-d083-01ef-cc07-cc8bb586c1c1@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-FE-Policy-ID: 3:14:2:SYSTEM
Received-SPF: pass client-ip=77.234.108.134; envelope-from=martin@HIDDEN;
 helo=mail8.parnet.fi
X-Spam_score_int: -25
X-Spam_score: -2.6
X-Spam_bar: --
X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.7 (-)
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.7 (--)

On Sun, 15 May 2022, Alex Ameen wrote:

> Earlier this week I read through the thread, and created a patch based on the 
> ones posted. This was checked if you would like to experiment with it.
>
> What I did notice was that this change has a wider effect than the problem 
> statement initially suggests. I'm not crazy about the way it has a 
> conditional behavior for two specific libraries since it is an ad-hoc 
> solution directed at two compiler-collections, as opposed to a general 
> purpose solution; but for the time being I see this as a practical change.
>
> As a side effect this change should also resolve issues with certain 
> flag-specs such as `-fsanitize' which is nice; but the impact of unknown side 
> effects is something I expect will rear its head in the near future. With 
> that in mind, I think this is a necessary change, but I want to express up 
> front that "I'm confident this will break a lot of existing builds, and I 
> consider this to be a first draft".
>
> I would greatly appreciate y'all taking this for a spin on any available 
> projects you have to get a sense of how it will behave "in the field". This 
> change really effects "unspecified behavior" that the test-suite isn't 
> designed to audit, but nonetheless has a practical effect on users.

Thanks!

I tested this now, and it doesn't work quite as is - it needs this 
modification:

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index ab5af335..9c084816 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -7554,7 +7554,7 @@ if AC_TRY_EVAL(ac_compile); then
    for p in `eval "$output_verbose_link_cmd"`; do
      case $prev$p in

-    -L* | -R* | -l* | */clang_rt*.a)
+    -L* | -R* | -l* | */libclang_rt*.a)
         # Some compilers place space between "-{L,R}" and the path.
         # Remove the space.
         if test x-L = "$p" ||

(This was correct in one out of two instances in 
1d2577357ee704da2d6d7c7da119ad82ba8ca172.)

With that changed, it does seem to work as it should for me on a test 
project.

// Martin

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sun, 15 May 2022 20:22:02 +0000
Resent-Message-ID: <handler.27866.B27866.165264611011323 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Alex Ameen <alex.ameen.tx@HIDDEN>
Cc: praiskup@HIDDEN, 27866 <at> debbugs.gnu.org, shea@HIDDEN, bfriesen@HIDDEN, manojgupta@HIDDEN
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, bug-libtool@HIDDEN, Shea Levy <shea@HIDDEN>, 27866 <at> debbugs.gnu.org, Bob Friesenhahn <bfriesen@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.165264611011323
          (code B ref 27866); Sun, 15 May 2022 20:22:02 +0000
Received: (at 27866) by debbugs.gnu.org; 15 May 2022 20:21:50 +0000
Received: from localhost ([127.0.0.1]:50825 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nqKkP-0002wX-Tw
	for submit <at> debbugs.gnu.org; Sun, 15 May 2022 16:21:50 -0400
Received: from mail8.parnet.fi ([77.234.108.134]:25666)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <martin@HIDDEN>) id 1nqKkL-0002wG-Ua
 for 27866 <at> debbugs.gnu.org; Sun, 15 May 2022 16:21:47 -0400
Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21])
 by mail8.parnet.fi  with ESMTP id 24FKLbMw002715-24FKLbMx002715;
 Sun, 15 May 2022 23:21:37 +0300
Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187])
 by mail9.parnet.fi (Postfix) with ESMTPS id 15F53A150B;
 Sun, 15 May 2022 23:21:36 +0300 (EEST)
Date: Sun, 15 May 2022 23:21:35 +0300 (EEST)
From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
In-Reply-To: <9f84eb26-d083-01ef-cc07-cc8bb586c1c1@HIDDEN>
Message-ID: <63a4df41-93c8-c54-307c-2bff6edb3589@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>
 <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@HIDDEN>
 <8735hnj81r.fsf@HIDDEN>
 <9f84eb26-d083-01ef-cc07-cc8bb586c1c1@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-FE-Policy-ID: 3:14:2:SYSTEM
X-Spam-Score: -0.7 (/)
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 (-)

On Sun, 15 May 2022, Alex Ameen wrote:

> Earlier this week I read through the thread, and created a patch based on the 
> ones posted. This was checked if you would like to experiment with it.
>
> What I did notice was that this change has a wider effect than the problem 
> statement initially suggests. I'm not crazy about the way it has a 
> conditional behavior for two specific libraries since it is an ad-hoc 
> solution directed at two compiler-collections, as opposed to a general 
> purpose solution; but for the time being I see this as a practical change.
>
> As a side effect this change should also resolve issues with certain 
> flag-specs such as `-fsanitize' which is nice; but the impact of unknown side 
> effects is something I expect will rear its head in the near future. With 
> that in mind, I think this is a necessary change, but I want to express up 
> front that "I'm confident this will break a lot of existing builds, and I 
> consider this to be a first draft".
>
> I would greatly appreciate y'all taking this for a spin on any available 
> projects you have to get a sense of how it will behave "in the field". This 
> change really effects "unspecified behavior" that the test-suite isn't 
> designed to audit, but nonetheless has a practical effect on users.

Thanks!

I tested this now, and it doesn't work quite as is - it needs this 
modification:

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index ab5af335..9c084816 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -7554,7 +7554,7 @@ if AC_TRY_EVAL(ac_compile); then
    for p in `eval "$output_verbose_link_cmd"`; do
      case $prev$p in

-    -L* | -R* | -l* | */clang_rt*.a)
+    -L* | -R* | -l* | */libclang_rt*.a)
         # Some compilers place space between "-{L,R}" and the path.
         # Remove the space.
         if test x-L = "$p" ||

(This was correct in one out of two instances in 
1d2577357ee704da2d6d7c7da119ad82ba8ca172.)

With that changed, it does seem to work as it should for me on a test 
project.

// Martin

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Alex Ameen <alex.ameen.tx@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sun, 15 May 2022 22:47:02 +0000
Resent-Message-ID: <handler.27866.B.16526548211031 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Cc: praiskup@HIDDEN, 27866 <at> debbugs.gnu.org, shea@HIDDEN, bfriesen@HIDDEN, manojgupta@HIDDEN
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, bug-libtool@HIDDEN, Shea Levy <shea@HIDDEN>, 27866 <at> debbugs.gnu.org, Bob Friesenhahn <bfriesen@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>
Received: via spool by submit <at> debbugs.gnu.org id=B.16526548211031
          (code B ref -1); Sun, 15 May 2022 22:47:02 +0000
Received: (at submit) by debbugs.gnu.org; 15 May 2022 22:47:01 +0000
Received: from localhost ([127.0.0.1]:50991 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nqN0u-0000GT-8O
	for submit <at> debbugs.gnu.org; Sun, 15 May 2022 18:47:01 -0400
Received: from lists.gnu.org ([209.51.188.17]:47124)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <alex.ameen.tx@HIDDEN>) id 1nqN0s-0000GL-Dz
 for submit <at> debbugs.gnu.org; Sun, 15 May 2022 18:46:59 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:49628)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <alex.ameen.tx@HIDDEN>)
 id 1nqN0s-0002xC-7B
 for bug-libtool@HIDDEN; Sun, 15 May 2022 18:46:58 -0400
Received: from mail-oi1-x235.google.com ([2607:f8b0:4864:20::235]:39841)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <alex.ameen.tx@HIDDEN>)
 id 1nqN0p-00008f-Pn
 for bug-libtool@HIDDEN; Sun, 15 May 2022 18:46:57 -0400
Received: by mail-oi1-x235.google.com with SMTP id l16so16717174oil.6
 for <bug-libtool@HIDDEN>; Sun, 15 May 2022 15:46:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=message-id:date:mime-version:user-agent:subject:content-language:to
 :cc:references:from:in-reply-to;
 bh=pLvsINQoyYbVH1AUg7gK5pY3yGyfbOrj3CFYijHHjv8=;
 b=HDJUAHeUHp7MfSNDt/fTMGcdRi1kFV1d6IcQHP+WdD/e+qyE3tot9bZ9VyGFIPmOhP
 2gMjfFjUQYYq8LJQrMRFbKqxAAstGwpp83J732sKtuKO1Feldgzlh5EgWEnTl7fLdACp
 XekKtcy6HX/sRjdd2hz/+6SiEHwS2dp54rn9hIiVUZHgmeSYt4TjjIxQJHj7JVa7BiUH
 xnEMPPazksQ/QTvtsyA1Y8OT9TjemfgL24dD2V9YZxYMVAMrLyMxoDrc4HnJLjhQj9xz
 uTI2lcS/CmyCuSMJMByvzJA7lhA49jQzUKcbTstALzHOsW4IPnvGUii45jmNypgyKFIX
 bY1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:message-id:date:mime-version:user-agent:subject
 :content-language:to:cc:references:from:in-reply-to;
 bh=pLvsINQoyYbVH1AUg7gK5pY3yGyfbOrj3CFYijHHjv8=;
 b=2QTZkN0FNyvwstUlfWTW1zAUnCy/ofF9b6ECt/2gA4h5RDka3+3rQzDamNag8Iqa7a
 Kx4lIvv/zw12//RUcTp3LPx8Y+xHutfdAPQ5eapWB30yMS7qBLeV/Rit6eu9p1JwZs7B
 ZYc2h8Uw5YJGHKTB29Bq5Nm4YlH9Of3yJZvBbNr45sk7BDBnmy6tda+h/zXWREH1NFvW
 mEnqNwDeIhixocp+LHhuravAzfDK0QUzqSs+8S0YyCRjbb2l/EU0ynIoYScAjV8F3rwT
 SYYvp7aKwMYz2YUPg3MMez0zbY4WAJQnEbYBMY9TAxUuelhMha80g71tfl3HEq7gn/eO
 TVsA==
X-Gm-Message-State: AOAM531k5wTzNIPfW1ofhPgZMauEc4N4t7+gutfkTiueNZhXDORa7Wsp
 NIZim5byA01Zfgsr+nGPaws=
X-Google-Smtp-Source: ABdhPJzOFlRd58yLSV9hG0cxFQ2SQ/OiBDKJcDDR+0/2tq0EY3jpgfT70osbYBCNe34qVds23Ej1tw==
X-Received: by 2002:a05:6808:b19:b0:325:d028:7681 with SMTP id
 s25-20020a0568080b1900b00325d0287681mr12207314oij.195.1652654813462; 
 Sun, 15 May 2022 15:46:53 -0700 (PDT)
Received: from [192.168.88.252] ([98.156.163.55])
 by smtp.gmail.com with ESMTPSA id
 kv16-20020a056870fb9000b000e9275a25b8sm4491249oab.32.2022.05.15.15.46.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 May 2022 15:46:52 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------pGPFuJ4cp4MUcNPAkKib58Gm"
Message-ID: <43f80a1b-e0f1-cd2a-9f12-f839b7c79125@HIDDEN>
Date: Sun, 15 May 2022 17:46:51 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Content-Language: en-US
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
 <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>
 <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@HIDDEN>
 <8735hnj81r.fsf@HIDDEN>
 <9f84eb26-d083-01ef-cc07-cc8bb586c1c1@HIDDEN>
 <63a4df41-93c8-c54-307c-2bff6edb3589@HIDDEN>
From: Alex Ameen <alex.ameen.tx@HIDDEN>
In-Reply-To: <63a4df41-93c8-c54-307c-2bff6edb3589@HIDDEN>
Received-SPF: pass client-ip=2607:f8b0:4864:20::235;
 envelope-from=alex.ameen.tx@HIDDEN; helo=mail-oi1-x235.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
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.3 (--)

This is a multi-part message in MIME format.
--------------pGPFuJ4cp4MUcNPAkKib58Gm
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Nice catch, I fat-fingered that one.

Could you share the workspace you tested in, or a snippet? I need to 
make a test case.


There was one aspect I wanted some clarity on though from the patches 
MSYS developed, which was "why is it that `m4/libtool.m4' used 
`*NAME*.a' when `build-aux/ltmain.in' used `*/libNAME*.$libext', and why 
they allowed `libgcc*' in `ltmain.in' but not `m4/libtool.m4'. I'm glad 
I looked into it because when I investigated the original patches' 
commit logs I realized that these were really just aimed at getting the 
builds for a small number of MSYS2 packages to succeed ( in the author's 
case VLC was the one they were focused on ); and that really this wasn't 
really designed to be a general purpose patch to `libtool'. From what I 
can tell MSYS2 is only using `libtool' for like 15 packages, so for 
their use case hard coding a few whitelisted libraries is totally fine. 
I'm actually really glad I dug into this more because In the field this 
would have caused serious UB issues - the likes of which are actually 
what led me to learn about linking/loading and eventually towards `libtool'.

I think my initial gut feeling on this one was right, and I'm probably 
going to revert that change and iron this out in a project branch that 
handles this alongside some related issues with flag-specs. The 
underlying problem here, which has been discussed in a few other threads 
is that `libtool' tries to outsmart the user and the compiler-collection 
by reinterpreting flags library linkage flags like `-l:libfoo.a' or 
`./libfoo.so', replacing them with `libfoo.la' and in rare cases even 
swapping system libs which entirely different alternatives for a 
particular platform.

In the MSYS patches their issue was that `libtool' doesn't respect the 
flag-spec/implicit linkage for either GCC or Clang - so libraries which 
are implicitly linked by the compiler-collection such as `libgcc_s.so' 
or `libclang_rt.a' don't get added, usually what you get instead is a 
manual invocation of `ld'. The result is that libtool removes certain 
libs which are normally added by the compiler-collection's invocation of 
`ld':

```
ld /path-to-libc/{crt1,crti}.o              \
    /path-to-cc/lib/crt<CC-init>.o           \  # CC adds, but not `libtool'
    <USER-FLAGS>                             \
    -L/path-to-cc/lib -l<CC-libc-overrides>  \  # CC adds, but not `libtool' ( almost always a static lib )
    -L/path-to-libc/lib -lc                  \
    -l<CC-runtime>                           \  # CC adds, but not `libtool' ( usually a shared lib )
    /path-to-cc/lib/crt<CC-cleanup>.o        \  # CC adds, but not `libtool' ( this one can get you in the most trouble )
    /path-to-libc/crtn.o;
```

While the issues they're dealing with for Clang really focus on the RT 
and libc override style libraries - the CC specific `.o' files can be a 
real silent killer ( I know from experience before becoming maintainer 
). The solution I'd like for this is going to take some time to develop, 
and is going to require some real changes to the stated behavior of 
`libtool' ( definitely not backwards compatible ) - but `libtool' needs 
to either parse flag-specs and perfectly reproduce the underlying CC's 
implicit libs, or it needs to stop directly invoking `ld'.

The big issue I see with the MSYS patches, and similar ad-hoc patches 
that have been submitted to work around issues in flag-specs 
`-fsanitize=' for example ) is that they often explicitly add linkage 
for the relevant libraries, and fail to add linkage for the `.o' files. 
The nasty thing about this is that it'll probably work fine 99% of the 
time, but the 1% of the time that it misbehaves will be nearly 
impossible to debug. You have initialization/cleanup routine in those 
`.o' files that alter the initialization of executables and shared 
libraries in discreet ways which effect a subset of of the RT and libc 
override implementations provided by CCs - if those routines aren't 
linked you often won't get a failure at link-editing time, rather you'll 
get bizarre UB at runtime and ( in my experience ) by the time you 
figure out what's wrong you'll have read two books, read the manuals for 
CC and `ld' backwards and forwards a dozen times, GDB sessions will 
haunt your dreams, and four months of your life have passed by lol.

In my case the mistake didn't involve `libtool', it was just a dev 
dropping the ball while porting a Makefile from AIX to Linux. It's worth 
noting, that as obnoxious as it is that `libtool' doesn't try to 
replicate the CC linkage - in cases where people didn't try to work 
around this by manually linking their CC specific libs, they would be 
protected from the issue I encountered. I startled myself today 
realizing that I checked in a patch that would have caused `libtool' to 
make the exact issue that led me to learn about linking ( the irony 
would have been palpable ). I am interested to learn if the patches MSYS 
is using have caused the sort of UB I dealt with, I've got a list of at 
least 3 issues I'd wager they run into with C++ "old ABI", `pthread', 
and `dlopen'.

On 5/15/22 15:21, Martin Storsjö wrote:
> On Sun, 15 May 2022, Alex Ameen wrote:
>
>> Earlier this week I read through the thread, and created a patch 
>> based on the ones posted. This was checked if you would like to 
>> experiment with it.
>>
>> What I did notice was that this change has a wider effect than the 
>> problem statement initially suggests. I'm not crazy about the way it 
>> has a conditional behavior for two specific libraries since it is an 
>> ad-hoc solution directed at two compiler-collections, as opposed to a 
>> general purpose solution; but for the time being I see this as a 
>> practical change.
>>
>> As a side effect this change should also resolve issues with certain 
>> flag-specs such as `-fsanitize' which is nice; but the impact of 
>> unknown side effects is something I expect will rear its head in the 
>> near future. With that in mind, I think this is a necessary change, 
>> but I want to express up front that "I'm confident this will break a 
>> lot of existing builds, and I consider this to be a first draft".
>>
>> I would greatly appreciate y'all taking this for a spin on any 
>> available projects you have to get a sense of how it will behave "in 
>> the field". This change really effects "unspecified behavior" that 
>> the test-suite isn't designed to audit, but nonetheless has a 
>> practical effect on users.
>
> Thanks!
>
> I tested this now, and it doesn't work quite as is - it needs this 
> modification:
>
> diff --git a/m4/libtool.m4 b/m4/libtool.m4
> index ab5af335..9c084816 100644
> --- a/m4/libtool.m4
> +++ b/m4/libtool.m4
> @@ -7554,7 +7554,7 @@ if AC_TRY_EVAL(ac_compile); then
>    for p in `eval "$output_verbose_link_cmd"`; do
>      case $prev$p in
>
> -    -L* | -R* | -l* | */clang_rt*.a)
> +    -L* | -R* | -l* | */libclang_rt*.a)
>         # Some compilers place space between "-{L,R}" and the path.
>         # Remove the space.
>         if test x-L = "$p" ||
>
> (This was correct in one out of two instances in 
> 1d2577357ee704da2d6d7c7da119ad82ba8ca172.)
>
> With that changed, it does seem to work as it should for me on a test 
> project.
>
> // Martin
>
--------------pGPFuJ4cp4MUcNPAkKib58Gm
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Nice catch, I fat-fingered that one.<br>
    </p>
    <p>Could you share the workspace you tested in, or a snippet? I need
      to make a test case.<br>
      <br>
      <br>
      There was one aspect I wanted some clarity on though from the
      patches MSYS developed, which was "why is it that `m4/libtool.m4'
      used `*NAME*.a' when `build-aux/ltmain.in' used
      `*/libNAME*.$libext', and why they allowed `libgcc*' in
      `ltmain.in' but not `m4/libtool.m4'. I'm glad I looked into it
      because when I investigated the original patches' commit logs I
      realized that these were really just aimed at getting the builds
      for a small number of MSYS2 packages to succeed ( in the author's
      case VLC was the one they were focused on ); and that really this
      wasn't really designed to be a general purpose patch to `libtool'.
      From what I can tell MSYS2 is only using `libtool' for like 15
      packages, so for their use case hard coding a few whitelisted
      libraries is totally fine. I'm actually really glad I dug into
      this more because In the field this would have caused serious UB
      issues - the likes of which are actually what led me to learn
      about linking/loading and eventually towards `libtool'.<br>
      <br>
      I think my initial gut feeling on this one was right, and I'm
      probably going to revert that change and iron this out in a
      project branch that handles this alongside some related issues
      with flag-specs. The underlying problem here, which has been
      discussed in a few other threads is that `libtool' tries to
      outsmart the user and the compiler-collection by reinterpreting
      flags library linkage flags like `-l:libfoo.a' or `./libfoo.so',
      replacing them with `libfoo.la' and in rare cases even swapping
      system libs which entirely different alternatives for a particular
      platform.<br>
      <br>
      In the MSYS patches their issue was that `libtool' doesn't respect
      the flag-spec/implicit linkage for either GCC or Clang - so
      libraries which are implicitly linked by the compiler-collection
      such as `libgcc_s.so' or `libclang_rt.a' don't get added, usually
      what you get instead is a manual invocation of `ld'. The result is
      that libtool removes certain libs which are normally added by the
      compiler-collection's invocation of `ld':<br>
    </p>
    <pre>```
ld /path-to-libc/{crt1,crti}.o              \
   /path-to-cc/lib/crt&lt;CC-init&gt;.o           \  # CC adds, but not `libtool'
   &lt;USER-FLAGS&gt;                             \
   -L/path-to-cc/lib -l&lt;CC-libc-overrides&gt;  \  # CC adds, but not `libtool' ( almost always a static lib )
   -L/path-to-libc/lib -lc                  \
   -l&lt;CC-runtime&gt;                           \  # CC adds, but not `libtool' ( usually a shared lib )
   /path-to-cc/lib/crt&lt;CC-cleanup&gt;.o        \  # CC adds, but not `libtool' ( this one can get you in the most trouble )
   /path-to-libc/crtn.o;
```
</pre>
    <p>While the issues they're dealing with for Clang really focus on
      the RT and libc override style libraries - the CC specific `.o'
      files can be a real silent killer ( I know from experience before
      becoming maintainer ). The solution I'd like for this is going to
      take some time to develop, and is going to require some real
      changes to the stated behavior of `libtool' ( definitely not
      backwards compatible ) - but `libtool' needs to either parse
      flag-specs and perfectly reproduce the underlying CC's implicit
      libs, or it needs to stop directly invoking `ld'.<br>
      <br>
      The big issue I see with the MSYS patches, and similar ad-hoc
      patches that have been submitted to work around issues in
      flag-specs `-fsanitize=' for example ) is that they often
      explicitly add linkage for the relevant libraries, and fail to add
      linkage for the `.o' files. The nasty thing about this is that
      it'll probably work fine 99% of the time, but the 1% of the time
      that it misbehaves will be nearly impossible to debug. You have
      initialization/cleanup routine in those `.o' files that alter the
      initialization of executables and shared libraries in discreet
      ways which effect a subset of of the RT and libc override
      implementations provided by CCs - if those routines aren't linked
      you often won't get a failure at link-editing time, rather you'll
      get bizarre UB at runtime and ( in my experience ) by the time you
      figure out what's wrong you'll have read two books, read the
      manuals for CC and `ld' backwards and forwards a dozen times, GDB
      sessions will haunt your dreams, and four months of your life have
      passed by lol.<br>
      <br>
      In my case the mistake didn't involve `libtool', it was just a dev
      dropping the ball while porting a Makefile from AIX to Linux. It's
      worth noting, that as obnoxious as it is that `libtool' doesn't
      try to replicate the CC linkage - in cases where people didn't try
      to work around this by manually linking their CC specific libs,
      they would be protected from the issue I encountered. I startled
      myself today realizing that I checked in a patch that would have
      caused `libtool' to make the exact issue that led me to learn
      about linking ( the irony would have been palpable ). I am
      interested to learn if the patches MSYS is using have caused the
      sort of UB I dealt with, I've got a list of at least 3 issues I'd
      wager they run into with C++ "old ABI", `pthread', and `dlopen'.<br>
      <br>
    </p>
    <div class="moz-cite-prefix">On 5/15/22 15:21, Martin Storsjö wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:63a4df41-93c8-c54-307c-2bff6edb3589@HIDDEN">On Sun,
      15 May 2022, Alex Ameen wrote:
      <br>
      <br>
      <blockquote type="cite">Earlier this week I read through the
        thread, and created a patch based on the ones posted. This was
        checked if you would like to experiment with it.
        <br>
        <br>
        What I did notice was that this change has a wider effect than
        the problem statement initially suggests. I'm not crazy about
        the way it has a conditional behavior for two specific libraries
        since it is an ad-hoc solution directed at two
        compiler-collections, as opposed to a general purpose solution;
        but for the time being I see this as a practical change.
        <br>
        <br>
        As a side effect this change should also resolve issues with
        certain flag-specs such as `-fsanitize' which is nice; but the
        impact of unknown side effects is something I expect will rear
        its head in the near future. With that in mind, I think this is
        a necessary change, but I want to express up front that "I'm
        confident this will break a lot of existing builds, and I
        consider this to be a first draft".
        <br>
        <br>
        I would greatly appreciate y'all taking this for a spin on any
        available projects you have to get a sense of how it will behave
        "in the field". This change really effects "unspecified
        behavior" that the test-suite isn't designed to audit, but
        nonetheless has a practical effect on users.
        <br>
      </blockquote>
      <br>
      Thanks!
      <br>
      <br>
      I tested this now, and it doesn't work quite as is - it needs this
      modification:
      <br>
      <br>
      diff --git a/m4/libtool.m4 b/m4/libtool.m4
      <br>
      index ab5af335..9c084816 100644
      <br>
      --- a/m4/libtool.m4
      <br>
      +++ b/m4/libtool.m4
      <br>
      @@ -7554,7 +7554,7 @@ if AC_TRY_EVAL(ac_compile); then
      <br>
         for p in `eval "$output_verbose_link_cmd"`; do
      <br>
           case $prev$p in
      <br>
      <br>
      -    -L* | -R* | -l* | */clang_rt*.a)
      <br>
      +    -L* | -R* | -l* | */libclang_rt*.a)
      <br>
              # Some compilers place space between "-{L,R}" and the
      path.
      <br>
              # Remove the space.
      <br>
              if test x-L = "$p" ||
      <br>
      <br>
      (This was correct in one out of two instances in
      1d2577357ee704da2d6d7c7da119ad82ba8ca172.)
      <br>
      <br>
      With that changed, it does seem to work as it should for me on a
      test project.
      <br>
      <br>
      // Martin
      <br>
      <br>
    </blockquote>
  </body>
</html>

--------------pGPFuJ4cp4MUcNPAkKib58Gm--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Alex Ameen <alex.ameen.tx@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sun, 15 May 2022 22:48:01 +0000
Resent-Message-ID: <handler.27866.B27866.16526548261066 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Cc: praiskup@HIDDEN, 27866 <at> debbugs.gnu.org, shea@HIDDEN, bfriesen@HIDDEN, manojgupta@HIDDEN
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, bug-libtool@HIDDEN, Shea Levy <shea@HIDDEN>, 27866 <at> debbugs.gnu.org, Bob Friesenhahn <bfriesen@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.16526548261066
          (code B ref 27866); Sun, 15 May 2022 22:48:01 +0000
Received: (at 27866) by debbugs.gnu.org; 15 May 2022 22:47:06 +0000
Received: from localhost ([127.0.0.1]:50994 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nqN0z-0000H8-74
	for submit <at> debbugs.gnu.org; Sun, 15 May 2022 18:47:05 -0400
Received: from mail-oi1-f174.google.com ([209.85.167.174]:33778)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <alex.ameen.tx@HIDDEN>) id 1nqN0t-0000GG-D1
 for 27866 <at> debbugs.gnu.org; Sun, 15 May 2022 18:47:00 -0400
Received: by mail-oi1-f174.google.com with SMTP id w130so16771668oig.0
 for <27866 <at> debbugs.gnu.org>; Sun, 15 May 2022 15:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=message-id:date:mime-version:user-agent:subject:content-language:to
 :cc:references:from:in-reply-to;
 bh=pLvsINQoyYbVH1AUg7gK5pY3yGyfbOrj3CFYijHHjv8=;
 b=HDJUAHeUHp7MfSNDt/fTMGcdRi1kFV1d6IcQHP+WdD/e+qyE3tot9bZ9VyGFIPmOhP
 2gMjfFjUQYYq8LJQrMRFbKqxAAstGwpp83J732sKtuKO1Feldgzlh5EgWEnTl7fLdACp
 XekKtcy6HX/sRjdd2hz/+6SiEHwS2dp54rn9hIiVUZHgmeSYt4TjjIxQJHj7JVa7BiUH
 xnEMPPazksQ/QTvtsyA1Y8OT9TjemfgL24dD2V9YZxYMVAMrLyMxoDrc4HnJLjhQj9xz
 uTI2lcS/CmyCuSMJMByvzJA7lhA49jQzUKcbTstALzHOsW4IPnvGUii45jmNypgyKFIX
 bY1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:message-id:date:mime-version:user-agent:subject
 :content-language:to:cc:references:from:in-reply-to;
 bh=pLvsINQoyYbVH1AUg7gK5pY3yGyfbOrj3CFYijHHjv8=;
 b=NLI82FOD2pcdjnHQ7W6Cz+eUcb8YJy59s/TD08ZFG1Rp+MliW+5L2jHYsytgvGtCLT
 ePAQw8IWH9kzvV4nrnnLiLX5brF6YiZzR4jcWm39MrKoxELBKrF3dWLd70QlmbB7hn9p
 902P9Lvw4vh4PpoH7YEUQbmWy4klIBspl5R0nuM4tOIGHGOYnBhKUBB7hOf2VhR9gz3/
 WEjOeEWgWK+VQ+AxLORVBU+JuHj+wgNeTJ39pnoNKQ/Bbin/sFwcSvIpL+l6ry9jIs/T
 gLk0LUPo3DuqFGht1CXvaFdhNoo5+EF9V8i5muMWcqw9JPKMcLNRjDNbtRcjf5KiBXkZ
 4xlQ==
X-Gm-Message-State: AOAM533GhK3tN0ULepkjcH0y4Tf22sk/yI8L0gPNmkHcwH5JMAyr8ZT4
 SMT9LuSLGl27cQy3Qgk5/No=
X-Google-Smtp-Source: ABdhPJzOFlRd58yLSV9hG0cxFQ2SQ/OiBDKJcDDR+0/2tq0EY3jpgfT70osbYBCNe34qVds23Ej1tw==
X-Received: by 2002:a05:6808:b19:b0:325:d028:7681 with SMTP id
 s25-20020a0568080b1900b00325d0287681mr12207314oij.195.1652654813462; 
 Sun, 15 May 2022 15:46:53 -0700 (PDT)
Received: from [192.168.88.252] ([98.156.163.55])
 by smtp.gmail.com with ESMTPSA id
 kv16-20020a056870fb9000b000e9275a25b8sm4491249oab.32.2022.05.15.15.46.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 May 2022 15:46:52 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------pGPFuJ4cp4MUcNPAkKib58Gm"
Message-ID: <43f80a1b-e0f1-cd2a-9f12-f839b7c79125@HIDDEN>
Date: Sun, 15 May 2022 17:46:51 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Content-Language: en-US
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
 <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>
 <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@HIDDEN>
 <8735hnj81r.fsf@HIDDEN>
 <9f84eb26-d083-01ef-cc07-cc8bb586c1c1@HIDDEN>
 <63a4df41-93c8-c54-307c-2bff6edb3589@HIDDEN>
From: Alex Ameen <alex.ameen.tx@HIDDEN>
In-Reply-To: <63a4df41-93c8-c54-307c-2bff6edb3589@HIDDEN>
X-Spam-Score: -0.0 (/)
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 is a multi-part message in MIME format.
--------------pGPFuJ4cp4MUcNPAkKib58Gm
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Nice catch, I fat-fingered that one.

Could you share the workspace you tested in, or a snippet? I need to 
make a test case.


There was one aspect I wanted some clarity on though from the patches 
MSYS developed, which was "why is it that `m4/libtool.m4' used 
`*NAME*.a' when `build-aux/ltmain.in' used `*/libNAME*.$libext', and why 
they allowed `libgcc*' in `ltmain.in' but not `m4/libtool.m4'. I'm glad 
I looked into it because when I investigated the original patches' 
commit logs I realized that these were really just aimed at getting the 
builds for a small number of MSYS2 packages to succeed ( in the author's 
case VLC was the one they were focused on ); and that really this wasn't 
really designed to be a general purpose patch to `libtool'. From what I 
can tell MSYS2 is only using `libtool' for like 15 packages, so for 
their use case hard coding a few whitelisted libraries is totally fine. 
I'm actually really glad I dug into this more because In the field this 
would have caused serious UB issues - the likes of which are actually 
what led me to learn about linking/loading and eventually towards `libtool'.

I think my initial gut feeling on this one was right, and I'm probably 
going to revert that change and iron this out in a project branch that 
handles this alongside some related issues with flag-specs. The 
underlying problem here, which has been discussed in a few other threads 
is that `libtool' tries to outsmart the user and the compiler-collection 
by reinterpreting flags library linkage flags like `-l:libfoo.a' or 
`./libfoo.so', replacing them with `libfoo.la' and in rare cases even 
swapping system libs which entirely different alternatives for a 
particular platform.

In the MSYS patches their issue was that `libtool' doesn't respect the 
flag-spec/implicit linkage for either GCC or Clang - so libraries which 
are implicitly linked by the compiler-collection such as `libgcc_s.so' 
or `libclang_rt.a' don't get added, usually what you get instead is a 
manual invocation of `ld'. The result is that libtool removes certain 
libs which are normally added by the compiler-collection's invocation of 
`ld':

```
ld /path-to-libc/{crt1,crti}.o              \
    /path-to-cc/lib/crt<CC-init>.o           \  # CC adds, but not `libtool'
    <USER-FLAGS>                             \
    -L/path-to-cc/lib -l<CC-libc-overrides>  \  # CC adds, but not `libtool' ( almost always a static lib )
    -L/path-to-libc/lib -lc                  \
    -l<CC-runtime>                           \  # CC adds, but not `libtool' ( usually a shared lib )
    /path-to-cc/lib/crt<CC-cleanup>.o        \  # CC adds, but not `libtool' ( this one can get you in the most trouble )
    /path-to-libc/crtn.o;
```

While the issues they're dealing with for Clang really focus on the RT 
and libc override style libraries - the CC specific `.o' files can be a 
real silent killer ( I know from experience before becoming maintainer 
). The solution I'd like for this is going to take some time to develop, 
and is going to require some real changes to the stated behavior of 
`libtool' ( definitely not backwards compatible ) - but `libtool' needs 
to either parse flag-specs and perfectly reproduce the underlying CC's 
implicit libs, or it needs to stop directly invoking `ld'.

The big issue I see with the MSYS patches, and similar ad-hoc patches 
that have been submitted to work around issues in flag-specs 
`-fsanitize=' for example ) is that they often explicitly add linkage 
for the relevant libraries, and fail to add linkage for the `.o' files. 
The nasty thing about this is that it'll probably work fine 99% of the 
time, but the 1% of the time that it misbehaves will be nearly 
impossible to debug. You have initialization/cleanup routine in those 
`.o' files that alter the initialization of executables and shared 
libraries in discreet ways which effect a subset of of the RT and libc 
override implementations provided by CCs - if those routines aren't 
linked you often won't get a failure at link-editing time, rather you'll 
get bizarre UB at runtime and ( in my experience ) by the time you 
figure out what's wrong you'll have read two books, read the manuals for 
CC and `ld' backwards and forwards a dozen times, GDB sessions will 
haunt your dreams, and four months of your life have passed by lol.

In my case the mistake didn't involve `libtool', it was just a dev 
dropping the ball while porting a Makefile from AIX to Linux. It's worth 
noting, that as obnoxious as it is that `libtool' doesn't try to 
replicate the CC linkage - in cases where people didn't try to work 
around this by manually linking their CC specific libs, they would be 
protected from the issue I encountered. I startled myself today 
realizing that I checked in a patch that would have caused `libtool' to 
make the exact issue that led me to learn about linking ( the irony 
would have been palpable ). I am interested to learn if the patches MSYS 
is using have caused the sort of UB I dealt with, I've got a list of at 
least 3 issues I'd wager they run into with C++ "old ABI", `pthread', 
and `dlopen'.

On 5/15/22 15:21, Martin Storsjö wrote:
> On Sun, 15 May 2022, Alex Ameen wrote:
>
>> Earlier this week I read through the thread, and created a patch 
>> based on the ones posted. This was checked if you would like to 
>> experiment with it.
>>
>> What I did notice was that this change has a wider effect than the 
>> problem statement initially suggests. I'm not crazy about the way it 
>> has a conditional behavior for two specific libraries since it is an 
>> ad-hoc solution directed at two compiler-collections, as opposed to a 
>> general purpose solution; but for the time being I see this as a 
>> practical change.
>>
>> As a side effect this change should also resolve issues with certain 
>> flag-specs such as `-fsanitize' which is nice; but the impact of 
>> unknown side effects is something I expect will rear its head in the 
>> near future. With that in mind, I think this is a necessary change, 
>> but I want to express up front that "I'm confident this will break a 
>> lot of existing builds, and I consider this to be a first draft".
>>
>> I would greatly appreciate y'all taking this for a spin on any 
>> available projects you have to get a sense of how it will behave "in 
>> the field". This change really effects "unspecified behavior" that 
>> the test-suite isn't designed to audit, but nonetheless has a 
>> practical effect on users.
>
> Thanks!
>
> I tested this now, and it doesn't work quite as is - it needs this 
> modification:
>
> diff --git a/m4/libtool.m4 b/m4/libtool.m4
> index ab5af335..9c084816 100644
> --- a/m4/libtool.m4
> +++ b/m4/libtool.m4
> @@ -7554,7 +7554,7 @@ if AC_TRY_EVAL(ac_compile); then
>    for p in `eval "$output_verbose_link_cmd"`; do
>      case $prev$p in
>
> -    -L* | -R* | -l* | */clang_rt*.a)
> +    -L* | -R* | -l* | */libclang_rt*.a)
>         # Some compilers place space between "-{L,R}" and the path.
>         # Remove the space.
>         if test x-L = "$p" ||
>
> (This was correct in one out of two instances in 
> 1d2577357ee704da2d6d7c7da119ad82ba8ca172.)
>
> With that changed, it does seem to work as it should for me on a test 
> project.
>
> // Martin
>
--------------pGPFuJ4cp4MUcNPAkKib58Gm
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Nice catch, I fat-fingered that one.<br>
    </p>
    <p>Could you share the workspace you tested in, or a snippet? I need
      to make a test case.<br>
      <br>
      <br>
      There was one aspect I wanted some clarity on though from the
      patches MSYS developed, which was "why is it that `m4/libtool.m4'
      used `*NAME*.a' when `build-aux/ltmain.in' used
      `*/libNAME*.$libext', and why they allowed `libgcc*' in
      `ltmain.in' but not `m4/libtool.m4'. I'm glad I looked into it
      because when I investigated the original patches' commit logs I
      realized that these were really just aimed at getting the builds
      for a small number of MSYS2 packages to succeed ( in the author's
      case VLC was the one they were focused on ); and that really this
      wasn't really designed to be a general purpose patch to `libtool'.
      From what I can tell MSYS2 is only using `libtool' for like 15
      packages, so for their use case hard coding a few whitelisted
      libraries is totally fine. I'm actually really glad I dug into
      this more because In the field this would have caused serious UB
      issues - the likes of which are actually what led me to learn
      about linking/loading and eventually towards `libtool'.<br>
      <br>
      I think my initial gut feeling on this one was right, and I'm
      probably going to revert that change and iron this out in a
      project branch that handles this alongside some related issues
      with flag-specs. The underlying problem here, which has been
      discussed in a few other threads is that `libtool' tries to
      outsmart the user and the compiler-collection by reinterpreting
      flags library linkage flags like `-l:libfoo.a' or `./libfoo.so',
      replacing them with `libfoo.la' and in rare cases even swapping
      system libs which entirely different alternatives for a particular
      platform.<br>
      <br>
      In the MSYS patches their issue was that `libtool' doesn't respect
      the flag-spec/implicit linkage for either GCC or Clang - so
      libraries which are implicitly linked by the compiler-collection
      such as `libgcc_s.so' or `libclang_rt.a' don't get added, usually
      what you get instead is a manual invocation of `ld'. The result is
      that libtool removes certain libs which are normally added by the
      compiler-collection's invocation of `ld':<br>
    </p>
    <pre>```
ld /path-to-libc/{crt1,crti}.o              \
   /path-to-cc/lib/crt&lt;CC-init&gt;.o           \  # CC adds, but not `libtool'
   &lt;USER-FLAGS&gt;                             \
   -L/path-to-cc/lib -l&lt;CC-libc-overrides&gt;  \  # CC adds, but not `libtool' ( almost always a static lib )
   -L/path-to-libc/lib -lc                  \
   -l&lt;CC-runtime&gt;                           \  # CC adds, but not `libtool' ( usually a shared lib )
   /path-to-cc/lib/crt&lt;CC-cleanup&gt;.o        \  # CC adds, but not `libtool' ( this one can get you in the most trouble )
   /path-to-libc/crtn.o;
```
</pre>
    <p>While the issues they're dealing with for Clang really focus on
      the RT and libc override style libraries - the CC specific `.o'
      files can be a real silent killer ( I know from experience before
      becoming maintainer ). The solution I'd like for this is going to
      take some time to develop, and is going to require some real
      changes to the stated behavior of `libtool' ( definitely not
      backwards compatible ) - but `libtool' needs to either parse
      flag-specs and perfectly reproduce the underlying CC's implicit
      libs, or it needs to stop directly invoking `ld'.<br>
      <br>
      The big issue I see with the MSYS patches, and similar ad-hoc
      patches that have been submitted to work around issues in
      flag-specs `-fsanitize=' for example ) is that they often
      explicitly add linkage for the relevant libraries, and fail to add
      linkage for the `.o' files. The nasty thing about this is that
      it'll probably work fine 99% of the time, but the 1% of the time
      that it misbehaves will be nearly impossible to debug. You have
      initialization/cleanup routine in those `.o' files that alter the
      initialization of executables and shared libraries in discreet
      ways which effect a subset of of the RT and libc override
      implementations provided by CCs - if those routines aren't linked
      you often won't get a failure at link-editing time, rather you'll
      get bizarre UB at runtime and ( in my experience ) by the time you
      figure out what's wrong you'll have read two books, read the
      manuals for CC and `ld' backwards and forwards a dozen times, GDB
      sessions will haunt your dreams, and four months of your life have
      passed by lol.<br>
      <br>
      In my case the mistake didn't involve `libtool', it was just a dev
      dropping the ball while porting a Makefile from AIX to Linux. It's
      worth noting, that as obnoxious as it is that `libtool' doesn't
      try to replicate the CC linkage - in cases where people didn't try
      to work around this by manually linking their CC specific libs,
      they would be protected from the issue I encountered. I startled
      myself today realizing that I checked in a patch that would have
      caused `libtool' to make the exact issue that led me to learn
      about linking ( the irony would have been palpable ). I am
      interested to learn if the patches MSYS is using have caused the
      sort of UB I dealt with, I've got a list of at least 3 issues I'd
      wager they run into with C++ "old ABI", `pthread', and `dlopen'.<br>
      <br>
    </p>
    <div class="moz-cite-prefix">On 5/15/22 15:21, Martin Storsjö wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:63a4df41-93c8-c54-307c-2bff6edb3589@HIDDEN">On Sun,
      15 May 2022, Alex Ameen wrote:
      <br>
      <br>
      <blockquote type="cite">Earlier this week I read through the
        thread, and created a patch based on the ones posted. This was
        checked if you would like to experiment with it.
        <br>
        <br>
        What I did notice was that this change has a wider effect than
        the problem statement initially suggests. I'm not crazy about
        the way it has a conditional behavior for two specific libraries
        since it is an ad-hoc solution directed at two
        compiler-collections, as opposed to a general purpose solution;
        but for the time being I see this as a practical change.
        <br>
        <br>
        As a side effect this change should also resolve issues with
        certain flag-specs such as `-fsanitize' which is nice; but the
        impact of unknown side effects is something I expect will rear
        its head in the near future. With that in mind, I think this is
        a necessary change, but I want to express up front that "I'm
        confident this will break a lot of existing builds, and I
        consider this to be a first draft".
        <br>
        <br>
        I would greatly appreciate y'all taking this for a spin on any
        available projects you have to get a sense of how it will behave
        "in the field". This change really effects "unspecified
        behavior" that the test-suite isn't designed to audit, but
        nonetheless has a practical effect on users.
        <br>
      </blockquote>
      <br>
      Thanks!
      <br>
      <br>
      I tested this now, and it doesn't work quite as is - it needs this
      modification:
      <br>
      <br>
      diff --git a/m4/libtool.m4 b/m4/libtool.m4
      <br>
      index ab5af335..9c084816 100644
      <br>
      --- a/m4/libtool.m4
      <br>
      +++ b/m4/libtool.m4
      <br>
      @@ -7554,7 +7554,7 @@ if AC_TRY_EVAL(ac_compile); then
      <br>
         for p in `eval "$output_verbose_link_cmd"`; do
      <br>
           case $prev$p in
      <br>
      <br>
      -    -L* | -R* | -l* | */clang_rt*.a)
      <br>
      +    -L* | -R* | -l* | */libclang_rt*.a)
      <br>
              # Some compilers place space between "-{L,R}" and the
      path.
      <br>
              # Remove the space.
      <br>
              if test x-L = "$p" ||
      <br>
      <br>
      (This was correct in one out of two instances in
      1d2577357ee704da2d6d7c7da119ad82ba8ca172.)
      <br>
      <br>
      With that changed, it does seem to work as it should for me on a
      test project.
      <br>
      <br>
      // Martin
      <br>
      <br>
    </blockquote>
  </body>
</html>

--------------pGPFuJ4cp4MUcNPAkKib58Gm--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Mon, 16 May 2022 07:27:02 +0000
Resent-Message-ID: <handler.27866.B.165268600429892 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Alex Ameen <alex.ameen.tx@HIDDEN>
Cc: praiskup@HIDDEN, 27866 <at> debbugs.gnu.org, shea@HIDDEN, bfriesen@HIDDEN, manojgupta@HIDDEN
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, bug-libtool@HIDDEN, Shea Levy <shea@HIDDEN>, 27866 <at> debbugs.gnu.org, Bob Friesenhahn <bfriesen@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>
Received: via spool by submit <at> debbugs.gnu.org id=B.165268600429892
          (code B ref -1); Mon, 16 May 2022 07:27:02 +0000
Received: (at submit) by debbugs.gnu.org; 16 May 2022 07:26:44 +0000
Received: from localhost ([127.0.0.1]:51534 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nqV7q-0007m2-Fl
	for submit <at> debbugs.gnu.org; Mon, 16 May 2022 03:26:43 -0400
Received: from lists.gnu.org ([209.51.188.17]:44046)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <martin@HIDDEN>) id 1nqV7n-0007lt-Hm
 for submit <at> debbugs.gnu.org; Mon, 16 May 2022 03:26:40 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:36106)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <martin@HIDDEN>) id 1nqV7n-0000qc-8E
 for bug-libtool@HIDDEN; Mon, 16 May 2022 03:26:39 -0400
Received: from mail8.parnet.fi ([77.234.108.134]:23662)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <martin@HIDDEN>) id 1nqV7j-0000Zz-Sm
 for bug-libtool@HIDDEN; Mon, 16 May 2022 03:26:38 -0400
Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21])
 by mail8.parnet.fi  with ESMTP id 24G7QLVu015310-24G7QLVv015310;
 Mon, 16 May 2022 10:26:21 +0300
Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187])
 by mail9.parnet.fi (Postfix) with ESMTPS id 60EFCA150B;
 Mon, 16 May 2022 10:26:20 +0300 (EEST)
Date: Mon, 16 May 2022 10:26:19 +0300 (EEST)
From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
In-Reply-To: <43f80a1b-e0f1-cd2a-9f12-f839b7c79125@HIDDEN>
Message-ID: <756f3af-b39b-8033-63e3-d742256aa31@HIDDEN>
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@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>
 <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@HIDDEN>
 <8735hnj81r.fsf@HIDDEN>
 <9f84eb26-d083-01ef-cc07-cc8bb586c1c1@HIDDEN>
 <63a4df41-93c8-c54-307c-2bff6edb3589@HIDDEN>
 <43f80a1b-e0f1-cd2a-9f12-f839b7c79125@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-FE-Policy-ID: 3:14:2:SYSTEM
Received-SPF: pass client-ip=77.234.108.134; envelope-from=martin@HIDDEN;
 helo=mail8.parnet.fi
X-Spam_score_int: -25
X-Spam_score: -2.6
X-Spam_bar: --
X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.7 (-)
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.7 (--)

On Sun, 15 May 2022, Alex Ameen wrote:

> Could you share the workspace you tested in, or a snippet? I need to make a
> test case.

This can reproduced with most libtool based projects that include C++ 
code. One example that I used for small standalone testing is this: 
http://github.com/mstorsjo/fdk-aac

This project normally links the library as if it was C code, not C++, to 
avoid unnecessary dependencies on the C++ standard library (which also 
implicitly avoids this issue). To expose this issue, uncomment this line 
in Makefile.am:

     libfdk_aac_la_LINK = $(LINK) $(libfdk_aac_la_LDFLAGS)

Then regenerate the build files with ./autogen.sh.

Then build the project with a toolchain from 
https://github.com/mstorsjo/llvm-mingw/releases - there are prebuilt ones 
for x86_64 and aarch64 linux and macos (and windows). Assuming you run on 
linux, configure the project like this:

    ../fdk-aac/configure --host=x86_64-w64-mingw32

When building, you'll end up with this build error:

   CXXLD    libfdk-aac.la
ld.lld: error: undefined symbol: ___chkstk_ms
>>> referenced by ../fdk-aac/libAACdec/src/FDK_delay.cpp:130
>>> 
libAACdec/src/.libs/FDK_delay.o:(FDK_Delay_Apply(FDK_SignalDelay*, long*, 
unsigned int, unsigned char))
>>> referenced by ../fdk-aac/libAACdec/src/aacdec_hcr.cpp:435
>>> 
libAACdec/src/.libs/aacdec_hcr.o:(HcrDecoder(CErHcrInfo*, 
CAacDecoderChannelInfo*, SamplingRateInfo const*, FDK_BITSTREAM*))
>>> referenced by ../fdk-aac/libAACdec/src/aacdecoder.cpp:2520
>>> 
libAACdec/src/.libs/aacdecoder.o:(CAacDecoder_DecodeFrame(AAC_DECODER_INSTANCE*, 
unsigned int, long*, int, int))
>>> referenced 14 more times

Are you able to reproduce this setup, or do you want me to package up a 
full build environment with the pre-setup code in this configuration?


> There was one aspect I wanted some clarity on though from the patches MSYS
> developed, which was "why is it that `m4/libtool.m4' used `*NAME*.a' when
> `build-aux/ltmain.in' used `*/libNAME*.$libext',

Which patch is that? In both 
https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011-Pick-up-clang_rt-static-archives-compiler-internal-l.patch 
and 
https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013-Allow-statically-linking-compiler-support-libraries-.patch 
it's spelled out as libclang_rt and libgcc, not *clang_rt.

> and why they allowed `libgcc*' in `ltmain.in' but not `m4/libtool.m4'.

The reason for that is that when clang refers to the clang_rt builtins 
library, it does so by passing an absolute path to 
libclang_rt.builtins-<arch>.a is specified in the link command (which 
libtool tries to analyze and pick up, by running $CC -v).

https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011-Pick-up-clang_rt-static-archives-compiler-internal-l.patch 
makes sure that this library is picked up here. For the case of libgcc, 
it's never specified as an absolute path to the library, but always 
specified as -lgcc<suffixes> which libtool does pick up on. So the patch 
to m4/libtool.m4 only needs special casing of libclang_rt.builtins; libgcc 
is handled just fine by the existing pattern of -l*.

But later if either libclang_rt.builtins, or libgcc, is linked statically 
(the only option for libclang_rt.builtins), they need to be marked as 
allowed in build-aux/ltmain.in, in 
https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013-Allow-statically-linking-compiler-support-libraries-.patch.

> I'm glad I looked into it because when I investigated the original 
> patches' commit logs I realized that these were really just aimed at 
> getting the builds for a small number of MSYS2 packages to succeed ( in 
> the author's case VLC was the one they were focused on );

I think that author you refer to is me.

> and that really this wasn't really designed to be a general purpose 
> patch to `libtool'.

It was meant to be a as general purpose patch as possible, to fix the 
issues I had observed - without having the entirely full picture as I'm 
not the libtool maintainer of course. But they were indeed meant to be 
upstreamable.

> From what I can tell MSYS2 is only using `libtool' for like 15 packages, 
> so for their use case hard coding a few whitelisted libraries is totally 
> fine.

That sounds like an incorrect conclusion.

The MSYS2 packaged and patched libtool is used when building the packages 
in https://github.com/msys2/MINGW-packages/. Currently this is a bit over 
2000 packages. Out of those, 320 have 'autoreconf' as part of their build 
instructions, 63 contain 'autogen.sh', 13 contain 'libtoolize'.

So roughly at least around 400 packages are routinely built with the MSYS2 
patched libtool installed in the packages - possibly some more that update 
their bundled libtool via some other command.

> but `libtool' needs to either parse flag-specs and perfectly reproduce 
> the underlying CC's implicit libs, or it needs to stop directly invoking 
> `ld'.

Indeed, I never quite understood why libtool needs to build C++ libraries 
with -nostdlib and try to replicate the compiler's default libraries in 
the first place.

> The big issue I see with the MSYS patches, and similar ad-hoc patches 
> that have been submitted to work around issues in flag-specs 
> `-fsanitize=' for example ) is that they often explicitly add linkage 
> for the relevant libraries, and fail to add linkage for the `.o' files.

I'm not familiar with the patches for '-fsanitize=' - but in the case of 
the patch I'm primarily talking about, it's all about the single static 
library libclang_rt.builtins-<arch>.a, which doesn't have any associated 
object files. I'm not referring to the sanitizers (which do have a much 
more tricky setup), but just the compiler helper builtins library, which 
doesn't have any of the tricky-init-object-files issues.

// Martin

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Mon, 16 May 2022 07:27:02 +0000
Resent-Message-ID: <handler.27866.B27866.165268599529869 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Alex Ameen <alex.ameen.tx@HIDDEN>
Cc: praiskup@HIDDEN, 27866 <at> debbugs.gnu.org, shea@HIDDEN, bfriesen@HIDDEN, manojgupta@HIDDEN
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, bug-libtool@HIDDEN, Shea Levy <shea@HIDDEN>, 27866 <at> debbugs.gnu.org, Bob Friesenhahn <bfriesen@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.165268599529869
          (code B ref 27866); Mon, 16 May 2022 07:27:02 +0000
Received: (at 27866) by debbugs.gnu.org; 16 May 2022 07:26:35 +0000
Received: from localhost ([127.0.0.1]:51531 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nqV7i-0007lg-23
	for submit <at> debbugs.gnu.org; Mon, 16 May 2022 03:26:35 -0400
Received: from mail8.parnet.fi ([77.234.108.134]:36204)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <martin@HIDDEN>) id 1nqV7f-0007lQ-3C
 for 27866 <at> debbugs.gnu.org; Mon, 16 May 2022 03:26:32 -0400
Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21])
 by mail8.parnet.fi  with ESMTP id 24G7QLVu015310-24G7QLVv015310;
 Mon, 16 May 2022 10:26:21 +0300
Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187])
 by mail9.parnet.fi (Postfix) with ESMTPS id 60EFCA150B;
 Mon, 16 May 2022 10:26:20 +0300 (EEST)
Date: Mon, 16 May 2022 10:26:19 +0300 (EEST)
From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
In-Reply-To: <43f80a1b-e0f1-cd2a-9f12-f839b7c79125@HIDDEN>
Message-ID: <756f3af-b39b-8033-63e3-d742256aa31@HIDDEN>
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@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>
 <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@HIDDEN>
 <8735hnj81r.fsf@HIDDEN>
 <9f84eb26-d083-01ef-cc07-cc8bb586c1c1@HIDDEN>
 <63a4df41-93c8-c54-307c-2bff6edb3589@HIDDEN>
 <43f80a1b-e0f1-cd2a-9f12-f839b7c79125@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-FE-Policy-ID: 3:14:2:SYSTEM
X-Spam-Score: -0.7 (/)
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 (-)

On Sun, 15 May 2022, Alex Ameen wrote:

> Could you share the workspace you tested in, or a snippet? I need to make a
> test case.

This can reproduced with most libtool based projects that include C++ 
code. One example that I used for small standalone testing is this: 
http://github.com/mstorsjo/fdk-aac

This project normally links the library as if it was C code, not C++, to 
avoid unnecessary dependencies on the C++ standard library (which also 
implicitly avoids this issue). To expose this issue, uncomment this line 
in Makefile.am:

     libfdk_aac_la_LINK = $(LINK) $(libfdk_aac_la_LDFLAGS)

Then regenerate the build files with ./autogen.sh.

Then build the project with a toolchain from 
https://github.com/mstorsjo/llvm-mingw/releases - there are prebuilt ones 
for x86_64 and aarch64 linux and macos (and windows). Assuming you run on 
linux, configure the project like this:

    ../fdk-aac/configure --host=x86_64-w64-mingw32

When building, you'll end up with this build error:

   CXXLD    libfdk-aac.la
ld.lld: error: undefined symbol: ___chkstk_ms
>>> referenced by ../fdk-aac/libAACdec/src/FDK_delay.cpp:130
>>> 
libAACdec/src/.libs/FDK_delay.o:(FDK_Delay_Apply(FDK_SignalDelay*, long*, 
unsigned int, unsigned char))
>>> referenced by ../fdk-aac/libAACdec/src/aacdec_hcr.cpp:435
>>> 
libAACdec/src/.libs/aacdec_hcr.o:(HcrDecoder(CErHcrInfo*, 
CAacDecoderChannelInfo*, SamplingRateInfo const*, FDK_BITSTREAM*))
>>> referenced by ../fdk-aac/libAACdec/src/aacdecoder.cpp:2520
>>> 
libAACdec/src/.libs/aacdecoder.o:(CAacDecoder_DecodeFrame(AAC_DECODER_INSTANCE*, 
unsigned int, long*, int, int))
>>> referenced 14 more times

Are you able to reproduce this setup, or do you want me to package up a 
full build environment with the pre-setup code in this configuration?


> There was one aspect I wanted some clarity on though from the patches MSYS
> developed, which was "why is it that `m4/libtool.m4' used `*NAME*.a' when
> `build-aux/ltmain.in' used `*/libNAME*.$libext',

Which patch is that? In both 
https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011-Pick-up-clang_rt-static-archives-compiler-internal-l.patch 
and 
https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013-Allow-statically-linking-compiler-support-libraries-.patch 
it's spelled out as libclang_rt and libgcc, not *clang_rt.

> and why they allowed `libgcc*' in `ltmain.in' but not `m4/libtool.m4'.

The reason for that is that when clang refers to the clang_rt builtins 
library, it does so by passing an absolute path to 
libclang_rt.builtins-<arch>.a is specified in the link command (which 
libtool tries to analyze and pick up, by running $CC -v).

https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011-Pick-up-clang_rt-static-archives-compiler-internal-l.patch 
makes sure that this library is picked up here. For the case of libgcc, 
it's never specified as an absolute path to the library, but always 
specified as -lgcc<suffixes> which libtool does pick up on. So the patch 
to m4/libtool.m4 only needs special casing of libclang_rt.builtins; libgcc 
is handled just fine by the existing pattern of -l*.

But later if either libclang_rt.builtins, or libgcc, is linked statically 
(the only option for libclang_rt.builtins), they need to be marked as 
allowed in build-aux/ltmain.in, in 
https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013-Allow-statically-linking-compiler-support-libraries-.patch.

> I'm glad I looked into it because when I investigated the original 
> patches' commit logs I realized that these were really just aimed at 
> getting the builds for a small number of MSYS2 packages to succeed ( in 
> the author's case VLC was the one they were focused on );

I think that author you refer to is me.

> and that really this wasn't really designed to be a general purpose 
> patch to `libtool'.

It was meant to be a as general purpose patch as possible, to fix the 
issues I had observed - without having the entirely full picture as I'm 
not the libtool maintainer of course. But they were indeed meant to be 
upstreamable.

> From what I can tell MSYS2 is only using `libtool' for like 15 packages, 
> so for their use case hard coding a few whitelisted libraries is totally 
> fine.

That sounds like an incorrect conclusion.

The MSYS2 packaged and patched libtool is used when building the packages 
in https://github.com/msys2/MINGW-packages/. Currently this is a bit over 
2000 packages. Out of those, 320 have 'autoreconf' as part of their build 
instructions, 63 contain 'autogen.sh', 13 contain 'libtoolize'.

So roughly at least around 400 packages are routinely built with the MSYS2 
patched libtool installed in the packages - possibly some more that update 
their bundled libtool via some other command.

> but `libtool' needs to either parse flag-specs and perfectly reproduce 
> the underlying CC's implicit libs, or it needs to stop directly invoking 
> `ld'.

Indeed, I never quite understood why libtool needs to build C++ libraries 
with -nostdlib and try to replicate the compiler's default libraries in 
the first place.

> The big issue I see with the MSYS patches, and similar ad-hoc patches 
> that have been submitted to work around issues in flag-specs 
> `-fsanitize=' for example ) is that they often explicitly add linkage 
> for the relevant libraries, and fail to add linkage for the `.o' files.

I'm not familiar with the patches for '-fsanitize=' - but in the case of 
the patch I'm primarily talking about, it's all about the single static 
library libclang_rt.builtins-<arch>.a, which doesn't have any associated 
object files. I'm not referring to the sanitizers (which do have a much 
more tricky setup), but just the compiler helper builtins library, which 
doesn't have any of the tricky-init-object-files issues.

// Martin

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Alex Ameen <alex.ameen.tx@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Mon, 16 May 2022 14:19:02 +0000
Resent-Message-ID: <handler.27866.B.16527107135398 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Cc: praiskup@HIDDEN, 27866 <at> debbugs.gnu.org, shea@HIDDEN, bfriesen@HIDDEN, manojgupta@HIDDEN
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, bug-libtool@HIDDEN, Shea Levy <shea@HIDDEN>, 27866 <at> debbugs.gnu.org, Bob Friesenhahn <bfriesen@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>
Received: via spool by submit <at> debbugs.gnu.org id=B.16527107135398
          (code B ref -1); Mon, 16 May 2022 14:19:02 +0000
Received: (at submit) by debbugs.gnu.org; 16 May 2022 14:18:33 +0000
Received: from localhost ([127.0.0.1]:54687 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nqbYN-0001Oz-Jc
	for submit <at> debbugs.gnu.org; Mon, 16 May 2022 10:18:33 -0400
Received: from lists.gnu.org ([209.51.188.17]:46988)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <alex.ameen.tx@HIDDEN>) id 1nqbYB-0001OR-JY
 for submit <at> debbugs.gnu.org; Mon, 16 May 2022 10:18:30 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:43380)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <alex.ameen.tx@HIDDEN>)
 id 1nqbYA-00065M-7V
 for bug-libtool@HIDDEN; Mon, 16 May 2022 10:18:19 -0400
Received: from mail-vs1-xe32.google.com ([2607:f8b0:4864:20::e32]:40659)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <alex.ameen.tx@HIDDEN>)
 id 1nqbY7-00038J-Rw
 for bug-libtool@HIDDEN; Mon, 16 May 2022 10:18:17 -0400
Received: by mail-vs1-xe32.google.com with SMTP id y74so15646464vsy.7
 for <bug-libtool@HIDDEN>; Mon, 16 May 2022 07:18:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=Uk2CvJKgmk/0fhiK+0UcdBPMKcVp0O1Rb7hShQ8h9/k=;
 b=ZOhmBxV4VgghuSepZrJMFPzSj9jLwi6ahU/IWGMuyNzH5FkOWtbLmAVw2gnvmGRW8L
 VLVZQ3IlwFcIbBlpbnq9Grc14fbxn1tqIb5f7HIZMeZGhaAqO0uEebYEWbkDNuf3AKHW
 H5PEG2zVFICiv5VFZz+2TqJc0+RRRUKNGLgz+XD9G7sZyoNB8ENb848jOKZAm/vUQ5CT
 hIA/HnxX3wAJOw3p1ASva/CwCC6d7hPKLOcV65TMrH6sMIMVyTFP2uFAzYXbtOJ3aEQz
 MfzMWdk48eGFcszbRR5KGg7Gx0jRncCRtndexVjwVq8N9zur+DJcAsyJpDTUslsXDAvY
 OqYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=Uk2CvJKgmk/0fhiK+0UcdBPMKcVp0O1Rb7hShQ8h9/k=;
 b=6/ALxw/AY/QamLSt3LUxHfcbmjQyKEE/SVOB04dIL2nHQVX4W/TlBynE164V2PwbAa
 vah2oXz5F52AUcqJDe+EpdmruivJojeoyPU0XWXbAtJ0zcVI1UNnCVVmg+VszWRC5Eim
 /N/sADIZLIaFMtovAFRlDIONchuzQCrrV/sw2IWAxW+O6S1+5Idpx5R6e+cxq5cxPj/N
 oePNYWZU2mreJnHyoLUDNg/vz55RIssk5GEbj3SihmQmOTPJ1JN7pRrxtVBTNcji1fkm
 rou7le3HbUL6C4jwc2e+P2irxneVoNbshbYRTvZ1oy8HYGqbQuQ2fi0/xmF5U25OpU2j
 2jEg==
X-Gm-Message-State: AOAM533/knnw88C9CeUoxyF7xFU22qEmrsp7z3anpUlqyG9YP6JMGdHx
 HW/u46FjFb5NpagYY6oHXTYzCJ6nIzO1g6fbmno=
X-Google-Smtp-Source: ABdhPJx/fowlZ4LymIPdLpew6L7PjKY998DOv+khx/3QLNNXtQThWiVgaZDuuWQA5X75ShbHqj7jTBgwZO5mNLle0PE=
X-Received: by 2002:a67:e047:0:b0:32d:54c5:28a5 with SMTP id
 n7-20020a67e047000000b0032d54c528a5mr6148625vsl.20.1652710694824; Mon, 16 May
 2022 07:18:14 -0700 (PDT)
MIME-Version: 1.0
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@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>
 <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@HIDDEN>
 <8735hnj81r.fsf@HIDDEN>
 <9f84eb26-d083-01ef-cc07-cc8bb586c1c1@HIDDEN>
 <63a4df41-93c8-c54-307c-2bff6edb3589@HIDDEN>
 <43f80a1b-e0f1-cd2a-9f12-f839b7c79125@HIDDEN>
 <756f3af-b39b-8033-63e3-d742256aa31@HIDDEN>
In-Reply-To: <756f3af-b39b-8033-63e3-d742256aa31@HIDDEN>
From: Alex Ameen <alex.ameen.tx@HIDDEN>
Date: Mon, 16 May 2022 09:18:03 -0500
Message-ID: <CAKgHvyv0cQh_ugfK-k5JWY2yi2BfuNeUCoFoQGbL4YaAV-H9Yw@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000e1af9105df21b10a"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e32;
 envelope-from=alex.ameen.tx@HIDDEN; helo=mail-vs1-xe32.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
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.3 (--)

--000000000000e1af9105df21b10a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey I reread my message, and will make my way through your responses today,
but something I forgot to mention was : really thank you for submitting
these. I hope my response didn't come across as critical. I really do
appreciate the work you've done here, and the effort you've made towards
clarifying.

On Mon, May 16, 2022, 2:26 AM Martin Storsj=C3=B6 <martin@HIDDEN> wrote:

> On Sun, 15 May 2022, Alex Ameen wrote:
>
> > Could you share the workspace you tested in, or a snippet? I need to
> make a
> > test case.
>
> This can reproduced with most libtool based projects that include C++
> code. One example that I used for small standalone testing is this:
> http://github.com/mstorsjo/fdk-aac
>
> This project normally links the library as if it was C code, not C++, to
> avoid unnecessary dependencies on the C++ standard library (which also
> implicitly avoids this issue). To expose this issue, uncomment this line
> in Makefile.am:
>
>      libfdk_aac_la_LINK =3D $(LINK) $(libfdk_aac_la_LDFLAGS)
>
> Then regenerate the build files with ./autogen.sh.
>
> Then build the project with a toolchain from
> https://github.com/mstorsjo/llvm-mingw/releases - there are prebuilt ones
> for x86_64 and aarch64 linux and macos (and windows). Assuming you run on
> linux, configure the project like this:
>
>     ../fdk-aac/configure --host=3Dx86_64-w64-mingw32
>
> When building, you'll end up with this build error:
>
>    CXXLD    libfdk-aac.la
> ld.lld: error: undefined symbol: ___chkstk_ms
> >>> referenced by ../fdk-aac/libAACdec/src/FDK_delay.cpp:130
> >>>
> libAACdec/src/.libs/FDK_delay.o:(FDK_Delay_Apply(FDK_SignalDelay*, long*,
> unsigned int, unsigned char))
> >>> referenced by ../fdk-aac/libAACdec/src/aacdec_hcr.cpp:435
> >>>
> libAACdec/src/.libs/aacdec_hcr.o:(HcrDecoder(CErHcrInfo*,
> CAacDecoderChannelInfo*, SamplingRateInfo const*, FDK_BITSTREAM*))
> >>> referenced by ../fdk-aac/libAACdec/src/aacdecoder.cpp:2520
> >>>
> libAACdec/src/.libs/aacdecoder.o:(CAacDecoder_DecodeFrame(AAC_DECODER_INS=
TANCE*,
>
> unsigned int, long*, int, int))
> >>> referenced 14 more times
>
> Are you able to reproduce this setup, or do you want me to package up a
> full build environment with the pre-setup code in this configuration?
>
>
> > There was one aspect I wanted some clarity on though from the patches
> MSYS
> > developed, which was "why is it that `m4/libtool.m4' used `*NAME*.a' wh=
en
> > `build-aux/ltmain.in' used `*/libNAME*.$libext',
>
> Which patch is that? In both
>
> https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011-Pick-up-=
clang_rt-static-archives-compiler-internal-l.patch
> and
>
> https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013-Allow-st=
atically-linking-compiler-support-libraries-.patch
> it's spelled out as libclang_rt and libgcc, not *clang_rt.
>
> > and why they allowed `libgcc*' in `ltmain.in' but not `m4/libtool.m4'.
>
> The reason for that is that when clang refers to the clang_rt builtins
> library, it does so by passing an absolute path to
> libclang_rt.builtins-<arch>.a is specified in the link command (which
> libtool tries to analyze and pick up, by running $CC -v).
>
>
> https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011-Pick-up-=
clang_rt-static-archives-compiler-internal-l.patch
> makes sure that this library is picked up here. For the case of libgcc,
> it's never specified as an absolute path to the library, but always
> specified as -lgcc<suffixes> which libtool does pick up on. So the patch
> to m4/libtool.m4 only needs special casing of libclang_rt.builtins; libgc=
c
> is handled just fine by the existing pattern of -l*.
>
> But later if either libclang_rt.builtins, or libgcc, is linked statically
> (the only option for libclang_rt.builtins), they need to be marked as
> allowed in build-aux/ltmain.in, in
>
> https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013-Allow-st=
atically-linking-compiler-support-libraries-.patch
> .
>
> > I'm glad I looked into it because when I investigated the original
> > patches' commit logs I realized that these were really just aimed at
> > getting the builds for a small number of MSYS2 packages to succeed ( in
> > the author's case VLC was the one they were focused on );
>
> I think that author you refer to is me.
>
> > and that really this wasn't really designed to be a general purpose
> > patch to `libtool'.
>
> It was meant to be a as general purpose patch as possible, to fix the
> issues I had observed - without having the entirely full picture as I'm
> not the libtool maintainer of course. But they were indeed meant to be
> upstreamable.
>
> > From what I can tell MSYS2 is only using `libtool' for like 15 packages=
,
> > so for their use case hard coding a few whitelisted libraries is totall=
y
> > fine.
>
> That sounds like an incorrect conclusion.
>
> The MSYS2 packaged and patched libtool is used when building the packages
> in https://github.com/msys2/MINGW-packages/. Currently this is a bit over
> 2000 packages. Out of those, 320 have 'autoreconf' as part of their build
> instructions, 63 contain 'autogen.sh', 13 contain 'libtoolize'.
>
> So roughly at least around 400 packages are routinely built with the MSYS=
2
> patched libtool installed in the packages - possibly some more that updat=
e
> their bundled libtool via some other command.
>
> > but `libtool' needs to either parse flag-specs and perfectly reproduce
> > the underlying CC's implicit libs, or it needs to stop directly invokin=
g
> > `ld'.
>
> Indeed, I never quite understood why libtool needs to build C++ libraries
> with -nostdlib and try to replicate the compiler's default libraries in
> the first place.
>
> > The big issue I see with the MSYS patches, and similar ad-hoc patches
> > that have been submitted to work around issues in flag-specs
> > `-fsanitize=3D' for example ) is that they often explicitly add linkage
> > for the relevant libraries, and fail to add linkage for the `.o' files.
>
> I'm not familiar with the patches for '-fsanitize=3D' - but in the case o=
f
> the patch I'm primarily talking about, it's all about the single static
> library libclang_rt.builtins-<arch>.a, which doesn't have any associated
> object files. I'm not referring to the sanitizers (which do have a much
> more tricky setup), but just the compiler helper builtins library, which
> doesn't have any of the tricky-init-object-files issues.
>
> // Martin
>
>

--000000000000e1af9105df21b10a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hey I reread my message, and will make my way through you=
r responses today, but something I forgot to=C2=A0mention was : really than=
k you for submitting these. I hope my response didn&#39;t come across as cr=
itical. I really do appreciate the work you&#39;ve done here, and the effor=
t you&#39;ve made towards clarifying.</div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 16, 2022, 2:26 AM Martin S=
torsj=C3=B6 &lt;<a href=3D"mailto:martin@HIDDEN">martin@HIDDEN</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, 15 May 2022, Alex =
Ameen wrote:<br>
<br>
&gt; Could you share the workspace you tested in, or a snippet? I need to m=
ake a<br>
&gt; test case.<br>
<br>
This can reproduced with most libtool based projects that include C++ <br>
code. One example that I used for small standalone testing is this: <br>
<a href=3D"http://github.com/mstorsjo/fdk-aac" rel=3D"noreferrer noreferrer=
" target=3D"_blank">http://github.com/mstorsjo/fdk-aac</a><br>
<br>
This project normally links the library as if it was C code, not C++, to <b=
r>
avoid unnecessary dependencies on the C++ standard library (which also <br>
implicitly avoids this issue). To expose this issue, uncomment this line <b=
r>
in Makefile.am:<br>
<br>
=C2=A0 =C2=A0 =C2=A0libfdk_aac_la_LINK =3D $(LINK) $(libfdk_aac_la_LDFLAGS)=
<br>
<br>
Then regenerate the build files with ./autogen.sh.<br>
<br>
Then build the project with a toolchain from <br>
<a href=3D"https://github.com/mstorsjo/llvm-mingw/releases" rel=3D"noreferr=
er noreferrer" target=3D"_blank">https://github.com/mstorsjo/llvm-mingw/rel=
eases</a> - there are prebuilt ones <br>
for x86_64 and aarch64 linux and macos (and windows). Assuming you run on <=
br>
linux, configure the project like this:<br>
<br>
=C2=A0 =C2=A0 ../fdk-aac/configure --host=3Dx86_64-w64-mingw32<br>
<br>
When building, you&#39;ll end up with this build error:<br>
<br>
=C2=A0 =C2=A0CXXLD=C2=A0 =C2=A0 <a href=3D"http://libfdk-aac.la" rel=3D"nor=
eferrer noreferrer" target=3D"_blank">libfdk-aac.la</a><br>
ld.lld: error: undefined symbol: ___chkstk_ms<br>
&gt;&gt;&gt; referenced by ../fdk-aac/libAACdec/src/FDK_delay.cpp:130<br>
&gt;&gt;&gt; <br>
libAACdec/src/.libs/FDK_delay.o:(FDK_Delay_Apply(FDK_SignalDelay*, long*, <=
br>
unsigned int, unsigned char))<br>
&gt;&gt;&gt; referenced by ../fdk-aac/libAACdec/src/aacdec_hcr.cpp:435<br>
&gt;&gt;&gt; <br>
libAACdec/src/.libs/aacdec_hcr.o:(HcrDecoder(CErHcrInfo*, <br>
CAacDecoderChannelInfo*, SamplingRateInfo const*, FDK_BITSTREAM*))<br>
&gt;&gt;&gt; referenced by ../fdk-aac/libAACdec/src/aacdecoder.cpp:2520<br>
&gt;&gt;&gt; <br>
libAACdec/src/.libs/aacdecoder.o:(CAacDecoder_DecodeFrame(AAC_DECODER_INSTA=
NCE*, <br>
unsigned int, long*, int, int))<br>
&gt;&gt;&gt; referenced 14 more times<br>
<br>
Are you able to reproduce this setup, or do you want me to package up a <br=
>
full build environment with the pre-setup code in this configuration?<br>
<br>
<br>
&gt; There was one aspect I wanted some clarity on though from the patches =
MSYS<br>
&gt; developed, which was &quot;why is it that `m4/libtool.m4&#39; used `*N=
AME*.a&#39; when<br>
&gt; `build-aux/<a href=3D"http://ltmain.in" rel=3D"noreferrer noreferrer" =
target=3D"_blank">ltmain.in</a>&#39; used `*/libNAME*.$libext&#39;,<br>
<br>
Which patch is that? In both <br>
<a href=3D"https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011=
-Pick-up-clang_rt-static-archives-compiler-internal-l.patch" rel=3D"norefer=
rer noreferrer" target=3D"_blank">https://github.com/msys2/MSYS2-packages/b=
lob/master/libtool/0011-Pick-up-clang_rt-static-archives-compiler-internal-=
l.patch</a> <br>
and <br>
<a href=3D"https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013=
-Allow-statically-linking-compiler-support-libraries-.patch" rel=3D"norefer=
rer noreferrer" target=3D"_blank">https://github.com/msys2/MSYS2-packages/b=
lob/master/libtool/0013-Allow-statically-linking-compiler-support-libraries=
-.patch</a> <br>
it&#39;s spelled out as libclang_rt and libgcc, not *clang_rt.<br>
<br>
&gt; and why they allowed `libgcc*&#39; in `<a href=3D"http://ltmain.in" re=
l=3D"noreferrer noreferrer" target=3D"_blank">ltmain.in</a>&#39; but not `m=
4/libtool.m4&#39;.<br>
<br>
The reason for that is that when clang refers to the clang_rt builtins <br>
library, it does so by passing an absolute path to <br>
libclang_rt.builtins-&lt;arch&gt;.a is specified in the link command (which=
 <br>
libtool tries to analyze and pick up, by running $CC -v).<br>
<br>
<a href=3D"https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011=
-Pick-up-clang_rt-static-archives-compiler-internal-l.patch" rel=3D"norefer=
rer noreferrer" target=3D"_blank">https://github.com/msys2/MSYS2-packages/b=
lob/master/libtool/0011-Pick-up-clang_rt-static-archives-compiler-internal-=
l.patch</a> <br>
makes sure that this library is picked up here. For the case of libgcc, <br=
>
it&#39;s never specified as an absolute path to the library, but always <br=
>
specified as -lgcc&lt;suffixes&gt; which libtool does pick up on. So the pa=
tch <br>
to m4/libtool.m4 only needs special casing of libclang_rt.builtins; libgcc =
<br>
is handled just fine by the existing pattern of -l*.<br>
<br>
But later if either libclang_rt.builtins, or libgcc, is linked statically <=
br>
(the only option for libclang_rt.builtins), they need to be marked as <br>
allowed in build-aux/<a href=3D"http://ltmain.in" rel=3D"noreferrer norefer=
rer" target=3D"_blank">ltmain.in</a>, in <br>
<a href=3D"https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013=
-Allow-statically-linking-compiler-support-libraries-.patch" rel=3D"norefer=
rer noreferrer" target=3D"_blank">https://github.com/msys2/MSYS2-packages/b=
lob/master/libtool/0013-Allow-statically-linking-compiler-support-libraries=
-.patch</a>.<br>
<br>
&gt; I&#39;m glad I looked into it because when I investigated the original=
 <br>
&gt; patches&#39; commit logs I realized that these were really just aimed =
at <br>
&gt; getting the builds for a small number of MSYS2 packages to succeed ( i=
n <br>
&gt; the author&#39;s case VLC was the one they were focused on );<br>
<br>
I think that author you refer to is me.<br>
<br>
&gt; and that really this wasn&#39;t really designed to be a general purpos=
e <br>
&gt; patch to `libtool&#39;.<br>
<br>
It was meant to be a as general purpose patch as possible, to fix the <br>
issues I had observed - without having the entirely full picture as I&#39;m=
 <br>
not the libtool maintainer of course. But they were indeed meant to be <br>
upstreamable.<br>
<br>
&gt; From what I can tell MSYS2 is only using `libtool&#39; for like 15 pac=
kages, <br>
&gt; so for their use case hard coding a few whitelisted libraries is total=
ly <br>
&gt; fine.<br>
<br>
That sounds like an incorrect conclusion.<br>
<br>
The MSYS2 packaged and patched libtool is used when building the packages <=
br>
in <a href=3D"https://github.com/msys2/MINGW-packages/" rel=3D"noreferrer n=
oreferrer" target=3D"_blank">https://github.com/msys2/MINGW-packages/</a>. =
Currently this is a bit over <br>
2000 packages. Out of those, 320 have &#39;autoreconf&#39; as part of their=
 build <br>
instructions, 63 contain &#39;autogen.sh&#39;, 13 contain &#39;libtoolize&#=
39;.<br>
<br>
So roughly at least around 400 packages are routinely built with the MSYS2 =
<br>
patched libtool installed in the packages - possibly some more that update =
<br>
their bundled libtool via some other command.<br>
<br>
&gt; but `libtool&#39; needs to either parse flag-specs and perfectly repro=
duce <br>
&gt; the underlying CC&#39;s implicit libs, or it needs to stop directly in=
voking <br>
&gt; `ld&#39;.<br>
<br>
Indeed, I never quite understood why libtool needs to build C++ libraries <=
br>
with -nostdlib and try to replicate the compiler&#39;s default libraries in=
 <br>
the first place.<br>
<br>
&gt; The big issue I see with the MSYS patches, and similar ad-hoc patches =
<br>
&gt; that have been submitted to work around issues in flag-specs <br>
&gt; `-fsanitize=3D&#39; for example ) is that they often explicitly add li=
nkage <br>
&gt; for the relevant libraries, and fail to add linkage for the `.o&#39; f=
iles.<br>
<br>
I&#39;m not familiar with the patches for &#39;-fsanitize=3D&#39; - but in =
the case of <br>
the patch I&#39;m primarily talking about, it&#39;s all about the single st=
atic <br>
library libclang_rt.builtins-&lt;arch&gt;.a, which doesn&#39;t have any ass=
ociated <br>
object files. I&#39;m not referring to the sanitizers (which do have a much=
 <br>
more tricky setup), but just the compiler helper builtins library, which <b=
r>
doesn&#39;t have any of the tricky-init-object-files issues.<br>
<br>
// Martin<br>
<br>
</blockquote></div>

--000000000000e1af9105df21b10a--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Alex Ameen <alex.ameen.tx@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Mon, 16 May 2022 14:19:02 +0000
Resent-Message-ID: <handler.27866.B27866.16527107045375 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Cc: praiskup@HIDDEN, 27866 <at> debbugs.gnu.org, shea@HIDDEN, bfriesen@HIDDEN, manojgupta@HIDDEN
X-Debbugs-Original-Cc: Pavel Raiskup <praiskup@HIDDEN>, bug-libtool@HIDDEN, Shea Levy <shea@HIDDEN>, 27866 <at> debbugs.gnu.org, Bob Friesenhahn <bfriesen@HIDDEN>, Manoj Gupta <manojgupta@HIDDEN>
Received: via spool by 27866-submit <at> debbugs.gnu.org id=B27866.16527107045375
          (code B ref 27866); Mon, 16 May 2022 14:19:02 +0000
Received: (at 27866) by debbugs.gnu.org; 16 May 2022 14:18:24 +0000
Received: from localhost ([127.0.0.1]:54685 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nqbYF-0001Oc-63
	for submit <at> debbugs.gnu.org; Mon, 16 May 2022 10:18:24 -0400
Received: from mail-vs1-f43.google.com ([209.85.217.43]:43003)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <alex.ameen.tx@HIDDEN>) id 1nqbYC-0001OM-AW
 for 27866 <at> debbugs.gnu.org; Mon, 16 May 2022 10:18:21 -0400
Received: by mail-vs1-f43.google.com with SMTP id i186so15653786vsc.9
 for <27866 <at> debbugs.gnu.org>; Mon, 16 May 2022 07:18:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=Uk2CvJKgmk/0fhiK+0UcdBPMKcVp0O1Rb7hShQ8h9/k=;
 b=ZOhmBxV4VgghuSepZrJMFPzSj9jLwi6ahU/IWGMuyNzH5FkOWtbLmAVw2gnvmGRW8L
 VLVZQ3IlwFcIbBlpbnq9Grc14fbxn1tqIb5f7HIZMeZGhaAqO0uEebYEWbkDNuf3AKHW
 H5PEG2zVFICiv5VFZz+2TqJc0+RRRUKNGLgz+XD9G7sZyoNB8ENb848jOKZAm/vUQ5CT
 hIA/HnxX3wAJOw3p1ASva/CwCC6d7hPKLOcV65TMrH6sMIMVyTFP2uFAzYXbtOJ3aEQz
 MfzMWdk48eGFcszbRR5KGg7Gx0jRncCRtndexVjwVq8N9zur+DJcAsyJpDTUslsXDAvY
 OqYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=Uk2CvJKgmk/0fhiK+0UcdBPMKcVp0O1Rb7hShQ8h9/k=;
 b=UFhIGqgRNSeTHBsjZflo2hy2TJUyTNNc4MJKbcoiqXIa8YrLLWeQHQgqY0/AQ9jpbP
 kLMd7+7f/EiA3wXDrkjxzKJSWw4pSlkNCYFyn0FNMfitQxY4nLXwNFn/iOMeEG4ErZTE
 CZSXe/gBY0uX3zF8ikut2H8h2+FUCuTiDFjyvPWs/YGlSTY2xlSXSzMFJtq1tsTMjvLB
 KtYJFAdNqRg2E1QJLhkywAef5+AgfAoOsmp6YFlY13G8hDYQ/PgSJXEMeOkbVvXvU0+/
 9Jw+nizn3wWBlJXhXwWs3EUTLsRS3h7eg2Oo0Q3561h3yVBihL2v9DhkqNbAOe2Gocae
 buBg==
X-Gm-Message-State: AOAM532wkc+fCMTOEWOzuTLh/waQ+0sA2QtDRKWcqFhaDdUN4k7LSTVo
 NuqHYBx6fsl/HTN2+Uwf+lNNAQ/ToP0UThCBSFY=
X-Google-Smtp-Source: ABdhPJx/fowlZ4LymIPdLpew6L7PjKY998DOv+khx/3QLNNXtQThWiVgaZDuuWQA5X75ShbHqj7jTBgwZO5mNLle0PE=
X-Received: by 2002:a67:e047:0:b0:32d:54c5:28a5 with SMTP id
 n7-20020a67e047000000b0032d54c528a5mr6148625vsl.20.1652710694824; Mon, 16 May
 2022 07:18:14 -0700 (PDT)
MIME-Version: 1.0
References: <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@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>
 <40fe93ff-2fb2-b3d6-8f9c-3ae7f77f7a62@HIDDEN>
 <8735hnj81r.fsf@HIDDEN>
 <9f84eb26-d083-01ef-cc07-cc8bb586c1c1@HIDDEN>
 <63a4df41-93c8-c54-307c-2bff6edb3589@HIDDEN>
 <43f80a1b-e0f1-cd2a-9f12-f839b7c79125@HIDDEN>
 <756f3af-b39b-8033-63e3-d742256aa31@HIDDEN>
In-Reply-To: <756f3af-b39b-8033-63e3-d742256aa31@HIDDEN>
From: Alex Ameen <alex.ameen.tx@HIDDEN>
Date: Mon, 16 May 2022 09:18:03 -0500
Message-ID: <CAKgHvyv0cQh_ugfK-k5JWY2yi2BfuNeUCoFoQGbL4YaAV-H9Yw@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000e1af9105df21b10a"
X-Spam-Score: -0.0 (/)
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 (-)

--000000000000e1af9105df21b10a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey I reread my message, and will make my way through your responses today,
but something I forgot to mention was : really thank you for submitting
these. I hope my response didn't come across as critical. I really do
appreciate the work you've done here, and the effort you've made towards
clarifying.

On Mon, May 16, 2022, 2:26 AM Martin Storsj=C3=B6 <martin@HIDDEN> wrote:

> On Sun, 15 May 2022, Alex Ameen wrote:
>
> > Could you share the workspace you tested in, or a snippet? I need to
> make a
> > test case.
>
> This can reproduced with most libtool based projects that include C++
> code. One example that I used for small standalone testing is this:
> http://github.com/mstorsjo/fdk-aac
>
> This project normally links the library as if it was C code, not C++, to
> avoid unnecessary dependencies on the C++ standard library (which also
> implicitly avoids this issue). To expose this issue, uncomment this line
> in Makefile.am:
>
>      libfdk_aac_la_LINK =3D $(LINK) $(libfdk_aac_la_LDFLAGS)
>
> Then regenerate the build files with ./autogen.sh.
>
> Then build the project with a toolchain from
> https://github.com/mstorsjo/llvm-mingw/releases - there are prebuilt ones
> for x86_64 and aarch64 linux and macos (and windows). Assuming you run on
> linux, configure the project like this:
>
>     ../fdk-aac/configure --host=3Dx86_64-w64-mingw32
>
> When building, you'll end up with this build error:
>
>    CXXLD    libfdk-aac.la
> ld.lld: error: undefined symbol: ___chkstk_ms
> >>> referenced by ../fdk-aac/libAACdec/src/FDK_delay.cpp:130
> >>>
> libAACdec/src/.libs/FDK_delay.o:(FDK_Delay_Apply(FDK_SignalDelay*, long*,
> unsigned int, unsigned char))
> >>> referenced by ../fdk-aac/libAACdec/src/aacdec_hcr.cpp:435
> >>>
> libAACdec/src/.libs/aacdec_hcr.o:(HcrDecoder(CErHcrInfo*,
> CAacDecoderChannelInfo*, SamplingRateInfo const*, FDK_BITSTREAM*))
> >>> referenced by ../fdk-aac/libAACdec/src/aacdecoder.cpp:2520
> >>>
> libAACdec/src/.libs/aacdecoder.o:(CAacDecoder_DecodeFrame(AAC_DECODER_INS=
TANCE*,
>
> unsigned int, long*, int, int))
> >>> referenced 14 more times
>
> Are you able to reproduce this setup, or do you want me to package up a
> full build environment with the pre-setup code in this configuration?
>
>
> > There was one aspect I wanted some clarity on though from the patches
> MSYS
> > developed, which was "why is it that `m4/libtool.m4' used `*NAME*.a' wh=
en
> > `build-aux/ltmain.in' used `*/libNAME*.$libext',
>
> Which patch is that? In both
>
> https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011-Pick-up-=
clang_rt-static-archives-compiler-internal-l.patch
> and
>
> https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013-Allow-st=
atically-linking-compiler-support-libraries-.patch
> it's spelled out as libclang_rt and libgcc, not *clang_rt.
>
> > and why they allowed `libgcc*' in `ltmain.in' but not `m4/libtool.m4'.
>
> The reason for that is that when clang refers to the clang_rt builtins
> library, it does so by passing an absolute path to
> libclang_rt.builtins-<arch>.a is specified in the link command (which
> libtool tries to analyze and pick up, by running $CC -v).
>
>
> https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011-Pick-up-=
clang_rt-static-archives-compiler-internal-l.patch
> makes sure that this library is picked up here. For the case of libgcc,
> it's never specified as an absolute path to the library, but always
> specified as -lgcc<suffixes> which libtool does pick up on. So the patch
> to m4/libtool.m4 only needs special casing of libclang_rt.builtins; libgc=
c
> is handled just fine by the existing pattern of -l*.
>
> But later if either libclang_rt.builtins, or libgcc, is linked statically
> (the only option for libclang_rt.builtins), they need to be marked as
> allowed in build-aux/ltmain.in, in
>
> https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013-Allow-st=
atically-linking-compiler-support-libraries-.patch
> .
>
> > I'm glad I looked into it because when I investigated the original
> > patches' commit logs I realized that these were really just aimed at
> > getting the builds for a small number of MSYS2 packages to succeed ( in
> > the author's case VLC was the one they were focused on );
>
> I think that author you refer to is me.
>
> > and that really this wasn't really designed to be a general purpose
> > patch to `libtool'.
>
> It was meant to be a as general purpose patch as possible, to fix the
> issues I had observed - without having the entirely full picture as I'm
> not the libtool maintainer of course. But they were indeed meant to be
> upstreamable.
>
> > From what I can tell MSYS2 is only using `libtool' for like 15 packages=
,
> > so for their use case hard coding a few whitelisted libraries is totall=
y
> > fine.
>
> That sounds like an incorrect conclusion.
>
> The MSYS2 packaged and patched libtool is used when building the packages
> in https://github.com/msys2/MINGW-packages/. Currently this is a bit over
> 2000 packages. Out of those, 320 have 'autoreconf' as part of their build
> instructions, 63 contain 'autogen.sh', 13 contain 'libtoolize'.
>
> So roughly at least around 400 packages are routinely built with the MSYS=
2
> patched libtool installed in the packages - possibly some more that updat=
e
> their bundled libtool via some other command.
>
> > but `libtool' needs to either parse flag-specs and perfectly reproduce
> > the underlying CC's implicit libs, or it needs to stop directly invokin=
g
> > `ld'.
>
> Indeed, I never quite understood why libtool needs to build C++ libraries
> with -nostdlib and try to replicate the compiler's default libraries in
> the first place.
>
> > The big issue I see with the MSYS patches, and similar ad-hoc patches
> > that have been submitted to work around issues in flag-specs
> > `-fsanitize=3D' for example ) is that they often explicitly add linkage
> > for the relevant libraries, and fail to add linkage for the `.o' files.
>
> I'm not familiar with the patches for '-fsanitize=3D' - but in the case o=
f
> the patch I'm primarily talking about, it's all about the single static
> library libclang_rt.builtins-<arch>.a, which doesn't have any associated
> object files. I'm not referring to the sanitizers (which do have a much
> more tricky setup), but just the compiler helper builtins library, which
> doesn't have any of the tricky-init-object-files issues.
>
> // Martin
>
>

--000000000000e1af9105df21b10a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hey I reread my message, and will make my way through you=
r responses today, but something I forgot to=C2=A0mention was : really than=
k you for submitting these. I hope my response didn&#39;t come across as cr=
itical. I really do appreciate the work you&#39;ve done here, and the effor=
t you&#39;ve made towards clarifying.</div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 16, 2022, 2:26 AM Martin S=
torsj=C3=B6 &lt;<a href=3D"mailto:martin@HIDDEN">martin@HIDDEN</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, 15 May 2022, Alex =
Ameen wrote:<br>
<br>
&gt; Could you share the workspace you tested in, or a snippet? I need to m=
ake a<br>
&gt; test case.<br>
<br>
This can reproduced with most libtool based projects that include C++ <br>
code. One example that I used for small standalone testing is this: <br>
<a href=3D"http://github.com/mstorsjo/fdk-aac" rel=3D"noreferrer noreferrer=
" target=3D"_blank">http://github.com/mstorsjo/fdk-aac</a><br>
<br>
This project normally links the library as if it was C code, not C++, to <b=
r>
avoid unnecessary dependencies on the C++ standard library (which also <br>
implicitly avoids this issue). To expose this issue, uncomment this line <b=
r>
in Makefile.am:<br>
<br>
=C2=A0 =C2=A0 =C2=A0libfdk_aac_la_LINK =3D $(LINK) $(libfdk_aac_la_LDFLAGS)=
<br>
<br>
Then regenerate the build files with ./autogen.sh.<br>
<br>
Then build the project with a toolchain from <br>
<a href=3D"https://github.com/mstorsjo/llvm-mingw/releases" rel=3D"noreferr=
er noreferrer" target=3D"_blank">https://github.com/mstorsjo/llvm-mingw/rel=
eases</a> - there are prebuilt ones <br>
for x86_64 and aarch64 linux and macos (and windows). Assuming you run on <=
br>
linux, configure the project like this:<br>
<br>
=C2=A0 =C2=A0 ../fdk-aac/configure --host=3Dx86_64-w64-mingw32<br>
<br>
When building, you&#39;ll end up with this build error:<br>
<br>
=C2=A0 =C2=A0CXXLD=C2=A0 =C2=A0 <a href=3D"http://libfdk-aac.la" rel=3D"nor=
eferrer noreferrer" target=3D"_blank">libfdk-aac.la</a><br>
ld.lld: error: undefined symbol: ___chkstk_ms<br>
&gt;&gt;&gt; referenced by ../fdk-aac/libAACdec/src/FDK_delay.cpp:130<br>
&gt;&gt;&gt; <br>
libAACdec/src/.libs/FDK_delay.o:(FDK_Delay_Apply(FDK_SignalDelay*, long*, <=
br>
unsigned int, unsigned char))<br>
&gt;&gt;&gt; referenced by ../fdk-aac/libAACdec/src/aacdec_hcr.cpp:435<br>
&gt;&gt;&gt; <br>
libAACdec/src/.libs/aacdec_hcr.o:(HcrDecoder(CErHcrInfo*, <br>
CAacDecoderChannelInfo*, SamplingRateInfo const*, FDK_BITSTREAM*))<br>
&gt;&gt;&gt; referenced by ../fdk-aac/libAACdec/src/aacdecoder.cpp:2520<br>
&gt;&gt;&gt; <br>
libAACdec/src/.libs/aacdecoder.o:(CAacDecoder_DecodeFrame(AAC_DECODER_INSTA=
NCE*, <br>
unsigned int, long*, int, int))<br>
&gt;&gt;&gt; referenced 14 more times<br>
<br>
Are you able to reproduce this setup, or do you want me to package up a <br=
>
full build environment with the pre-setup code in this configuration?<br>
<br>
<br>
&gt; There was one aspect I wanted some clarity on though from the patches =
MSYS<br>
&gt; developed, which was &quot;why is it that `m4/libtool.m4&#39; used `*N=
AME*.a&#39; when<br>
&gt; `build-aux/<a href=3D"http://ltmain.in" rel=3D"noreferrer noreferrer" =
target=3D"_blank">ltmain.in</a>&#39; used `*/libNAME*.$libext&#39;,<br>
<br>
Which patch is that? In both <br>
<a href=3D"https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011=
-Pick-up-clang_rt-static-archives-compiler-internal-l.patch" rel=3D"norefer=
rer noreferrer" target=3D"_blank">https://github.com/msys2/MSYS2-packages/b=
lob/master/libtool/0011-Pick-up-clang_rt-static-archives-compiler-internal-=
l.patch</a> <br>
and <br>
<a href=3D"https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013=
-Allow-statically-linking-compiler-support-libraries-.patch" rel=3D"norefer=
rer noreferrer" target=3D"_blank">https://github.com/msys2/MSYS2-packages/b=
lob/master/libtool/0013-Allow-statically-linking-compiler-support-libraries=
-.patch</a> <br>
it&#39;s spelled out as libclang_rt and libgcc, not *clang_rt.<br>
<br>
&gt; and why they allowed `libgcc*&#39; in `<a href=3D"http://ltmain.in" re=
l=3D"noreferrer noreferrer" target=3D"_blank">ltmain.in</a>&#39; but not `m=
4/libtool.m4&#39;.<br>
<br>
The reason for that is that when clang refers to the clang_rt builtins <br>
library, it does so by passing an absolute path to <br>
libclang_rt.builtins-&lt;arch&gt;.a is specified in the link command (which=
 <br>
libtool tries to analyze and pick up, by running $CC -v).<br>
<br>
<a href=3D"https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011=
-Pick-up-clang_rt-static-archives-compiler-internal-l.patch" rel=3D"norefer=
rer noreferrer" target=3D"_blank">https://github.com/msys2/MSYS2-packages/b=
lob/master/libtool/0011-Pick-up-clang_rt-static-archives-compiler-internal-=
l.patch</a> <br>
makes sure that this library is picked up here. For the case of libgcc, <br=
>
it&#39;s never specified as an absolute path to the library, but always <br=
>
specified as -lgcc&lt;suffixes&gt; which libtool does pick up on. So the pa=
tch <br>
to m4/libtool.m4 only needs special casing of libclang_rt.builtins; libgcc =
<br>
is handled just fine by the existing pattern of -l*.<br>
<br>
But later if either libclang_rt.builtins, or libgcc, is linked statically <=
br>
(the only option for libclang_rt.builtins), they need to be marked as <br>
allowed in build-aux/<a href=3D"http://ltmain.in" rel=3D"noreferrer norefer=
rer" target=3D"_blank">ltmain.in</a>, in <br>
<a href=3D"https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013=
-Allow-statically-linking-compiler-support-libraries-.patch" rel=3D"norefer=
rer noreferrer" target=3D"_blank">https://github.com/msys2/MSYS2-packages/b=
lob/master/libtool/0013-Allow-statically-linking-compiler-support-libraries=
-.patch</a>.<br>
<br>
&gt; I&#39;m glad I looked into it because when I investigated the original=
 <br>
&gt; patches&#39; commit logs I realized that these were really just aimed =
at <br>
&gt; getting the builds for a small number of MSYS2 packages to succeed ( i=
n <br>
&gt; the author&#39;s case VLC was the one they were focused on );<br>
<br>
I think that author you refer to is me.<br>
<br>
&gt; and that really this wasn&#39;t really designed to be a general purpos=
e <br>
&gt; patch to `libtool&#39;.<br>
<br>
It was meant to be a as general purpose patch as possible, to fix the <br>
issues I had observed - without having the entirely full picture as I&#39;m=
 <br>
not the libtool maintainer of course. But they were indeed meant to be <br>
upstreamable.<br>
<br>
&gt; From what I can tell MSYS2 is only using `libtool&#39; for like 15 pac=
kages, <br>
&gt; so for their use case hard coding a few whitelisted libraries is total=
ly <br>
&gt; fine.<br>
<br>
That sounds like an incorrect conclusion.<br>
<br>
The MSYS2 packaged and patched libtool is used when building the packages <=
br>
in <a href=3D"https://github.com/msys2/MINGW-packages/" rel=3D"noreferrer n=
oreferrer" target=3D"_blank">https://github.com/msys2/MINGW-packages/</a>. =
Currently this is a bit over <br>
2000 packages. Out of those, 320 have &#39;autoreconf&#39; as part of their=
 build <br>
instructions, 63 contain &#39;autogen.sh&#39;, 13 contain &#39;libtoolize&#=
39;.<br>
<br>
So roughly at least around 400 packages are routinely built with the MSYS2 =
<br>
patched libtool installed in the packages - possibly some more that update =
<br>
their bundled libtool via some other command.<br>
<br>
&gt; but `libtool&#39; needs to either parse flag-specs and perfectly repro=
duce <br>
&gt; the underlying CC&#39;s implicit libs, or it needs to stop directly in=
voking <br>
&gt; `ld&#39;.<br>
<br>
Indeed, I never quite understood why libtool needs to build C++ libraries <=
br>
with -nostdlib and try to replicate the compiler&#39;s default libraries in=
 <br>
the first place.<br>
<br>
&gt; The big issue I see with the MSYS patches, and similar ad-hoc patches =
<br>
&gt; that have been submitted to work around issues in flag-specs <br>
&gt; `-fsanitize=3D&#39; for example ) is that they often explicitly add li=
nkage <br>
&gt; for the relevant libraries, and fail to add linkage for the `.o&#39; f=
iles.<br>
<br>
I&#39;m not familiar with the patches for &#39;-fsanitize=3D&#39; - but in =
the case of <br>
the patch I&#39;m primarily talking about, it&#39;s all about the single st=
atic <br>
library libclang_rt.builtins-&lt;arch&gt;.a, which doesn&#39;t have any ass=
ociated <br>
object files. I&#39;m not referring to the sanitizers (which do have a much=
 <br>
more tricky setup), but just the compiler helper builtins library, which <b=
r>
doesn&#39;t have any of the tricky-init-object-files issues.<br>
<br>
// Martin<br>
<br>
</blockquote></div>

--000000000000e1af9105df21b10a--

MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Ileana Dumitrescu <ileanadumitrescu95@HIDDEN>
Subject: bug#27866: closed (Handle clang's internal libraries when finding
 compiler's internal libraries)
CC: tracker <at> debbugs.gnu.org
Message-ID: <handler.27866.D27866.174473153224017.ackdone <at> debbugs.gnu.org>
References: <987fa64c-b039-4a74-a479-0894171faed6@HIDDEN>
 <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
X-Gnu-PR-Message: closed 27866
X-Gnu-PR-Package: libtool
Date: Tue, 15 Apr 2025 15:39:02 +0000
Content-Type: multipart/mixed; boundary="----------=_1744731542-24104-0"

This is a multi-part message in MIME format...

------------=_1744731542-24104-0
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8

Your message dated Tue, 15 Apr 2025 18:38:36 +0300
with message-id <987fa64c-b039-4a74-a479-0894171faed6@HIDDEN>
and subject line bug#27866: Handle clang's internal libraries when finding =
compiler's internal libraries
has caused the debbugs.gnu.org bug report #27866,
regarding Handle clang's internal libraries when finding compiler's interna=
l libraries
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@HIDDEN)


--=20
27866: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D27866
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

------------=_1744731542-24104-0
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at submit) by debbugs.gnu.org; 28 Jul 2017 21:04:26 +0000
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 &quot;-lname&quot; 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 &quot;$output_verbose_link_cmd&quot;`; 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}&quot; 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 &quot;=
$p&quot; ||</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&quot;/usr/bin/x86_64-pc=
-linux-gnu-ld&quot; --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--



------------=_1744731542-24104-0
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at 27866-done) by debbugs.gnu.org; 15 Apr 2025 15:38:52 +0000
Received: from localhost ([127.0.0.1]:53806 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1u4iNA-0006FI-1i
	for submit <at> debbugs.gnu.org; Tue, 15 Apr 2025 11:38:52 -0400
Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:41809)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <ileanadumitrescu95@HIDDEN>)
 id 1u4iN6-0006Dc-7J
 for 27866-done <at> debbugs.gnu.org; Tue, 15 Apr 2025 11:38:49 -0400
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43f106a3591so5261815e9.3
 for <27866-done <at> debbugs.gnu.org>; Tue, 15 Apr 2025 08:38:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1744731521; x=1745336321; darn=debbugs.gnu.org;
 h=autocrypt:subject:from:cc:to:content-language:user-agent
 :mime-version:date:message-id:from:to:cc:subject:date:message-id
 :reply-to; bh=SJoZD8h+KQ6UdHaoNnK20Vd/DI+WaZGFZN2kGn+vqx8=;
 b=b0Si+MIZ/8+lPBmL4pVecDaa7ZBCvCTDR7TTw3v6ruQv7imOvEwbrVuzwqQgtvNm0k
 gJad42c/oPE7tcDhm6eEno7KcMRdrBwhRHaGC+lNzs6LJYtXISi2km/qcNOx/aiEeNQU
 P8iyhXOrGBYPWvLH0QzVwD0O6IMJBNLK6JA/bqJjokm+v8ctrdNgaLHh0yVE92cf4RKr
 71ccJIK4oWNvZzv/eEGQ9LGUbtjiJp7CvZUFJtDI7NNT0R4Mz1fD5nzVwmeo0XD2yMVq
 IksDQGqZGmD0Xk6t6o9GN4JDYQOt8urVO+gn/pEN6DlbWnoFH3xI9T8dsPf3MLF4ykq9
 NUQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1744731521; x=1745336321;
 h=autocrypt:subject:from:cc:to:content-language:user-agent
 :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject
 :date:message-id:reply-to;
 bh=SJoZD8h+KQ6UdHaoNnK20Vd/DI+WaZGFZN2kGn+vqx8=;
 b=P0DOCuYwO7y6FmNkR/E9fnWbpSbE9CdimYngkkJVue6bZWzjvwq3aRvsQagV/KztUS
 hhFhMoWVk5cV4r8bQrsWhGrwEe3et669q4ulgVpXxINnoo/aYoET/cBIKHbMjmWRAKUa
 wrb7Q9MGgLL6FTvE86q8XV79pHl2XIlLlCP2y3+g1h39KB/zSBFQzQsPOFkn2WYB7skE
 zOSai1lCpTRR9DeZZafz0AledJINwQce5VY6wZMdXR0JBk/HfhQ5dup10iYdHpNz2vsx
 xCieQ+8C2g/gtkOXclSTsq5vfjvsEMkuwfXpdGRp4J2B4U/JJwMZUqYwcY0H8JwqpVwq
 Tmyg==
X-Gm-Message-State: AOJu0YyYYWg7orBXNPW5tEoMjOpMMeBLWtvoAZkE5bN3cNpluE6Ga7Fi
 +/BHXoRHeM463aCujyrUJcDo0alrlKvS5/8vE/A6Y4DHCK+oyeuItPK22Q==
X-Gm-Gg: ASbGncuIDumg5tWTii4YeIV6mBWmzo6G1epQMjQMGD0j+xkVlaeK4YNLZuB18JGUDX1
 LdnXi06nuxWrdfQBzD6MMcAXo/Jxa5uP2BqPis9UMryYq+p5zvHkOYiIfymsv9GiucgBmUwkw4u
 DAL2htSmVQLZKgqHRiZ891N6Yw2ndcZ+B/jc9YkdIEfFx4bfo1dUrwcCix915LUnsHGviEHh4Db
 JWs1B6jkIraf93axFN3H0T3SQirTLlNkFqyYAUIYQIR5gIFHlzypXKglOUMeca1EXW01tochs80
 NG5GeMvMPqrNK2dh0gk/AhQJgDfIU5jl62BLz8CD5jEUcrT22CIMYqdygsPO
X-Google-Smtp-Source: AGHT+IH/J0JbUSqp1vdoIgi3e+uGbfHVmwzUcPtFCQSOx4+vg7gnvVviX15IlFOHaWLqXEgf2h13/Q==
X-Received: by 2002:a05:600c:1d29:b0:43d:fa5e:50e6 with SMTP id
 5b1f17b1804b1-43f3a9c04efmr50517515e9.9.1744731520911; 
 Tue, 15 Apr 2025 08:38:40 -0700 (PDT)
Received: from [192.168.254.128] ([95.214.217.107])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43f233c824bsm211474765e9.24.2025.04.15.08.38.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 15 Apr 2025 08:38:40 -0700 (PDT)
Message-ID: <987fa64c-b039-4a74-a479-0894171faed6@HIDDEN>
Date: Tue, 15 Apr 2025 18:38:36 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: 27866-done <at> debbugs.gnu.org
From: Ileana Dumitrescu <ileanadumitrescu95@HIDDEN>
Subject: bug#27866: Handle clang's internal libraries when finding compiler's
 internal libraries
Autocrypt: addr=ileanadumitrescu95@HIDDEN; keydata=
 xsFNBGFMu5ABEACpFrPCKpfsTSl4svqi91Hsf8gGtdKwndgXqMPJNqBXEJCCwiiUPnS68wNW
 ae54So04zVAcXewFdM36GypUGep5bhdgvbVKaDCrhNRdAoZ0VAywgU9CDCAa3v8eXUSrlGon
 k/ygjLIMnkOSjIMls4+z0FOpvsd1IcgcBDU5S6DSAF/Sb8w9bF2yD7f5RaLN6++EJEO2Bp+8
 v4qCJEUGzi5QJKXHVUTGiTirx50eLIkw0HseLVOiJoU0NRRgzK/q04+X/NuOAPnZm5K3GOJU
 mKmG7M2tdMhhGT7UjF3XiI0MwydGIrPU1T1OdPBnXv6ajRYzLgIZl0GsGeFo5qFaFmRtNO7n
 CGi/5XtivM1WvbqXIQmsAmpm8N/uEcPcuP+0+7s1o0JC+c4nbHlQyvUFSZVgbZQ+mSn6GXRP
 NfL7AeDSINXXvXDv5vkHN+FbFggx5nWg8J5a33hxbnZoR/qTfDBQHF3mJMF3lesXibN+oLvw
 OVtlIffKc4jwjLKL40644eQfbhHjCE1AXGQjUGCE5vAkCxEqWH2nQbXIedijQD/5mufaCQX3
 Rl314FBfyV1b9rIHxJYRLXHT83+om7y5ncYI5sdoY7/g/Ggmi0PuuUicax/ejOx4nNtDgDxl
 hCgOVm6qpmX9kyEZj0+vAodQjMrx3JKgojBdbusl4C5bWIgeRwARAQABzTBJbGVhbmEgRHVt
 aXRyZXNjdSA8aWxlYW5hZHVtaXRyZXNjdTk1QGdtYWlsLmNvbT7CwZQEEwEKAD4CGwMFCwkI
 BwIGFQoJCAsCBBYCAwECHgECF4AWIQT6Jsp4S+GIkn8iuZ9lcOoBFG9zVAUCZAiLZwUJCF9q
 VwAKCRBlcOoBFG9zVGShEACQkxNBRGws9AszRtKbnCcK5/B7TbB8/AsRF+Qbr6D66We5Nlkj
 Lp2ZuHpNB0u3zzlXUPqE851txphNZTAM4L0EgmVmFwZ1402HMlbTe+dIjoeQnituxQE2UT4P
 WwnhqREPX7M/W2Q67Xvq5b3rpCWma3wtnFCLu9CjGMcoRD+kmVDK/Kld63E55qp1RbPsGCLD
 3p1Qn7eW3x+sgK9iH+0Oftu/r61O++d1zDzbnOgmvlEk7yWg2+QIDQpqzONJ3a3ye//Sahfa
 zo4XwIDimDC4L/LZk40HLgOHMvN9mtRCMJcJmqQ7XWe99qtaBMGxKBq5n8ZkCPVA86uEyAbJ
 LUdniS0zwDbpcE0nOSHMYKsW3R+D9bJkEDxNlKfgIqiCgrXXjdu9fREGxUm3jbJlD6nqKE/y
 bWtJ0BES2DCmMipprm5+cSWWiQ4rgaJBfY2YxwNMF1I9QXXKAo0xWvvjFB/jbpX7nicYx+rt
 RV4mvxu6EyaZSCfAKjMoPqdLT+1kP4UGzV7CxH//QiPziWgyQyUr5o+vhW5HAbnxGLDnuL+6
 Wmb5cGXDr73R7Rs7PfBALaScP6+5MrJ9hNTt6uwwJ70VdfU9o3UEInGOfdnBbWc5yNFktuO8
 yUKjgLjDR1RXqils+ALUa2I5ifjsf2dlQhmCsAq9PktN9N++vk+TdzBcNM7BTQRhTLuQARAA
 xH2RgDZFA5q9G2wfKzsig/Dz/Kx9H9MGLayJEs5MNIJv17dG+mMmgjRk4O0QwhGzmgD8nBe1
 AJXqE6hm6K2MpXajb/B9/vIFNgNQ9KIaTtIehkG2rwXwPDLfvgPYLRw+fH0gAVbS1mDDRro7
 RJr8pl7m8mi63UEZQxkqF3IZ1pD7uyfCcPl0V3b5dWwo5Uky7hJPEFvj8zJaBS6YdnZ8WteI
 xIR8eHMPwi2WQLJwn8LUqG2ODMIMkpQo71f2dCopCSq1UU2BY/JMagbpUXek3FIjNIKp9KUj
 3FFkUFvlqKif+kB9M6P+llBVY0nDCidK617V6NJwaJUZzRgGimiuW2Qx9QwWHYcBbiaK6EHa
 ew5gkVwPlMJJJhwwFAlPfYT0ThsVl/kpaOjptyDbRWxyGLac+nLXvVai6ElJM7797ZWbwdZh
 a7TYUA6Y0JPr1ciVcFpipslXkOKzq0GjPPSuQ9+Q57LGWoJX0Z1rravAS7uzFhNbNMgQebnJ
 5efvMRO8DCDUWiIn22VBR3seL3lBS8sf0Pj+lRCBHJ8usJf/MkfWZiAuQyQ1/EnDao/3wPD0
 prOBgx096bFMWnuA+YfBYcnb6SASpYwYGTqZU/vp6M1ORWnvxdXvEYEfeq+RabaqvZ4MN0eD
 75X7K+nbhWhlWuOjVd59E57UN018gdC2DWMAEQEAAcLBfAQYAQoAJgIbDBYhBPomynhL4YiS
 fyK5n2Vw6gEUb3NUBQJkCIuUBQkIX2qEAAoJEGVw6gEUb3NU6qMP/R80Q4G/CVLsrXMEWhie
 PIHmPYfLL1guvLNi/K3YocMFSloU6QjyP2Lsceh5Sz5NB/+xr6p6nGpmc5FEGxr20SoXyEfJ
 CNWXNR+4znkSzkRH1FJ+QOYdlZCFaGGaQzTkji47heoW9m9to/dGv8fKa34VLo7wzvD3FyYd
 F27lSGNqSiIPNFS8kGS5m0fVDHP2jgFjiWjcXRUG78KzH4Yansse5KTPj2dm8zb+o30jfd8d
 M1ccd3FavQ74kjrbTubQWsStTNMBm9ML7vSoirs5P3d8NNLHSMDtlZfzNfWKkxthZY1N86sM
 OoecaOl8rfBIKrXMkWJXRDoz6o8Xrd/+JeByDBGuM5jAMT0mQ5ckBwFN5Q7ket0c/YomKZQ3
 ul3V44eS8hmizeWNM2r4x3DVJa+4tsXeTLSWWX79z276SqSxQveKfnJh0ak8q0tqJAc6iflv
 UjIIW5c7aSfcul+u6/8S0T74nEHfBhpBjQm9BEumt1sSfXGYO77LXemuYDWpe2v0BO0j5hBs
 sYnJ/hUDXgy2+bMJXzohJqYEjSs9gdTDskD6x9Z1sTHutikUw/g4gxxRThH2l4YhBb6kuwct
 9xzecT2/PVzXkjnt+gwQ6PHdyTWj0//LZCKJVquluG3myyCMALInBkJ0dzwXKH0VHe8PYt18
 tEGGBkKUVsxBXBBe
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------cl5Z0IiqXxCk5qAIyow0bikW"
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 27866-done
Cc: =?UTF-8?Q?Martin_Storsj=C3=B6?= <martin@HIDDEN>,
 Manoj Gupta <manojgupta@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.7 (/)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------cl5Z0IiqXxCk5qAIyow0bikW
Content-Type: multipart/mixed; boundary="------------JOkbaTfqGHUSQFV4qoJMAw0T";
 protected-headers="v1"
From: Ileana Dumitrescu <ileanadumitrescu95@HIDDEN>
To: 27866-done <at> debbugs.gnu.org
Cc: Manoj Gupta <manojgupta@HIDDEN>, =?UTF-8?Q?Martin_Storsj=C3=B6?=
 <martin@HIDDEN>
Message-ID: <987fa64c-b039-4a74-a479-0894171faed6@HIDDEN>
Subject: bug#27866: Handle clang's internal libraries when finding compiler's
 internal libraries

--------------JOkbaTfqGHUSQFV4qoJMAw0T
Content-Type: multipart/mixed; boundary="------------8GYj2095KHgB9H0sMn4gUQO8"

--------------8GYj2095KHgB9H0sMn4gUQO8
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

VGhhbmsgeW91IGZvciB5b3VyIGJ1ZyBzdWJtaXNzaW9uLiBUaGlzIGlzc3VlIG1heSBiZSBm
aXhlZCBieQ0KdXRpbGl6aW5nIGEgbmV3IGNvbmZpZ3VyYXRpb24gb3B0aW9uLCAtLWVuYWJs
ZS1jeHgtc3RkbGliIFsxXSwgc2luY2UgaXQNCmhhcyBiZWVuIGNvbmZpcm1lZCB0byBmaXgg
YSBzaW1pbGFyIGJ1ZyByZXBvcnQgWzJdLiBJZiByZS1jb25maWd1cmluZw0KZG9lcyBub3Qg
Zml4IHRoZSBpc3N1ZSwgSSB3aWxsIHJlb3BlbiB0aGlzIGJ1Zy4NCg0KWzFdIA0KaHR0cHM6
Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9jZ2l0L2xpYnRvb2wuZ2l0L2NvbW1pdC8/aWQ9OWJj
NzUzNmJkODc1NWYzYjYzMTE4NjEzNDk2YTg5NjcxNTEyZjJkYg0KWzJdIGh0dHBzOi8vc2F2
YW5uYWguZ251Lm9yZy9zdXBwb3J0L2luZGV4LnBocD8xMTExOTMNCg0KLS0gDQpJbGVhbmEg
RHVtaXRyZXNjdQ0KDQpHUEcgUHVibGljIEtleTogRkEyNiBDQTc4IDRCRTEgODg5MiA3RjIy
IEI5OUYgNjU3MCBFQTAxIDE0NkYgNzM1NA0KDQo=
--------------8GYj2095KHgB9H0sMn4gUQO8
Content-Type: application/pgp-keys; name="OpenPGP_0x6570EA01146F7354.asc"
Content-Disposition: attachment; filename="OpenPGP_0x6570EA01146F7354.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBGFMu5ABEACpFrPCKpfsTSl4svqi91Hsf8gGtdKwndgXqMPJNqBXEJCCwiiU
PnS68wNWae54So04zVAcXewFdM36GypUGep5bhdgvbVKaDCrhNRdAoZ0VAywgU9C
DCAa3v8eXUSrlGonk/ygjLIMnkOSjIMls4+z0FOpvsd1IcgcBDU5S6DSAF/Sb8w9
bF2yD7f5RaLN6++EJEO2Bp+8v4qCJEUGzi5QJKXHVUTGiTirx50eLIkw0HseLVOi
JoU0NRRgzK/q04+X/NuOAPnZm5K3GOJUmKmG7M2tdMhhGT7UjF3XiI0MwydGIrPU
1T1OdPBnXv6ajRYzLgIZl0GsGeFo5qFaFmRtNO7nCGi/5XtivM1WvbqXIQmsAmpm
8N/uEcPcuP+0+7s1o0JC+c4nbHlQyvUFSZVgbZQ+mSn6GXRPNfL7AeDSINXXvXDv
5vkHN+FbFggx5nWg8J5a33hxbnZoR/qTfDBQHF3mJMF3lesXibN+oLvwOVtlIffK
c4jwjLKL40644eQfbhHjCE1AXGQjUGCE5vAkCxEqWH2nQbXIedijQD/5mufaCQX3
Rl314FBfyV1b9rIHxJYRLXHT83+om7y5ncYI5sdoY7/g/Ggmi0PuuUicax/ejOx4
nNtDgDxlhCgOVm6qpmX9kyEZj0+vAodQjMrx3JKgojBdbusl4C5bWIgeRwARAQAB
zS9JbGVhbmEgRHVtaXRyZXNjdSA8aWxlYW5hZHVtaTk1QHByb3Rvbm1haWwuY29t
PsLBlAQTAQoAPhYhBPomynhL4YiSfyK5n2Vw6gEUb3NUBQJhTLuQAhsDBQkDwmcA
BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEGVw6gEUb3NUCC4P/AiRUDzkEm8E
WdvGQ9CkUYPAOARr19w04+N+86XZU8owULTkys81Wv80Wz48Q6IA3RASjHuyNtOQ
a3TmoGsRYovIqKWQY6hIWBY7radPldSnbqXDp0mbwxSFVsCV2m2YqZKQpnKTR7b5
N6KgKKDXDLK0ES5CO1DAdvTg33WOonSNVpP+14R1bg9L685nOckK+TP1kQq91W+0
QUeEfS7BqdU/Znv39sVVMUkXQiWK441rQ1wcHvD32iiSoqnFQxtrdTwaglpv1/Y6
MDsnnwrLX3Bsq0vIL8CYVwVqy309/rtq3tpL1dw9lWaEA0sBNBMfOvBBJ1GOUpnE
f6k6dlhHSoDDndbODXBEAgXnbz6JKqPA+NAJfnccnvcb7G2KnWtvG/GbWQia7S1Q
lRi18GTDfX143uApm++/bFkGy/m3UjocGxyx9xh/wpzKuTlqBvxAX/cSR7hw3imC
5t2t6fmgIL9ZTED5FEyEgM1+zi/OfrPyqxKs/Qo8ZxoqMuZMHN4n9pJCtOvLT72H
PUNxfRKiqjTj9hgQUm+sc8vfYXGapLY7Ybi4VrNPtGUxH/iSRf29sYc7bQlIoXiW
KqcPjPuI/IZ8qMrNSloBgGeMuJ4iQn5shIZWbbgnJf5LcSO3SaPsLH80tnfimhkK
tj6+MMe9afss26DcNcw4mT3IljkSRjLxwsGUBBMBCgA+AhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAFiEE+ibKeEvhiJJ/IrmfZXDqARRvc1QFAmQIi3IFCQhfalcA
CgkQZXDqARRvc1QNYw//fohzqHChHrOl60maI533r+wIMaFnqAPS6+S4mlV5qCcy
t2CEvvtQ4ggjg7cjm/hKbDBGnOAl0/Cq2QVo+SNJGGBmdvPgCjC8o6Dc4KaFW8wO
H2OYMLWm1kzxM/aO7oEWNS4gi3mM1eb2yiT4Uk6jtEjQ/7gEc8B2PXWjvt9gw2RF
0rJDT9EMM5p/hSuAjfTOp4BfnKX5YM5G01iH7HPpGl+IAr6bcd30qoGmH/gpwWrK
8eMYQa3RkKtMFFLQpd7i4yGbQwg6XeY4e2xXKccCHR6tyhKqTyerZQVG1D95xHq5
mipz86eXArZSozhpaf/SlplI/YHqo38R94oOqSA13aBmIQf+PKR+DiKaR4/jMt38
3pH+RK80ucNS8ueMWaDj40r2oixbQ9A0uSN5tcq//IprT+ax2iuBwQEE3keZjJB7
UGNqXTnvEW52+hrUpqL1G4YNGnQBuL56iIlAqmnKS0VdXWOxI2U+En6AjIcRAqLZ
Gptv90Nc33mfe96Yka5dBWdk4oi/FNu/JnKAcZQPYkByaA8PQYXsnCmgJCQj/8aC
RPVddj83nHAE9AEI3n9aOD7jsR1gfYLwOw3fGJqx4MZWcHBAIUF/36FIHQ+ygQDT
+b39MpdENCW4q14GfAAcY9nsj2eW4YYRdAzY3YiqvwrajuP57pu+hOXimI2qEp/N
MElsZWFuYSBEdW1pdHJlc2N1IDxpbGVhbmFkdW1pdHJlc2N1OTVAZ21haWwuY29t
PsLBlAQTAQoAPhYhBPomynhL4YiSfyK5n2Vw6gEUb3NUBQJi/OUPAhsDBQkDwmcA
BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEGVw6gEUb3NUnHIP/j4W1IhIfdoK
7ZoPO2hELJC0vcCJGB6a0mVP3g3w6EalKGQsA4P8btKDNdjrZqP6OsN99RWenCCY
ASndKGq9SmYIe7Bnrr98xB528G3Bo271OCAKT1IauJ272NtMvqyzvgNVXTtZyzKM
/sX+l36QRlRbVi5VxpdVll70a1U7YxusvzBtFeWrdbVZ7vAY3kSrX7tXjZ8Nj8C3
UiPJdCguPBU+Fjzcs6gfJ7ngcQ1QHrjokMFBGU8nLcHyKrir1b2ltZ02fW+Tke1E
ViSQXIvF8a85OqklVxKDFu9EpZEg1lZo84UNGZDJpblpSbRnfQoBQxbmSp4u4nVR
lYVNqzKNkf/7w+xukE18LxFZ2zqeVt1WNOauDbcTWmoM4mQy70q79uiT6pTjEh/m
W1R74+vbXt6QKSxhV1YTDyYebumMGu94m9G5qwTg6/w0VZGnyV7ywqwKLztKHOBJ
wzP6e0jhS41bTShMlRuYo8lOgAenKuX/0EKdTonf3o+mp+qrSOlkVBeGiSjhv/Ts
qAiebOhJE1utw1iQpHEzKZGnm40f67RgSAUgKiZawCkVPtQcn2vDAfxb/r08/dfK
NCcXkGIsIQPclRaShCJFBaOXFO6G1jVE2jyj3bgXxUy/x9O8F3MebacKOzRROoL4
DSNp7KTil8kJq4EoqxSJJQMnhV7obSm3wsGUBBMBCgA+AhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAFiEE+ibKeEvhiJJ/IrmfZXDqARRvc1QFAmQIi2cFCQhfalcA
CgkQZXDqARRvc1RkoRAAkJMTQURsLPQLM0bSm5wnCufwe02wfPwLERfkG6+g+uln
uTZZIy6dmbh6TQdLt885V1D6hPOdbcaYTWUwDOC9BIJlZhcGdeNNhzJW03vnSI6H
kJ4rbsUBNlE+D1sJ4akRD1+zP1tkOu176uW966Qlpmt8LZxQi7vQoxjHKEQ/pJlQ
yvypXetxOeaqdUWz7Bgiw96dUJ+3lt8frICvYh/tDn7bv6+tTvvndcw825zoJr5R
JO8loNvkCA0KaszjSd2t8nv/0moX2s6OF8CA4pgwuC/y2ZONBy4DhzLzfZrUQjCX
CZqkO11nvfarWgTBsSgauZ/GZAj1QPOrhMgGyS1HZ4ktM8A26XBNJzkhzGCrFt0f
g/WyZBA8TZSn4CKogoK1143bvX0RBsVJt42yZQ+p6ihP8m1rSdAREtgwpjIqaa5u
fnEllokOK4GiQX2NmMcDTBdSPUF1ygKNMVr74xQf426V+54nGMfq7UVeJr8buhMm
mUgnwCozKD6nS0/tZD+FBs1ewsR//0Ij84loMkMlK+aPr4VuRwG58Riw57i/ulpm
+XBlw6+90e0bOz3wQC2knD+vuTKyfYTU7ersMCe9FXX1PaN1BCJxjn3ZwW1nOcjR
ZLbjvMlCo4C4w0dUV6opbPgC1GtiOYn47H9nZUIZgrAKvT5LTfTfvr5Pk3cwXDTO
wU0EYUy7kAEQAMR9kYA2RQOavRtsHys7IoPw8/ysfR/TBi2siRLOTDSCb9e3Rvpj
JoI0ZODtEMIRs5oA/JwXtQCV6hOoZuitjKV2o2/wff7yBTYDUPSiGk7SHoZBtq8F
8Dwy374D2C0cPnx9IAFW0tZgw0a6O0Sa/KZe5vJout1BGUMZKhdyGdaQ+7snwnD5
dFd2+XVsKOVJMu4STxBb4/MyWgUumHZ2fFrXiMSEfHhzD8ItlkCycJ/C1KhtjgzC
DJKUKO9X9nQqKQkqtVFNgWPyTGoG6VF3pNxSIzSCqfSlI9xRZFBb5aion/pAfTOj
/pZQVWNJwwonSute1ejScGiVGc0YBoporltkMfUMFh2HAW4miuhB2nsOYJFcD5TC
SSYcMBQJT32E9E4bFZf5KWjo6bcg20Vschi2nPpy171WouhJSTO+/e2Vm8HWYWu0
2FAOmNCT69XIlXBaYqbJV5Dis6tBozz0rkPfkOeyxlqCV9Gda62rwEu7sxYTWzTI
EHm5yeXn7zETvAwg1FoiJ9tlQUd7Hi95QUvLH9D4/pUQgRyfLrCX/zJH1mYgLkMk
NfxJw2qP98Dw9KazgYMdPemxTFp7gPmHwWHJ2+kgEqWMGBk6mVP76ejNTkVp78XV
7xGBH3qvkWm2qr2eDDdHg++V+yvp24VoZVrjo1XefROe1DdNfIHQtg1jABEBAAHC
wXwEGAEKACYWIQT6Jsp4S+GIkn8iuZ9lcOoBFG9zVAUCYUy7kAIbDAUJA8JnAAAK
CRBlcOoBFG9zVEq8EACD/7XohTdF/jfb85lh7/6vFD1XRh0UbSg9cm+b9bd7C3uf
bIl3AdI99SXPWkiRv+J8rMVuW78wtOVa/nFcxH8lqC+z1rpQxXkLYSapVsx7dnww
ize1hg9qXRysl+iYqGXXaRpDyRSoEMJailLv3T6URofa4qEJ3ROpWBfqmV/BUBs0
sqCKXsaRPZ00/CPiJMybP5lyBnOdfYjjYcQS26NEXXL6qr/uHcs7InAN1xxoOcCO
YE4jfsg2eXJobwWc57rGHEkAR4cvAhwPPtENHhkK0Rd+EIFMrsyjAthUJsmgSSaX
FIo2ubBII4VdCbGqVT4+szfTVHxUbuC1ITUOggqPuXy1bZcWHUyW/VhbrfBjbVN6
QF5v2J+P/2KK5bHCupbpyxgeJk45BTWdrixWdFM369ZE9Jh1LF811E+O0VAlnWPH
JKzbD6eKFjvTZ/Vb9Rq5+sjOw2U873AhKxH5xSfmGyPrkzDI6KM5lLfGVG1qH+NZ
YRMWU5WDP+VNREdmVxvTwnCVorawnawVvfikfL5YFogvumJHl1Z7SZlmqjrL4yQk
nCdFtWMTuZsjB9671X0E64u2lC3hGxyq+81OHUtaK11knr8XcYBRknKsVA2UvGlL
zuSVXnvmrf0qVz6PijECOCYMYTsZWJgMOPAC5oTA+jYSoiTyk0ZYcNrH550bhcLB
fAQYAQoAJgIbDBYhBPomynhL4YiSfyK5n2Vw6gEUb3NUBQJkCIuUBQkIX2qEAAoJ
EGVw6gEUb3NU6qMP/R80Q4G/CVLsrXMEWhiePIHmPYfLL1guvLNi/K3YocMFSloU
6QjyP2Lsceh5Sz5NB/+xr6p6nGpmc5FEGxr20SoXyEfJCNWXNR+4znkSzkRH1FJ+
QOYdlZCFaGGaQzTkji47heoW9m9to/dGv8fKa34VLo7wzvD3FyYdF27lSGNqSiIP
NFS8kGS5m0fVDHP2jgFjiWjcXRUG78KzH4Yansse5KTPj2dm8zb+o30jfd8dM1cc
d3FavQ74kjrbTubQWsStTNMBm9ML7vSoirs5P3d8NNLHSMDtlZfzNfWKkxthZY1N
86sMOoecaOl8rfBIKrXMkWJXRDoz6o8Xrd/+JeByDBGuM5jAMT0mQ5ckBwFN5Q7k
et0c/YomKZQ3ul3V44eS8hmizeWNM2r4x3DVJa+4tsXeTLSWWX79z276SqSxQveK
fnJh0ak8q0tqJAc6iflvUjIIW5c7aSfcul+u6/8S0T74nEHfBhpBjQm9BEumt1sS
fXGYO77LXemuYDWpe2v0BO0j5hBssYnJ/hUDXgy2+bMJXzohJqYEjSs9gdTDskD6
x9Z1sTHutikUw/g4gxxRThH2l4YhBb6kuwct9xzecT2/PVzXkjnt+gwQ6PHdyTWj
0//LZCKJVquluG3myyCMALInBkJ0dzwXKH0VHe8PYt18tEGGBkKUVsxBXBBe
=3DfGTx
-----END PGP PUBLIC KEY BLOCK-----

--------------8GYj2095KHgB9H0sMn4gUQO8--

--------------JOkbaTfqGHUSQFV4qoJMAw0T--

--------------cl5Z0IiqXxCk5qAIyow0bikW
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEE+ibKeEvhiJJ/IrmfZXDqARRvc1QFAmf+fX0FAwAAAAAACgkQZXDqARRvc1Rj
gA/+P/bBDdalkKNMNIYKY6Jsi0bEfWPDVw0ui94iDsVZfUSUmh9pxmoj2AP+eYdoBtBg8enF8Vju
shWUzxVoW0Ce9bqM1wx0fcFz6ItqerrO4rbPa3ZLIt5Rd0SUklhKP+uHHNtFS1EzdvD/TIpNAgjF
FU/k/IzImJmLUOwocdbwsU3HSosr9ztMIJqKcooiU/u6vL+pGw6Vr0itSQNNQI3g8qPH17MKdp2C
/FOtVn7YTHzM015EDvGDgmxCmxR5Wf4ywWA255NNHc810r3oBoldG9g/kXIFnFJy7SF/kKOVqXkn
fCFHN7DORIHxsmW48oFzx/Spb7xsvSDKh9h5z/ji6jTTa/EhSrlvEhdfdEY7h7nfGNx+4+RdL9s7
TYlNF1K1ANj5TTgl4+knlhzjLSq28jl0M3BI//ZHb0gPr70h88g/OWcuG/tljGsY6k/X/UOa6W/g
NNTu+jkJDnWfDY9AnSd9k6L59AirjDSFjwPcabHO91Q3KqjMKWXW+oi9C08tL68Q8gkC37SiKZLZ
ozH5nIGGSLu2YWpEomQa8/2Q1jiEiITTxjpqJD6WF6RJ+5jxRaHTr0B1vIfCLVKDBmvVnqpT5u5L
pfofelo7o6jU99MJH9ROgH2Xh1OLgBFpIJdL+J5/Hs0Wb6G2b/SwOEXnuXeb3KwKGn/2qEX1CT+S
YCM=
=qeqi
-----END PGP SIGNATURE-----

--------------cl5Z0IiqXxCk5qAIyow0bikW--


------------=_1744731542-24104-0--

MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Manoj Gupta <manojgupta@HIDDEN>
Subject: bug#27866: closed (bug#27866: Handle clang's internal libraries
 when finding compiler's internal libraries)
Message-ID: <handler.27866.D27866.174473153224017.notifdone <at> debbugs.gnu.org>
References: <987fa64c-b039-4a74-a479-0894171faed6@HIDDEN>
 <CAAMbb06ZDvGwrNbCg56DhLyZ9A+rN=2w+52AVm7tVMFYpL28oQ@HIDDEN>
X-Gnu-PR-Message: they-closed 27866
X-Gnu-PR-Package: libtool
Reply-To: 27866 <at> debbugs.gnu.org
Date: Tue, 15 Apr 2025 15:39:03 +0000
Content-Type: multipart/mixed; boundary="----------=_1744731543-24104-1"

This is a multi-part message in MIME format...

------------=_1744731543-24104-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Your bug report

#27866: Handle clang's internal libraries when finding compiler's internal =
libraries

which was filed against the libtool package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 27866 <at> debbugs.gnu.org.

--=20
27866: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D27866
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

------------=_1744731543-24104-1
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at 27866-done) by debbugs.gnu.org; 15 Apr 2025 15:38:52 +0000
Received: from localhost ([127.0.0.1]:53806 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1u4iNA-0006FI-1i
	for submit <at> debbugs.gnu.org; Tue, 15 Apr 2025 11:38:52 -0400
Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:41809)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <ileanadumitrescu95@HIDDEN>)
 id 1u4iN6-0006Dc-7J
 for 27866-done <at> debbugs.gnu.org; Tue, 15 Apr 2025 11:38:49 -0400
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43f106a3591so5261815e9.3
 for <27866-done <at> debbugs.gnu.org>; Tue, 15 Apr 2025 08:38:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1744731521; x=1745336321; darn=debbugs.gnu.org;
 h=autocrypt:subject:from:cc:to:content-language:user-agent
 :mime-version:date:message-id:from:to:cc:subject:date:message-id
 :reply-to; bh=SJoZD8h+KQ6UdHaoNnK20Vd/DI+WaZGFZN2kGn+vqx8=;
 b=b0Si+MIZ/8+lPBmL4pVecDaa7ZBCvCTDR7TTw3v6ruQv7imOvEwbrVuzwqQgtvNm0k
 gJad42c/oPE7tcDhm6eEno7KcMRdrBwhRHaGC+lNzs6LJYtXISi2km/qcNOx/aiEeNQU
 P8iyhXOrGBYPWvLH0QzVwD0O6IMJBNLK6JA/bqJjokm+v8ctrdNgaLHh0yVE92cf4RKr
 71ccJIK4oWNvZzv/eEGQ9LGUbtjiJp7CvZUFJtDI7NNT0R4Mz1fD5nzVwmeo0XD2yMVq
 IksDQGqZGmD0Xk6t6o9GN4JDYQOt8urVO+gn/pEN6DlbWnoFH3xI9T8dsPf3MLF4ykq9
 NUQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1744731521; x=1745336321;
 h=autocrypt:subject:from:cc:to:content-language:user-agent
 :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject
 :date:message-id:reply-to;
 bh=SJoZD8h+KQ6UdHaoNnK20Vd/DI+WaZGFZN2kGn+vqx8=;
 b=P0DOCuYwO7y6FmNkR/E9fnWbpSbE9CdimYngkkJVue6bZWzjvwq3aRvsQagV/KztUS
 hhFhMoWVk5cV4r8bQrsWhGrwEe3et669q4ulgVpXxINnoo/aYoET/cBIKHbMjmWRAKUa
 wrb7Q9MGgLL6FTvE86q8XV79pHl2XIlLlCP2y3+g1h39KB/zSBFQzQsPOFkn2WYB7skE
 zOSai1lCpTRR9DeZZafz0AledJINwQce5VY6wZMdXR0JBk/HfhQ5dup10iYdHpNz2vsx
 xCieQ+8C2g/gtkOXclSTsq5vfjvsEMkuwfXpdGRp4J2B4U/JJwMZUqYwcY0H8JwqpVwq
 Tmyg==
X-Gm-Message-State: AOJu0YyYYWg7orBXNPW5tEoMjOpMMeBLWtvoAZkE5bN3cNpluE6Ga7Fi
 +/BHXoRHeM463aCujyrUJcDo0alrlKvS5/8vE/A6Y4DHCK+oyeuItPK22Q==
X-Gm-Gg: ASbGncuIDumg5tWTii4YeIV6mBWmzo6G1epQMjQMGD0j+xkVlaeK4YNLZuB18JGUDX1
 LdnXi06nuxWrdfQBzD6MMcAXo/Jxa5uP2BqPis9UMryYq+p5zvHkOYiIfymsv9GiucgBmUwkw4u
 DAL2htSmVQLZKgqHRiZ891N6Yw2ndcZ+B/jc9YkdIEfFx4bfo1dUrwcCix915LUnsHGviEHh4Db
 JWs1B6jkIraf93axFN3H0T3SQirTLlNkFqyYAUIYQIR5gIFHlzypXKglOUMeca1EXW01tochs80
 NG5GeMvMPqrNK2dh0gk/AhQJgDfIU5jl62BLz8CD5jEUcrT22CIMYqdygsPO
X-Google-Smtp-Source: AGHT+IH/J0JbUSqp1vdoIgi3e+uGbfHVmwzUcPtFCQSOx4+vg7gnvVviX15IlFOHaWLqXEgf2h13/Q==
X-Received: by 2002:a05:600c:1d29:b0:43d:fa5e:50e6 with SMTP id
 5b1f17b1804b1-43f3a9c04efmr50517515e9.9.1744731520911; 
 Tue, 15 Apr 2025 08:38:40 -0700 (PDT)
Received: from [192.168.254.128] ([95.214.217.107])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43f233c824bsm211474765e9.24.2025.04.15.08.38.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 15 Apr 2025 08:38:40 -0700 (PDT)
Message-ID: <987fa64c-b039-4a74-a479-0894171faed6@HIDDEN>
Date: Tue, 15 Apr 2025 18:38:36 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: 27866-done <at> debbugs.gnu.org
From: Ileana Dumitrescu <ileanadumitrescu95@HIDDEN>
Subject: bug#27866: Handle clang's internal libraries when finding compiler's
 internal libraries
Autocrypt: addr=ileanadumitrescu95@HIDDEN; keydata=
 xsFNBGFMu5ABEACpFrPCKpfsTSl4svqi91Hsf8gGtdKwndgXqMPJNqBXEJCCwiiUPnS68wNW
 ae54So04zVAcXewFdM36GypUGep5bhdgvbVKaDCrhNRdAoZ0VAywgU9CDCAa3v8eXUSrlGon
 k/ygjLIMnkOSjIMls4+z0FOpvsd1IcgcBDU5S6DSAF/Sb8w9bF2yD7f5RaLN6++EJEO2Bp+8
 v4qCJEUGzi5QJKXHVUTGiTirx50eLIkw0HseLVOiJoU0NRRgzK/q04+X/NuOAPnZm5K3GOJU
 mKmG7M2tdMhhGT7UjF3XiI0MwydGIrPU1T1OdPBnXv6ajRYzLgIZl0GsGeFo5qFaFmRtNO7n
 CGi/5XtivM1WvbqXIQmsAmpm8N/uEcPcuP+0+7s1o0JC+c4nbHlQyvUFSZVgbZQ+mSn6GXRP
 NfL7AeDSINXXvXDv5vkHN+FbFggx5nWg8J5a33hxbnZoR/qTfDBQHF3mJMF3lesXibN+oLvw
 OVtlIffKc4jwjLKL40644eQfbhHjCE1AXGQjUGCE5vAkCxEqWH2nQbXIedijQD/5mufaCQX3
 Rl314FBfyV1b9rIHxJYRLXHT83+om7y5ncYI5sdoY7/g/Ggmi0PuuUicax/ejOx4nNtDgDxl
 hCgOVm6qpmX9kyEZj0+vAodQjMrx3JKgojBdbusl4C5bWIgeRwARAQABzTBJbGVhbmEgRHVt
 aXRyZXNjdSA8aWxlYW5hZHVtaXRyZXNjdTk1QGdtYWlsLmNvbT7CwZQEEwEKAD4CGwMFCwkI
 BwIGFQoJCAsCBBYCAwECHgECF4AWIQT6Jsp4S+GIkn8iuZ9lcOoBFG9zVAUCZAiLZwUJCF9q
 VwAKCRBlcOoBFG9zVGShEACQkxNBRGws9AszRtKbnCcK5/B7TbB8/AsRF+Qbr6D66We5Nlkj
 Lp2ZuHpNB0u3zzlXUPqE851txphNZTAM4L0EgmVmFwZ1402HMlbTe+dIjoeQnituxQE2UT4P
 WwnhqREPX7M/W2Q67Xvq5b3rpCWma3wtnFCLu9CjGMcoRD+kmVDK/Kld63E55qp1RbPsGCLD
 3p1Qn7eW3x+sgK9iH+0Oftu/r61O++d1zDzbnOgmvlEk7yWg2+QIDQpqzONJ3a3ye//Sahfa
 zo4XwIDimDC4L/LZk40HLgOHMvN9mtRCMJcJmqQ7XWe99qtaBMGxKBq5n8ZkCPVA86uEyAbJ
 LUdniS0zwDbpcE0nOSHMYKsW3R+D9bJkEDxNlKfgIqiCgrXXjdu9fREGxUm3jbJlD6nqKE/y
 bWtJ0BES2DCmMipprm5+cSWWiQ4rgaJBfY2YxwNMF1I9QXXKAo0xWvvjFB/jbpX7nicYx+rt
 RV4mvxu6EyaZSCfAKjMoPqdLT+1kP4UGzV7CxH//QiPziWgyQyUr5o+vhW5HAbnxGLDnuL+6
 Wmb5cGXDr73R7Rs7PfBALaScP6+5MrJ9hNTt6uwwJ70VdfU9o3UEInGOfdnBbWc5yNFktuO8
 yUKjgLjDR1RXqils+ALUa2I5ifjsf2dlQhmCsAq9PktN9N++vk+TdzBcNM7BTQRhTLuQARAA
 xH2RgDZFA5q9G2wfKzsig/Dz/Kx9H9MGLayJEs5MNIJv17dG+mMmgjRk4O0QwhGzmgD8nBe1
 AJXqE6hm6K2MpXajb/B9/vIFNgNQ9KIaTtIehkG2rwXwPDLfvgPYLRw+fH0gAVbS1mDDRro7
 RJr8pl7m8mi63UEZQxkqF3IZ1pD7uyfCcPl0V3b5dWwo5Uky7hJPEFvj8zJaBS6YdnZ8WteI
 xIR8eHMPwi2WQLJwn8LUqG2ODMIMkpQo71f2dCopCSq1UU2BY/JMagbpUXek3FIjNIKp9KUj
 3FFkUFvlqKif+kB9M6P+llBVY0nDCidK617V6NJwaJUZzRgGimiuW2Qx9QwWHYcBbiaK6EHa
 ew5gkVwPlMJJJhwwFAlPfYT0ThsVl/kpaOjptyDbRWxyGLac+nLXvVai6ElJM7797ZWbwdZh
 a7TYUA6Y0JPr1ciVcFpipslXkOKzq0GjPPSuQ9+Q57LGWoJX0Z1rravAS7uzFhNbNMgQebnJ
 5efvMRO8DCDUWiIn22VBR3seL3lBS8sf0Pj+lRCBHJ8usJf/MkfWZiAuQyQ1/EnDao/3wPD0
 prOBgx096bFMWnuA+YfBYcnb6SASpYwYGTqZU/vp6M1ORWnvxdXvEYEfeq+RabaqvZ4MN0eD
 75X7K+nbhWhlWuOjVd59E57UN018gdC2DWMAEQEAAcLBfAQYAQoAJgIbDBYhBPomynhL4YiS
 fyK5n2Vw6gEUb3NUBQJkCIuUBQkIX2qEAAoJEGVw6gEUb3NU6qMP/R80Q4G/CVLsrXMEWhie
 PIHmPYfLL1guvLNi/K3YocMFSloU6QjyP2Lsceh5Sz5NB/+xr6p6nGpmc5FEGxr20SoXyEfJ
 CNWXNR+4znkSzkRH1FJ+QOYdlZCFaGGaQzTkji47heoW9m9to/dGv8fKa34VLo7wzvD3FyYd
 F27lSGNqSiIPNFS8kGS5m0fVDHP2jgFjiWjcXRUG78KzH4Yansse5KTPj2dm8zb+o30jfd8d
 M1ccd3FavQ74kjrbTubQWsStTNMBm9ML7vSoirs5P3d8NNLHSMDtlZfzNfWKkxthZY1N86sM
 OoecaOl8rfBIKrXMkWJXRDoz6o8Xrd/+JeByDBGuM5jAMT0mQ5ckBwFN5Q7ket0c/YomKZQ3
 ul3V44eS8hmizeWNM2r4x3DVJa+4tsXeTLSWWX79z276SqSxQveKfnJh0ak8q0tqJAc6iflv
 UjIIW5c7aSfcul+u6/8S0T74nEHfBhpBjQm9BEumt1sSfXGYO77LXemuYDWpe2v0BO0j5hBs
 sYnJ/hUDXgy2+bMJXzohJqYEjSs9gdTDskD6x9Z1sTHutikUw/g4gxxRThH2l4YhBb6kuwct
 9xzecT2/PVzXkjnt+gwQ6PHdyTWj0//LZCKJVquluG3myyCMALInBkJ0dzwXKH0VHe8PYt18
 tEGGBkKUVsxBXBBe
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------cl5Z0IiqXxCk5qAIyow0bikW"
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 27866-done
Cc: =?UTF-8?Q?Martin_Storsj=C3=B6?= <martin@HIDDEN>,
 Manoj Gupta <manojgupta@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.7 (/)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------cl5Z0IiqXxCk5qAIyow0bikW
Content-Type: multipart/mixed; boundary="------------JOkbaTfqGHUSQFV4qoJMAw0T";
 protected-headers="v1"
From: Ileana Dumitrescu <ileanadumitrescu95@HIDDEN>
To: 27866-done <at> debbugs.gnu.org
Cc: Manoj Gupta <manojgupta@HIDDEN>, =?UTF-8?Q?Martin_Storsj=C3=B6?=
 <martin@HIDDEN>
Message-ID: <987fa64c-b039-4a74-a479-0894171faed6@HIDDEN>
Subject: bug#27866: Handle clang's internal libraries when finding compiler's
 internal libraries

--------------JOkbaTfqGHUSQFV4qoJMAw0T
Content-Type: multipart/mixed; boundary="------------8GYj2095KHgB9H0sMn4gUQO8"

--------------8GYj2095KHgB9H0sMn4gUQO8
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

VGhhbmsgeW91IGZvciB5b3VyIGJ1ZyBzdWJtaXNzaW9uLiBUaGlzIGlzc3VlIG1heSBiZSBm
aXhlZCBieQ0KdXRpbGl6aW5nIGEgbmV3IGNvbmZpZ3VyYXRpb24gb3B0aW9uLCAtLWVuYWJs
ZS1jeHgtc3RkbGliIFsxXSwgc2luY2UgaXQNCmhhcyBiZWVuIGNvbmZpcm1lZCB0byBmaXgg
YSBzaW1pbGFyIGJ1ZyByZXBvcnQgWzJdLiBJZiByZS1jb25maWd1cmluZw0KZG9lcyBub3Qg
Zml4IHRoZSBpc3N1ZSwgSSB3aWxsIHJlb3BlbiB0aGlzIGJ1Zy4NCg0KWzFdIA0KaHR0cHM6
Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9jZ2l0L2xpYnRvb2wuZ2l0L2NvbW1pdC8/aWQ9OWJj
NzUzNmJkODc1NWYzYjYzMTE4NjEzNDk2YTg5NjcxNTEyZjJkYg0KWzJdIGh0dHBzOi8vc2F2
YW5uYWguZ251Lm9yZy9zdXBwb3J0L2luZGV4LnBocD8xMTExOTMNCg0KLS0gDQpJbGVhbmEg
RHVtaXRyZXNjdQ0KDQpHUEcgUHVibGljIEtleTogRkEyNiBDQTc4IDRCRTEgODg5MiA3RjIy
IEI5OUYgNjU3MCBFQTAxIDE0NkYgNzM1NA0KDQo=
--------------8GYj2095KHgB9H0sMn4gUQO8
Content-Type: application/pgp-keys; name="OpenPGP_0x6570EA01146F7354.asc"
Content-Disposition: attachment; filename="OpenPGP_0x6570EA01146F7354.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBGFMu5ABEACpFrPCKpfsTSl4svqi91Hsf8gGtdKwndgXqMPJNqBXEJCCwiiU
PnS68wNWae54So04zVAcXewFdM36GypUGep5bhdgvbVKaDCrhNRdAoZ0VAywgU9C
DCAa3v8eXUSrlGonk/ygjLIMnkOSjIMls4+z0FOpvsd1IcgcBDU5S6DSAF/Sb8w9
bF2yD7f5RaLN6++EJEO2Bp+8v4qCJEUGzi5QJKXHVUTGiTirx50eLIkw0HseLVOi
JoU0NRRgzK/q04+X/NuOAPnZm5K3GOJUmKmG7M2tdMhhGT7UjF3XiI0MwydGIrPU
1T1OdPBnXv6ajRYzLgIZl0GsGeFo5qFaFmRtNO7nCGi/5XtivM1WvbqXIQmsAmpm
8N/uEcPcuP+0+7s1o0JC+c4nbHlQyvUFSZVgbZQ+mSn6GXRPNfL7AeDSINXXvXDv
5vkHN+FbFggx5nWg8J5a33hxbnZoR/qTfDBQHF3mJMF3lesXibN+oLvwOVtlIffK
c4jwjLKL40644eQfbhHjCE1AXGQjUGCE5vAkCxEqWH2nQbXIedijQD/5mufaCQX3
Rl314FBfyV1b9rIHxJYRLXHT83+om7y5ncYI5sdoY7/g/Ggmi0PuuUicax/ejOx4
nNtDgDxlhCgOVm6qpmX9kyEZj0+vAodQjMrx3JKgojBdbusl4C5bWIgeRwARAQAB
zS9JbGVhbmEgRHVtaXRyZXNjdSA8aWxlYW5hZHVtaTk1QHByb3Rvbm1haWwuY29t
PsLBlAQTAQoAPhYhBPomynhL4YiSfyK5n2Vw6gEUb3NUBQJhTLuQAhsDBQkDwmcA
BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEGVw6gEUb3NUCC4P/AiRUDzkEm8E
WdvGQ9CkUYPAOARr19w04+N+86XZU8owULTkys81Wv80Wz48Q6IA3RASjHuyNtOQ
a3TmoGsRYovIqKWQY6hIWBY7radPldSnbqXDp0mbwxSFVsCV2m2YqZKQpnKTR7b5
N6KgKKDXDLK0ES5CO1DAdvTg33WOonSNVpP+14R1bg9L685nOckK+TP1kQq91W+0
QUeEfS7BqdU/Znv39sVVMUkXQiWK441rQ1wcHvD32iiSoqnFQxtrdTwaglpv1/Y6
MDsnnwrLX3Bsq0vIL8CYVwVqy309/rtq3tpL1dw9lWaEA0sBNBMfOvBBJ1GOUpnE
f6k6dlhHSoDDndbODXBEAgXnbz6JKqPA+NAJfnccnvcb7G2KnWtvG/GbWQia7S1Q
lRi18GTDfX143uApm++/bFkGy/m3UjocGxyx9xh/wpzKuTlqBvxAX/cSR7hw3imC
5t2t6fmgIL9ZTED5FEyEgM1+zi/OfrPyqxKs/Qo8ZxoqMuZMHN4n9pJCtOvLT72H
PUNxfRKiqjTj9hgQUm+sc8vfYXGapLY7Ybi4VrNPtGUxH/iSRf29sYc7bQlIoXiW
KqcPjPuI/IZ8qMrNSloBgGeMuJ4iQn5shIZWbbgnJf5LcSO3SaPsLH80tnfimhkK
tj6+MMe9afss26DcNcw4mT3IljkSRjLxwsGUBBMBCgA+AhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAFiEE+ibKeEvhiJJ/IrmfZXDqARRvc1QFAmQIi3IFCQhfalcA
CgkQZXDqARRvc1QNYw//fohzqHChHrOl60maI533r+wIMaFnqAPS6+S4mlV5qCcy
t2CEvvtQ4ggjg7cjm/hKbDBGnOAl0/Cq2QVo+SNJGGBmdvPgCjC8o6Dc4KaFW8wO
H2OYMLWm1kzxM/aO7oEWNS4gi3mM1eb2yiT4Uk6jtEjQ/7gEc8B2PXWjvt9gw2RF
0rJDT9EMM5p/hSuAjfTOp4BfnKX5YM5G01iH7HPpGl+IAr6bcd30qoGmH/gpwWrK
8eMYQa3RkKtMFFLQpd7i4yGbQwg6XeY4e2xXKccCHR6tyhKqTyerZQVG1D95xHq5
mipz86eXArZSozhpaf/SlplI/YHqo38R94oOqSA13aBmIQf+PKR+DiKaR4/jMt38
3pH+RK80ucNS8ueMWaDj40r2oixbQ9A0uSN5tcq//IprT+ax2iuBwQEE3keZjJB7
UGNqXTnvEW52+hrUpqL1G4YNGnQBuL56iIlAqmnKS0VdXWOxI2U+En6AjIcRAqLZ
Gptv90Nc33mfe96Yka5dBWdk4oi/FNu/JnKAcZQPYkByaA8PQYXsnCmgJCQj/8aC
RPVddj83nHAE9AEI3n9aOD7jsR1gfYLwOw3fGJqx4MZWcHBAIUF/36FIHQ+ygQDT
+b39MpdENCW4q14GfAAcY9nsj2eW4YYRdAzY3YiqvwrajuP57pu+hOXimI2qEp/N
MElsZWFuYSBEdW1pdHJlc2N1IDxpbGVhbmFkdW1pdHJlc2N1OTVAZ21haWwuY29t
PsLBlAQTAQoAPhYhBPomynhL4YiSfyK5n2Vw6gEUb3NUBQJi/OUPAhsDBQkDwmcA
BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEGVw6gEUb3NUnHIP/j4W1IhIfdoK
7ZoPO2hELJC0vcCJGB6a0mVP3g3w6EalKGQsA4P8btKDNdjrZqP6OsN99RWenCCY
ASndKGq9SmYIe7Bnrr98xB528G3Bo271OCAKT1IauJ272NtMvqyzvgNVXTtZyzKM
/sX+l36QRlRbVi5VxpdVll70a1U7YxusvzBtFeWrdbVZ7vAY3kSrX7tXjZ8Nj8C3
UiPJdCguPBU+Fjzcs6gfJ7ngcQ1QHrjokMFBGU8nLcHyKrir1b2ltZ02fW+Tke1E
ViSQXIvF8a85OqklVxKDFu9EpZEg1lZo84UNGZDJpblpSbRnfQoBQxbmSp4u4nVR
lYVNqzKNkf/7w+xukE18LxFZ2zqeVt1WNOauDbcTWmoM4mQy70q79uiT6pTjEh/m
W1R74+vbXt6QKSxhV1YTDyYebumMGu94m9G5qwTg6/w0VZGnyV7ywqwKLztKHOBJ
wzP6e0jhS41bTShMlRuYo8lOgAenKuX/0EKdTonf3o+mp+qrSOlkVBeGiSjhv/Ts
qAiebOhJE1utw1iQpHEzKZGnm40f67RgSAUgKiZawCkVPtQcn2vDAfxb/r08/dfK
NCcXkGIsIQPclRaShCJFBaOXFO6G1jVE2jyj3bgXxUy/x9O8F3MebacKOzRROoL4
DSNp7KTil8kJq4EoqxSJJQMnhV7obSm3wsGUBBMBCgA+AhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAFiEE+ibKeEvhiJJ/IrmfZXDqARRvc1QFAmQIi2cFCQhfalcA
CgkQZXDqARRvc1RkoRAAkJMTQURsLPQLM0bSm5wnCufwe02wfPwLERfkG6+g+uln
uTZZIy6dmbh6TQdLt885V1D6hPOdbcaYTWUwDOC9BIJlZhcGdeNNhzJW03vnSI6H
kJ4rbsUBNlE+D1sJ4akRD1+zP1tkOu176uW966Qlpmt8LZxQi7vQoxjHKEQ/pJlQ
yvypXetxOeaqdUWz7Bgiw96dUJ+3lt8frICvYh/tDn7bv6+tTvvndcw825zoJr5R
JO8loNvkCA0KaszjSd2t8nv/0moX2s6OF8CA4pgwuC/y2ZONBy4DhzLzfZrUQjCX
CZqkO11nvfarWgTBsSgauZ/GZAj1QPOrhMgGyS1HZ4ktM8A26XBNJzkhzGCrFt0f
g/WyZBA8TZSn4CKogoK1143bvX0RBsVJt42yZQ+p6ihP8m1rSdAREtgwpjIqaa5u
fnEllokOK4GiQX2NmMcDTBdSPUF1ygKNMVr74xQf426V+54nGMfq7UVeJr8buhMm
mUgnwCozKD6nS0/tZD+FBs1ewsR//0Ij84loMkMlK+aPr4VuRwG58Riw57i/ulpm
+XBlw6+90e0bOz3wQC2knD+vuTKyfYTU7ersMCe9FXX1PaN1BCJxjn3ZwW1nOcjR
ZLbjvMlCo4C4w0dUV6opbPgC1GtiOYn47H9nZUIZgrAKvT5LTfTfvr5Pk3cwXDTO
wU0EYUy7kAEQAMR9kYA2RQOavRtsHys7IoPw8/ysfR/TBi2siRLOTDSCb9e3Rvpj
JoI0ZODtEMIRs5oA/JwXtQCV6hOoZuitjKV2o2/wff7yBTYDUPSiGk7SHoZBtq8F
8Dwy374D2C0cPnx9IAFW0tZgw0a6O0Sa/KZe5vJout1BGUMZKhdyGdaQ+7snwnD5
dFd2+XVsKOVJMu4STxBb4/MyWgUumHZ2fFrXiMSEfHhzD8ItlkCycJ/C1KhtjgzC
DJKUKO9X9nQqKQkqtVFNgWPyTGoG6VF3pNxSIzSCqfSlI9xRZFBb5aion/pAfTOj
/pZQVWNJwwonSute1ejScGiVGc0YBoporltkMfUMFh2HAW4miuhB2nsOYJFcD5TC
SSYcMBQJT32E9E4bFZf5KWjo6bcg20Vschi2nPpy171WouhJSTO+/e2Vm8HWYWu0
2FAOmNCT69XIlXBaYqbJV5Dis6tBozz0rkPfkOeyxlqCV9Gda62rwEu7sxYTWzTI
EHm5yeXn7zETvAwg1FoiJ9tlQUd7Hi95QUvLH9D4/pUQgRyfLrCX/zJH1mYgLkMk
NfxJw2qP98Dw9KazgYMdPemxTFp7gPmHwWHJ2+kgEqWMGBk6mVP76ejNTkVp78XV
7xGBH3qvkWm2qr2eDDdHg++V+yvp24VoZVrjo1XefROe1DdNfIHQtg1jABEBAAHC
wXwEGAEKACYWIQT6Jsp4S+GIkn8iuZ9lcOoBFG9zVAUCYUy7kAIbDAUJA8JnAAAK
CRBlcOoBFG9zVEq8EACD/7XohTdF/jfb85lh7/6vFD1XRh0UbSg9cm+b9bd7C3uf
bIl3AdI99SXPWkiRv+J8rMVuW78wtOVa/nFcxH8lqC+z1rpQxXkLYSapVsx7dnww
ize1hg9qXRysl+iYqGXXaRpDyRSoEMJailLv3T6URofa4qEJ3ROpWBfqmV/BUBs0
sqCKXsaRPZ00/CPiJMybP5lyBnOdfYjjYcQS26NEXXL6qr/uHcs7InAN1xxoOcCO
YE4jfsg2eXJobwWc57rGHEkAR4cvAhwPPtENHhkK0Rd+EIFMrsyjAthUJsmgSSaX
FIo2ubBII4VdCbGqVT4+szfTVHxUbuC1ITUOggqPuXy1bZcWHUyW/VhbrfBjbVN6
QF5v2J+P/2KK5bHCupbpyxgeJk45BTWdrixWdFM369ZE9Jh1LF811E+O0VAlnWPH
JKzbD6eKFjvTZ/Vb9Rq5+sjOw2U873AhKxH5xSfmGyPrkzDI6KM5lLfGVG1qH+NZ
YRMWU5WDP+VNREdmVxvTwnCVorawnawVvfikfL5YFogvumJHl1Z7SZlmqjrL4yQk
nCdFtWMTuZsjB9671X0E64u2lC3hGxyq+81OHUtaK11knr8XcYBRknKsVA2UvGlL
zuSVXnvmrf0qVz6PijECOCYMYTsZWJgMOPAC5oTA+jYSoiTyk0ZYcNrH550bhcLB
fAQYAQoAJgIbDBYhBPomynhL4YiSfyK5n2Vw6gEUb3NUBQJkCIuUBQkIX2qEAAoJ
EGVw6gEUb3NU6qMP/R80Q4G/CVLsrXMEWhiePIHmPYfLL1guvLNi/K3YocMFSloU
6QjyP2Lsceh5Sz5NB/+xr6p6nGpmc5FEGxr20SoXyEfJCNWXNR+4znkSzkRH1FJ+
QOYdlZCFaGGaQzTkji47heoW9m9to/dGv8fKa34VLo7wzvD3FyYdF27lSGNqSiIP
NFS8kGS5m0fVDHP2jgFjiWjcXRUG78KzH4Yansse5KTPj2dm8zb+o30jfd8dM1cc
d3FavQ74kjrbTubQWsStTNMBm9ML7vSoirs5P3d8NNLHSMDtlZfzNfWKkxthZY1N
86sMOoecaOl8rfBIKrXMkWJXRDoz6o8Xrd/+JeByDBGuM5jAMT0mQ5ckBwFN5Q7k
et0c/YomKZQ3ul3V44eS8hmizeWNM2r4x3DVJa+4tsXeTLSWWX79z276SqSxQveK
fnJh0ak8q0tqJAc6iflvUjIIW5c7aSfcul+u6/8S0T74nEHfBhpBjQm9BEumt1sS
fXGYO77LXemuYDWpe2v0BO0j5hBssYnJ/hUDXgy2+bMJXzohJqYEjSs9gdTDskD6
x9Z1sTHutikUw/g4gxxRThH2l4YhBb6kuwct9xzecT2/PVzXkjnt+gwQ6PHdyTWj
0//LZCKJVquluG3myyCMALInBkJ0dzwXKH0VHe8PYt18tEGGBkKUVsxBXBBe
=3DfGTx
-----END PGP PUBLIC KEY BLOCK-----

--------------8GYj2095KHgB9H0sMn4gUQO8--

--------------JOkbaTfqGHUSQFV4qoJMAw0T--

--------------cl5Z0IiqXxCk5qAIyow0bikW
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEE+ibKeEvhiJJ/IrmfZXDqARRvc1QFAmf+fX0FAwAAAAAACgkQZXDqARRvc1Rj
gA/+P/bBDdalkKNMNIYKY6Jsi0bEfWPDVw0ui94iDsVZfUSUmh9pxmoj2AP+eYdoBtBg8enF8Vju
shWUzxVoW0Ce9bqM1wx0fcFz6ItqerrO4rbPa3ZLIt5Rd0SUklhKP+uHHNtFS1EzdvD/TIpNAgjF
FU/k/IzImJmLUOwocdbwsU3HSosr9ztMIJqKcooiU/u6vL+pGw6Vr0itSQNNQI3g8qPH17MKdp2C
/FOtVn7YTHzM015EDvGDgmxCmxR5Wf4ywWA255NNHc810r3oBoldG9g/kXIFnFJy7SF/kKOVqXkn
fCFHN7DORIHxsmW48oFzx/Spb7xsvSDKh9h5z/ji6jTTa/EhSrlvEhdfdEY7h7nfGNx+4+RdL9s7
TYlNF1K1ANj5TTgl4+knlhzjLSq28jl0M3BI//ZHb0gPr70h88g/OWcuG/tljGsY6k/X/UOa6W/g
NNTu+jkJDnWfDY9AnSd9k6L59AirjDSFjwPcabHO91Q3KqjMKWXW+oi9C08tL68Q8gkC37SiKZLZ
ozH5nIGGSLu2YWpEomQa8/2Q1jiEiITTxjpqJD6WF6RJ+5jxRaHTr0B1vIfCLVKDBmvVnqpT5u5L
pfofelo7o6jU99MJH9ROgH2Xh1OLgBFpIJdL+J5/Hs0Wb6G2b/SwOEXnuXeb3KwKGn/2qEX1CT+S
YCM=
=qeqi
-----END PGP SIGNATURE-----

--------------cl5Z0IiqXxCk5qAIyow0bikW--


------------=_1744731543-24104-1
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at submit) by debbugs.gnu.org; 28 Jul 2017 21:04:26 +0000
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 &quot;-lname&quot; 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 &quot;$output_verbose_link_cmd&quot;`; 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}&quot; 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 &quot;=
$p&quot; ||</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&quot;/usr/bin/x86_64-pc=
-linux-gnu-ld&quot; --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--



------------=_1744731543-24104-1--

X-Loop: help-debbugs@HIDDEN
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Resent-From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Fri, 25 Apr 2025 13:45:02 +0000
Resent-Message-ID: <handler.27866.D27866.174558864419095 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27866
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Ileana Dumitrescu <ileanadumitrescu95@HIDDEN>
Cc: Manoj Gupta <manojgupta@HIDDEN>, 27866-done <at> debbugs.gnu.org
Received: via spool by 27866-done <at> debbugs.gnu.org id=D27866.174558864419095
          (code D ref 27866); Fri, 25 Apr 2025 13:45:02 +0000
Received: (at 27866-done) by debbugs.gnu.org; 25 Apr 2025 13:44:04 +0000
Received: from localhost ([127.0.0.1]:48969 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1u8JLY-0004xt-5f
	for submit <at> debbugs.gnu.org; Fri, 25 Apr 2025 09:44:04 -0400
Received: from mail-lf1-x129.google.com ([2a00:1450:4864:20::129]:46383)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <martin@HIDDEN>) id 1u8JLT-0004xG-Oq
 for 27866-done <at> debbugs.gnu.org; Fri, 25 Apr 2025 09:44:02 -0400
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-54ac9b3ddf6so2066916e87.1
 for <27866-done <at> debbugs.gnu.org>; Fri, 25 Apr 2025 06:43:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=martin-st.20230601.gappssmtp.com; s=20230601; t=1745588633; x=1746193433;
 darn=debbugs.gnu.org; 
 h=mime-version:references:message-id:in-reply-to:subject:cc:to:from
 :date:from:to:cc:subject:date:message-id:reply-to;
 bh=/+f8FdArmi7dpjBUFuSJNkuj6+WKaJGMNUEfIbxdxVY=;
 b=pO/5/7PTFUvbpEljuiNAaBPSIbnjxWsrjap+OP/ZpR5WDuNa7ZdPChYEQQXKPQtGYI
 6tTpaO0txEQ/EcmuGv0n769fQ6ocIkGJyiria9MNgbl6Tw0MDKyunq1Ou1L9mAJCVdS1
 /dJxn5itsA7VMr1qgqeJfFkE43EAp2+JSxobqljhwIQY5kZJY2ti/nw6m32JeCg2WZPb
 wHlKfZgu7ft7on6uxhj1XeXpdr99JqX0+l+OZr4YNN0/cz1QqHzkfyQ3b2fNsOOPYen8
 Bab/3ZYH3BnsQMBehP7b+IbEczneki2OvW2tdndFtvy/pnSUbQipKSjLLd58zb7sUr6c
 3nDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1745588633; x=1746193433;
 h=mime-version:references:message-id:in-reply-to:subject:cc:to:from
 :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=/+f8FdArmi7dpjBUFuSJNkuj6+WKaJGMNUEfIbxdxVY=;
 b=NPhw1ZRb8qqLRxceOhxCLv5AUQ43+gkrqo9ueBtryjERrypCDHeYlWjGA5iPemxLAY
 SNwZaM7cau2XPGiXioXWpiHUbYk/8ByNe2EYxBTDag4m+u0zpLmY+oFjUUvP/neErCX8
 q036Z5S0rDgJT/sm4rUtFXVb3EA/zbKhEOfjPAiXnOdPfgA4V0DBmBeKyTHUBa9txm7C
 YDUWE4omXuA9u83IDAQkSAlWMLv4mJQH427E3Zb1c/IyutYo2FFbhpRnoxMKeyd0+kCa
 TzGbEcIO2a8JWlT+O795mSRNkRSm6UlBYG4izoDQfubb/KmdSNXU6xgjN0lXzzGuZE4l
 BbBA==
X-Gm-Message-State: AOJu0YxVe9zaEOiHMgiC4ObwNHNHy7Ke9qDUdGS7zJrIPft2hP13yQ/n
 2ks3RPS83Rw/dG/qnvcNl+F1JUCHYkKf9uTkYMK2LWZjiZLFkIoNqCjkqL10jA==
X-Gm-Gg: ASbGncuNq9nXaKml4BGn+LPMinZlogfh70kvKQNJmMQQtYqOmv2I2PxMaTKiKgQmxjb
 kZrC/5Jh3EyfQcRn0F0SitoT+10nxXqNs91Lorxc8S/Pl/er/mdUXkmEzq78+/4/wM89jMMXv9P
 Y0ABxrxU8OFHrknq1Fa9BxBbYE5LXzqJu9bnb/y0gf+Nm2nVOtRXsXgCYiiBxZrQX0byHf6nhWL
 P9o53eDNYfPuWGoZHG6/gX6yB5jCCGCXrEKLi2AtldfPJeNcUv+KeikkcBdX8gBylmkV/tb81n5
 V8xodCVuUWB5sIaA6GpH2Z+HJ8DUQmaqw+MS0xap/hA+04buu7GP1nXwqSKyxSmJkvioovFKJX2
 qVSyz78n1DMY+Gd+jvteDKSJBAAhUQwCRtmqc
X-Google-Smtp-Source: AGHT+IF4UbBAkVDkTeWBzO9G4oCTwGqjSqG+04z3oO8IC7HlvuI94AdXAfn1/C7Ycd22dUUX50JQMg==
X-Received: by 2002:a05:6512:3995:b0:54d:6a89:88ab with SMTP id
 2adb3069b0e04-54e8cbcdb08mr619912e87.1.1745588632861; 
 Fri, 25 Apr 2025 06:43:52 -0700 (PDT)
Received: from tunnel335574-pt.tunnel.tserv24.sto1.ipv6.he.net
 (tunnel335574-pt.tunnel.tserv24.sto1.ipv6.he.net. [2001:470:27:11::2])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-54e7ccb7df0sm597534e87.225.2025.04.25.06.43.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 25 Apr 2025 06:43:52 -0700 (PDT)
Date: Fri, 25 Apr 2025 16:43:49 +0300 (EEST)
From: Martin =?UTF-8?Q?Storsj=C3=B6?= <martin@HIDDEN>
In-Reply-To: <987fa64c-b039-4a74-a479-0894171faed6@HIDDEN>
Message-ID: <b94e5462-f793-af5b-1a9f-4f373f143eb8@HIDDEN>
References: <987fa64c-b039-4a74-a479-0894171faed6@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
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 (-)

Hi Ileana,

On Tue, 15 Apr 2025, Ileana Dumitrescu wrote:

> Thank you for your bug submission. This issue may be fixed by
> utilizing a new configuration option, --enable-cxx-stdlib [1], since it
> has been confirmed to fix a similar bug report [2]. If re-configuring
> does not fix the issue, I will reopen this bug.

Thanks for looking into this bug (and sorry for taking a little while to 
follow up on this).

Yes, using the new option --enable-cxx-stdlib does avoid hitting this 
issue. However, as this requires explicit opt-in from users (either from 
project maintainers, enabling it via LT_INIT, or from users to configure 
with --enable-cxx-stdlib), most users affected by this issue will still 
keep hitting this issue (although they might have a way to work around it) 
- so I would appreciate if this bug would be reopened.

If --enable-cxx-stdlib would be enabled by default (as it perhaps might do 
at some point in the future?), this wouldn't be as much of an issue any 
longer.

The issue can be reproduced with a very minimal testcase at [1], using a 
toolchain from [2], e.g. [3].

To reproduce the issue, unpack the toolchain, add it to $PATH, unpack the 
testcase, run ./autogen.sh, and configure and build with "./configure 
--host=x86_64-w64-mingw32 && make".

The issue can be fixed by the referenced patches, or by reapplying 
1d2577357ee704da2d6d7c7da119ad82ba8ca172 (which was reverted quickly 
afterwards, without much explanation). That fix commit in itself is 
mildly incorrect though, it requires changing m4/libtool.m4 to reference 
*/libclang_rt*.a instead of */clang_rt*.a.

[1] https://martin.st/temp/libtool-compiler-rt.tar.gz
[2] https://github.com/mstorsjo/llvm-mingw/releases
[3] https://github.com/mstorsjo/llvm-mingw/releases/download/20250417/llvm-mingw-20250417-ucrt-ubuntu-22.04-x86_64.tar.xz

Thanks for the consideration!

// Martin