bug#78410: Patch for tiny improve cl wrapper script
Kirill Makurin <[email protected]> Fri, 16 May 2025 03:18:36 +0000
| Newsgroups | gmane.comp.sysutils.automake.bugs |
|---|---|
| Message-ID | <SJ2PR84MB35380A84117D8936EBE48F2EB193A@SJ2PR84MB3538.NAMPRD84.PROD.OUTLOOK.COM> |
--_000_SJ2PR84MB35380A84117D8936EBE48F2EB193ASJ2PR84MB3538NAMP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Karl, I see you're somewhat confused about changes proposed by Yang Kun. Let me a= dd some context here. "cl" (cl.exe) is Microsoft's C/C++ compiler, sometimes referred as MSVC. One thing to keep in mind about cl.exe is that it does not understand commo= n flags like `-L`, ` -l`, `-Wl` or combination of `-c -o`, so the `compile`= script is used to emulate them. It also handles conversion between unix- a= nd windows-style filenames (e.g. when building from Cygwin environment). On Windows, unlike other platforms such as Linux, you do not link directly = against the shared library (*.so, or in case of Windows *.dll), but against= import libraries. The thing is that naming conventions used to name libraries on Windows diff= ers depending on toolchain and build system used to produce them. Note that= you can use libraries produced using one toolchain with another (at least = with C libraries). Libtool uses the following naming convention for theoretical library libNAM= E: - With (mingw's) gcc/clang, static library would be named libNAME.a and imp= ort library would be named libNAME.dll.a. - With MSVC-like tools (e.g. cl.exe and clang-cl.exe) static library would = be named NAME.lib and import library would be named NAME.dll.lib. Note how with MSVC `lib` prefix is omitted and `.lib` extension is used ins= tead of `.a` (which is common everywhere but Windows). However, other build system, like cmake and meson, (by default) use differe= nt naming convention for import libraries: NAME.lib (which overlaps with Li= btool's name for MSVC's static libraries). The proposed patch makes `compile` wrapper search for import libraries prod= uces with (mingw's) gcc/clang, in addition to import libraries produces wit= h MSVC-like (cl.exe) tools. IMO, the proposed change is good. The only comment I can make is that I wou= ld prefer looking for libraries produced with gcc/clang after looking for l= ibraries produces with MSVC-like tools. I actually would like to propose adding one more entry to the search path: = `$dir/lib$lib.lib`, which should follow `$dir/$lib.lib`. I am not sure if t= his name is widely used, however, Microsoft documentation uses such names i= n examples related to creation of static libraries. I hope this information helps. - Kirill Makurin ________________________________ From: [email protected] <bug-automake-= [email protected]> on behalf of Karl Berry <karl@fr= eefriends.org> Sent: Friday, May 16, 2025 5:07 AM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <784= [email protected]> Subject: bug#78410: Patch for tiny improve cl wrapper script Hi Nick, Yang, IFS=3D$' \t\n' is a bashism which is not supported in most other shells= . The original code is portable. This seems to have nothing to do with the rest of your change, so why change it at all? Indeed, I was going to make the same comment. I won't be installing that part of the patch. The functional part of the change, to check for $lib.dll.a files after $lib.dll.lib files, seems fine (harmless at least) on the face of it, but Yang, I don't understand your comment: > I think we'd better also search for lib$lib.dll.a even it's a odd > behavior to search lib$lib.a for cl. What is "cl"? "Command line"? Doesn't make sense to me. > However I don't know if that's ok because it doesn't seem to be > useful. If it's not useful then why did you take the time to propose the change? Does anyone/anything actually use .dll.a files? Search engines have very few, though not zero, results for me. --thanks, karl. --_000_SJ2PR84MB35380A84117D8936EBE48F2EB193ASJ2PR84MB3538NAMP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <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 Karl,</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 see you're somewhat confused about changes proposed by Yang Kun. Let me a= dd some context here.</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"text-align: left; text-indent: 0px; = margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, C= alibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> "cl" (cl.exe) is Microsoft's C/C++ compiler, sometimes referred a= s MSVC.<br> <br> </div> <div class=3D"elementToProof" style=3D"text-align: left; text-indent: 0px; = margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, C= alibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> One thing to keep in mind about cl.exe is that it does not understand commo= n flags like `-L`, ` -l`, `-Wl` or combination of `-c -o`, so the `compile`= script is used to emulate them. It also handles conversion between unix- a= nd windows-style filenames (e.g. when building from Cygwin environment).</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);"> On Windows, unlike other platforms such as Linux, you do not link directly = against the shared library (*.so, or in case of Windows *.dll), but against= import libraries.</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 thing is that naming conventions used to name libraries on Windows diff= ers depending on toolchain and build system used to produce them. Note that= you can use libraries produced using one toolchain with another (at least = with C libraries).</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);"> Libtool uses the following naming convention for theoretical library libNAM= E:</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);"> - With (mingw's) gcc/clang, static library would be named libNAME.a and imp= ort library would be named libNAME.dll.a.</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);"> - With MSVC-like tools (e.g. cl.exe and clang-cl.exe) static library would = be named NAME.lib and import library would be named NAME.dll.lib.</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);"> Note how with MSVC `lib` prefix is omitted and `.lib` extension is used ins= tead of `.a` (which is common everywhere but Windows).</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);"> However, other build system, like cmake and meson, (by default) use differe= nt naming convention for import libraries: NAME.lib (which overlaps with Li= btool's name for MSVC's static libraries).</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 proposed patch makes `compile` wrapper search for import libraries prod= uces with (mingw's) gcc/clang, in addition to import libraries produces wit= h MSVC-like (cl.exe) tools.</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);"> IMO, the proposed change is good. The only comment I can make is that I wou= ld prefer looking for libraries produced with gcc/clang after looking for l= ibraries produces with MSVC-like tools.</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 actually would like to propose adding one more entry to the search path: = `$dir/lib$lib.lib`, which should follow `$dir/$lib.lib`. I am not sure if t= his name is widely used, however, Microsoft documentation uses such names i= n examples related to creation of static libraries. </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 hope this information helps.</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> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> bug-automake-bounces+= [email protected] <bug-automake-bounces+maiddaisuki=3Dou= [email protected]> on behalf of Karl Berry <[email protected]><= br> <b>Sent:</b> Friday, May 16, 2025 5:07 AM<br> <b>To:</b> [email protected] <[email protected]><br> <b>Cc:</b> [email protected] <[email protected]>; 78410@debbugs= .gnu.org <[email protected]><br> <b>Subject:</b> bug#78410: Patch for tiny improve cl wrapper script</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;= "> <div class=3D"PlainText">Hi Nick, Yang,<br> <br> IFS=3D$' \t\n' is a bashism which is not supported in mo= st other shells.<br> The original code is portable. This seems to have = nothing to do with<br> the rest of your change, so why change it at all?<br> <br> Indeed, I was going to make the same comment. I won't be installing that<br= > part of the patch.<br> <br> The functional part of the change, to check for $lib.dll.a files after<br> $lib.dll.lib files, seems fine (harmless at least) on the face of it,<br> but Yang, I don't understand your comment:<br> <br> > I think we'd better also search for lib$lib.dll.a even it's a odd <br> > behavior to search lib$lib.a for cl. <br> <br> What is "cl"? "Command line"? Doesn't make sense to me.= <br> <br> > However I don't know if that's ok because it doesn't seem to be<br> > useful.<br> <br> If it's not useful then why did you take the time to propose the change?<br= > Does anyone/anything actually use .dll.a files? Search engines have very<br= > few, though not zero, results for me. --thanks, karl.<br> <br> <br> <br> </div> </span></font></div> </body> </html> --_000_SJ2PR84MB35380A84117D8936EBE48F2EB193ASJ2PR84MB3538NAMP_--