bug#74175: libtool mishandles some compiler flags when used with MSVC tools
Kirill Makurin <[email protected]> Thu, 5 Jun 2025 09:58:23 +0000
| Newsgroups | gmane.comp.gnu.libtool.bugs |
|---|---|
| Message-ID | <DM4PR84MB13732B2989BE083B37B1EB60B16FA@DM4PR84MB1373.NAMPRD84.PROD.OUTLOOK.COM> |
--_004_DM4PR84MB13732B2989BE083B37B1EB60B16FADM4PR84MB1373NAMP_ Content-Type: multipart/alternative; boundary="_000_DM4PR84MB13732B2989BE083B37B1EB60B16FADM4PR84MB1373NAMP_" --_000_DM4PR84MB13732B2989BE083B37B1EB60B16FADM4PR84MB1373NAMP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 c= l.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. Maybe libtool could check during configuration whether compiler defines thi= s 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, `com= pile` takes care of them. There is one problematic case though. If we would use clang.exe installed w= ith Visual Studio, this will not work. It defines _MSC_VER, but it usus gcc= -like command line options. - Kirill Makurin ________________________________ From: Ileana Dumitrescu Sent: Friday, May 30, 2025 2:24 AM To: [email protected] Cc: Kirill Makurin Subject: Re: bug#74175: libtool mishandles some compiler flags when used wi= th MSVC tools On 13/11/2024 21:59, Ileana Dumitrescu wrote: > Hi Kirill, > > On 02/11/2024 09:17, Kirill Makurin wrote: >> The encountered bugs are as follows: >> >> 1. When libtool is used with MSVC tools, libtool's link step >> mishandles compiler flags like`-Wl` and `-Xlinker`. For example, `- >> Wl,- def:FILENAME` becomes plain `-def:FILENAME` when libtool invokes >> the compiler*. (as seen in make-msvc.txt) This part of the bug report has a patch applied [1] in the development branch now, which should migrate to master after some more time. MSVC building and testing has greatly improved, so I will hopefully get another stable release with these fixes out in a couple months. [1]https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?h=3Ddevelopme= nt&id=3D4ded381a6f09cb761a05403450b5e34fec945f5a -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 --_000_DM4PR84MB13732B2989BE083B37B1EB60B16FADM4PR84MB1373NAMP_ 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);"> Hi Ileana,</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);"> The fix seems incomplete.</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);"> 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.</di= v> <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);"> Do you think checking compiler's name is a good idea? AFAIK, all three of c= l.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.</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);"> Maybe libtool could check during configuration whether compiler d= efines this macro to decide how to pass linker flags? Since `compile` wrapp= er should usually be involved, we need to just pass -Wl flags and friends a= s is, `compile` takes care of them.</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);"> There is one problematic case though. If we would use clang.exe installed w= ith Visual Studio, this will not work. It defines _MSC_VER, but it usus gcc= -like command line options.</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 class=3D"elementToProof" style=3D"font-family: Calibri, Arial, Helveti= ca, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <b>From:</b> Ileana Dumitrescu<br> <b>Sent:</b> Friday, May 30, 2025 2:24 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 class=3D"elementToProof" style=3D"font-size: 11pt;">On 13/11/2024 21:5= 9, Ileana Dumitrescu wrote:<br> > Hi Kirill,<br> ><br> > On 02/11/2024 09:17, Kirill Makurin wrote:<br> >> The encountered bugs are as follows:<br> >><br> >> 1. When libtool is used with MSVC tools, libtool's link step<br> >> mishandles compiler flags like`-Wl` and `-Xlinker`. For example, `= -<br> >> Wl,- def:FILENAME` becomes plain `-def:FILENAME` when libtool invo= kes<br> >> the compiler*. (as seen in make-msvc.txt)<br> <br> This part of the bug report has a patch applied [1] in the development<br> branch now, which should migrate to master after some more time. MSVC<br> building and testing has greatly improved, so I will hopefully get<br> another stable release with these fixes out in a couple months.<br> <br> [1]https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?h=3Ddevelopme= nt&id=3D4ded381a6f09cb761a05403450b5e34fec945f5a<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_DM4PR84MB13732B2989BE083B37B1EB60B16FADM4PR84MB1373NAMP_-- --_004_DM4PR84MB13732B2989BE083B37B1EB60B16FADM4PR84MB1373NAMP_ Content-Type: text/plain; name="cmd.txt" Content-Description: cmd.txt Content-Disposition: attachment; filename="cmd.txt"; size=2077; creation-date="Thu, 05 Jun 2025 09:45:26 GMT"; modification-date="Thu, 05 Jun 2025 09:47:24 GMT" Content-Transfer-Encoding: base64 L2Jpbi9zaCAuL2xpYnRvb2wgIC0tdGFnPUNDICAgLS1tb2RlPWxpbmsgL2kvbGlidG9vbC1tc3Zj LWJ1Zy0wL2J1aWxkLWF1eC9jb21waWxlIGNsYW5nLWNsLmV4ZSAtbm9sb2dvIC1PMiAtTUQgLW5v LXVuZGVmaW5lZCAtYXZvaWQtdmVyc2lvbiAtV2wsLWRlZjpsaWJ0b29sLW1zdmMtYnVnLmRlZiAg LW8gbGlibHQtbXN2Yy1idWcubGEgLXJwYXRoIC91c3IvbGliIHNyYy5sbwpsaWJ0b29sOiBsaW5r OiBsbHZtLW5tLmV4ZSAgLmxpYnMvc3JjLm9iaiAgIHwgL3Vzci9iaW4vc2VkIC1uIC1lICdzL14u KlsgICAgICAgICBdXChbQUJDREdJUlNUV11bQUJDREdJUlNUV10qXClbICAgICAgICAgXVsgICAg ICBdKlwoW19BLVphLXpdW19BLVphLXowLTldKlwpJC9cMSBcMiBcMi9wJyB8IC91c3IvYmluL3Nl ZCAnLyBfX2dudV9sdG8vZCcgfCAvdXNyL2Jpbi9zZWQgLWUgJy9eW0JDREdSU11bIF0vcy8uKlsg XVwoW14gXSpcKS9cMSxEQVRBLycgfCAvdXNyL2Jpbi9zZWQgLWUgJy9eW0FJVFddWyBdL3MvLipb IF0vLycgfCBzb3J0IHwgdW5pcSA+IC5saWJzL2x0LW1zdmMtYnVnLmV4cHN5bQpsaWJ0b29sOiBs aW5rOiBpZiB0ZXN0IERFRiA9ICJgL3Vzci9iaW4vc2VkIC1uIC1lICdzL15bICBdKi8vJyAtZSAn L15cKDsuKlwpKiQvZCcgLWUgJ3MvXlwoRVhQT1JUU1x8TElCUkFSWVwpXChbICAgICAgICAgXS4q XCkqJC9ERUYvcCcgLWUgcSAubGlicy9sdC1tc3ZjLWJ1Zy5leHBzeW1gIiA7IHRoZW4gY3AgIi5s aWJzL2x0LW1zdmMtYnVnLmV4cHN5bSIgIi5saWJzL2x0LW1zdmMtYnVnLmRsbC5kZWYiOyBlY2hv ICIubGlicy9sdC1tc3ZjLWJ1Zy5kbGwuZGVmIiA+ICIubGlicy9sdC1tc3ZjLWJ1Zy5kbGwuZXhw c3ltIjsgZWxzZSAvdXNyL2Jpbi9zZWQgLWUgJ3MvXi8tbGluayAtRVhQT1JUOi8nIDwgLmxpYnMv bHQtbXN2Yy1idWcuZXhwc3ltID4gLmxpYnMvbHQtbXN2Yy1idWcuZGxsLmV4cHN5bTsgZmkKbGli dG9vbDogbGluazogIGlmIHRlc3QgLXogIi1kZWY6bGlidG9vbC1tc3ZjLWJ1Zy5kZWYsIjsgdGhl biAvaS9saWJ0b29sLW1zdmMtYnVnLTAvYnVpbGQtYXV4L2NvbXBpbGUgY2xhbmctY2wuZXhlIC1u b2xvZ28gLUZlLmxpYnMvbHQtbXN2Yy1idWcuZGxsICAubGlicy9zcmMub2JqICAgLU8yIC1kZWY6 bGlidG9vbC1tc3ZjLWJ1Zy5kZWYgICAgIkAubGlicy9sdC1tc3ZjLWJ1Zy5kbGwuZXhwc3ltIiAt V2wsLURMTCwtSU1QTElCOiIubGlicy9sdC1tc3ZjLWJ1Zy5kbGwubGliIjsgZWxzZSAvaS9saWJ0 b29sLW1zdmMtYnVnLTAvYnVpbGQtYXV4L2NvbXBpbGUgY2xhbmctY2wuZXhlIC1ub2xvZ28gLUZl LmxpYnMvbHQtbXN2Yy1idWcuZGxsICAubGlicy9zcmMub2JqICAgLU8yIC1kZWY6bGlidG9vbC1t c3ZjLWJ1Zy5kZWYgICAgIkAubGlicy9sdC1tc3ZjLWJ1Zy5kbGwuZXhwc3ltIiAtV2wsLWRlZjps aWJ0b29sLW1zdmMtYnVnLmRlZiwtRExMLC1JTVBMSUI6Ii5saWJzL2x0LW1zdmMtYnVnLmRsbC5s aWIiOyBmaQpjbGFuZy1jbDogd2FybmluZzogdW5rbm93biBhcmd1bWVudCBpZ25vcmVkIGluIGNs YW5nLWNsOiAnLWRlZjpsaWJ0b29sLW1zdmMtYnVnLmRlZicgWy1XdW5rbm93bi1hcmd1bWVudF0K ICAgQ3JlYXRpbmcgbGlicmFyeSAubGlicy9sdC1tc3ZjLWJ1Zy5kbGwubGliIGFuZCBvYmplY3Qg LmxpYnMvbHQtbXN2Yy1idWcuZGxsLmV4cApsdC1tc3ZjLWJ1Zy5kbGwuZXhwIDogd2FybmluZyBM Tks0MDcwOiAvT1VUOmxpYmx0LW1zdmMtYnVnLmRsbCBkaXJlY3RpdmUgaW4gLkVYUCBkaWZmZXJz IGZyb20gb3V0cHV0IGZpbGVuYW1lICcubGlic1xsdC1tc3ZjLWJ1Zy5kbGwnOyBpZ25vcmluZyBk aXJlY3RpdmUKbGlidG9vbDogbGluazogIGxpbmtuYW1lcz0KbGlidG9vbDogbGluazogbGx2bS1h ci5leGUgY3IgLmxpYnMvbHQtbXN2Yy1idWcubGliICBzcmMub2JqCmxpYnRvb2w6IGxpbms6IHJh bmxpYiAubGlicy9sdC1tc3ZjLWJ1Zy5saWIKbGlidG9vbDogbGluazogKCBjZCAiLmxpYnMiICYm IHJtIC1mICJsaWJsdC1tc3ZjLWJ1Zy5sYSIgJiYgY3AgLXBSICIuLi9saWJsdC1tc3ZjLWJ1Zy5s YSIgImxpYmx0LW1zdmMtYnVnLmxhIiApCg== --_004_DM4PR84MB13732B2989BE083B37B1EB60B16FADM4PR84MB1373NAMP_--