bug#74175: libtool mishandles some compiler flags when used with MSVC tools
Kirill Makurin <[email protected]> Thu, 5 Jun 2025 16:26:23 +0000
| Newsgroups | gmane.comp.gnu.libtool.bugs |
|---|---|
| Message-ID | <DM4PR84MB1373897E9C69264214461C55B16FA@DM4PR84MB1373.NAMPRD84.PROD.OUTLOOK.COM> |
--_000_DM4PR84MB1373897E9C69264214461C55B16FADM4PR84MB1373NAMP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, this issue appears only with clang-cl.exe. The issue has been fixed fo= r cl.exe. I do not have icl.exe to test it, unfortunately. - Kirill Makurin ________________________________ From: Ileana Dumitrescu Sent: Friday, June 6, 2025 1:13 AM To: [email protected] Cc: Kirill Makurin Subject: Re: bug#74175: libtool mishandles some compiler flags when used wi= th MSVC tools On 05/06/2025 13:09, Kirill Makurin wrote: > I am actually wrong. If we would pass -Wl and friends as is to clang.exe > it would handle them correctly by itself. > > Note: clang.exe installed with Visual Studio uses link.exe, just like > cl.exe would. Thank you for the updates. Is this an issue specifically with clang-cl? I believe the issue is fixed with cl/cl.exe in development. > What do you think about checking whether compiler defines _MSC_VER macro? I do not have a strong opinion on this, so it could be added. Could you submit a patch for review? > - Kirill Makurin > ------------------------------------------------------------------------ > *From:* [email protected] <bug- > [email protected]> on behalf of Kirill > Makurin <[email protected]> > *Sent:* Thursday, June 5, 2025 6:58 PM > *To:* Ileana Dumitrescu <[email protected]>; > [email protected] <[email protected]> > *Subject:* bug#74175: libtool mishandles some compiler flags when used > with MSVC tools > Hi Ileana, > > The fix seems incomplete. > > See attached file for `libtool --mode=3Dlink` invocation with clang-cl. > You may notice that the flag passed with -Wl is passed twice: once on > its own (just like it was with cl.exe with the bug) and once properly > with -Wl. > > Do you think checking compiler's name is a good idea? AFAIK, all three > of cl.exe, clang-cl.exe and icl.exe (MSVC-like compilers handled by > Automake's `compile` wrapper) define _MSC_VER macro. If libtool does > check, it should be at least consistent with `compile` wrapper. There are checks for compilers in libtool, like "cl* | icl*)" for cc_basename when on a windows-like system. If libtool's configuration when using clang-cl.exe is incorrect, these could be updated to avoid clang-cl.exe or a new check could be added for the needed configuration. > Maybe libtool could check during configuration whether compiler defines > this macro to decide how to pass linker flags? Since `compile` wrapper > should usually be involved, we need to just pass -Wl flags and friends > as is, `compile` takes care of them. > > There is one problematic case though. If we would use clang.exe > installed with Visual Studio, this will not work. It defines _MSC_VER, > but it usus gcc-like command line options. -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 --_000_DM4PR84MB1373897E9C69264214461C55B16FADM4PR84MB1373NAMP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> Yes, this issue appears only with clang-cl.exe. The issue has been fixed fo= r cl.exe.</div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> I do not have icl.exe to test it, unfortunately.</div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> - Kirill Makurin</div> <div id=3D"appendonsend"></div> <div><br> </div> <div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size= : 12pt; color: rgb(0, 0, 0);"> <br> </div> <hr style=3D"display: inline-block; width: 98%;"> <div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size= : 12pt; color: rgb(0, 0, 0);"> <b>From:</b> Ileana Dumitrescu<br> <b>Sent:</b> Friday, June 6, 2025 1:13 AM<br> <b>To:</b> [email protected]<br> <b>Cc:</b> Kirill Makurin<br> <b>Subject:</b> Re: bug#74175: libtool mishandles some compiler flags = when used with MSVC tools </div> <div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size= : 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style=3D"font-size: 11pt;">On 05/06/2025 13:09, Kirill Makurin wrote:<= br> > I am actually wrong. If we would pass -Wl and friends as is to clang.e= xe<br> > it would handle them correctly by itself.<br> ><br> > Note: clang.exe installed with Visual Studio uses link.exe, just like<= br> > cl.exe would.<br> <br> Thank you for the updates. Is this an issue specifically with clang-cl?<br> I believe the issue is fixed with cl/cl.exe in development.<br> <br> > What do you think about checking whether compiler defines _MSC_VER mac= ro?<br> <br> I do not have a strong opinion on this, so it could be added. Could you<br> submit a patch for review?<br> <br> > - Kirill Makurin<br> > ----------------------------------------------------------------------= --<br> > *From:* [email protected] <bug-= <br> > [email protected]> on behalf of Kir= ill<br> > Makurin <[email protected]><br> > *Sent:* Thursday, June 5, 2025 6:58 PM<br> > *To:* Ileana Dumitrescu <[email protected]>;<br> > [email protected] <[email protected]><br> > *Subject:* bug#74175: libtool mishandles some compiler flags when used= <br> > with MSVC tools<br> > Hi Ileana,<br> ><br> > The fix seems incomplete.<br> ><br> > See attached file for `libtool --mode=3Dlink` invocation with clang-cl= .<br> > You may notice that the flag passed with -Wl is passed twice: once on<= br> > its own (just like it was with cl.exe with the bug) and once properly<= br> > with -Wl.<br> ><br> > Do you think checking compiler's name is a good idea? AFAIK, all three= <br> > of cl.exe, clang-cl.exe and icl.exe (MSVC-like compilers handled by<br= > > Automake's `compile` wrapper) define _MSC_VER macro. If libtool does<b= r> > check, it should be at least consistent with `compile` wrapper.<br> <br> There are checks for compilers in libtool, like "cl* | icl*)" for= <br> cc_basename when on a windows-like system. If libtool's configuration<br> when using clang-cl.exe is incorrect, these could be updated to avoid<br> clang-cl.exe or a new check could be added for the needed configuration.<br= > <br> > Maybe libtool could check during configuration whether compi= ler defines<br> > this macro to decide how to pass linker flags? Since `compile` wrapper= <br> > should usually be involved, we need to just pass -Wl flags and friends= <br> > as is, `compile` takes care of them.<br> ><br> > There is one problematic case though. If we would use clang.exe<br> > installed with Visual Studio, this will not work. It defines _MSC_VER,= <br> > but it usus gcc-like command line options.<br> <br> --<br> Ileana Dumitrescu<br> <br> GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354<br> <br> </div> </body> </html> --_000_DM4PR84MB1373897E9C69264214461C55B16FADM4PR84MB1373NAMP_--