GNU bug report logs - #78410
Patch for tiny improve cl wrapper script

Previous Next

Full log

View this message in rfc822 format

From: Kirill Makurin <maiddaisuki <at> outlook.com>
To: Karl Berry <karl <at> freefriends.org>, "78410 <at> debbugs.gnu.org" <78410 <at> debbugs.gnu.org>
Subject: bug#78410: Patch for tiny improve cl wrapper script
Date: Fri, 16 May 2025 03:18:36 +0000

[Message part 1 (text/plain, inline)]

Hi Karl,

I see you're somewhat confused about changes proposed by Yang Kun. Let me add 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 common 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- and 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 differs 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 libNAME:

- With (mingw's) gcc/clang, static library would be named libNAME.a and import 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 instead of `.a` (which is common everywhere but Windows).

However, other build system, like cmake and meson, (by default) use different naming convention for import libraries: NAME.lib (which overlaps with Libtool's name for MSVC's static libraries).

The proposed patch makes `compile` wrapper search for import libraries produces with (mingw's) gcc/clang, in addition to import libraries produces with MSVC-like (cl.exe) tools.

IMO, the proposed change is good. The only comment I can make is that I would prefer looking for libraries produced with gcc/clang after looking for libraries 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 this name is widely used, however, Microsoft documentation uses such names in examples related to creation of static libraries.

I hope this information helps.

- Kirill Makurin
________________________________
From: bug-automake-bounces+maiddaisuki=outlook.com <at> gnu.org <bug-automake-bounces+maiddaisuki=outlook.com <at> gnu.org> on behalf of Karl Berry <karl <at> freefriends.org>
Sent: Friday, May 16, 2025 5:07 AM
To: nbowler <at> draconx.ca <nbowler <at> draconx.ca>
Cc: ikspress <at> outlook.com <ikspress <at> outlook.com>; 78410 <at> debbugs.gnu.org <78410 <at> debbugs.gnu.org>
Subject: bug#78410: Patch for tiny improve cl wrapper script

Hi Nick, Yang,

    IFS=$' \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.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.