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

Previous Next

To reply to this bug, email your comments to 78410 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Yang Kun <ikspress <at> outlook.com>
To: bug-automake <at> gnu.org
Subject: Patch for tiny improve cl wrapper script
Date: Tue, 13 May 2025 23:05:54 +0800

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

Greetings

I found some possible improvements of compile script in lib/ when I use it.

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. However I don't know if that's ok 
because it doesn't seem to be useful.

Best Regards,

Yang Kun

[0001-compile-improve-script.patch (text/plain, attachment)]

Message #8 received at 78410 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: Yang Kun <ikspress <at> outlook.com>
Cc: 78410 <at> debbugs.gnu.org
Subject: Re: bug#78410: Patch for tiny improve cl wrapper script
Date: Thu, 15 May 2025 13:45:16 -0400

On Tue, May 13, 2025 at 11:05:54PM +0800, Yang Kun wrote:
[...]
> diff --git a/lib/compile b/lib/compile
> index c404e89..a2afc93 100755
> --- a/lib/compile
> +++ b/lib/compile
> @@ -28,12 +28,8 @@ scriptversion=2025-02-03.05; # UTC
>  # bugs to <bug-automake <at> gnu.org> or send patches to
>  # <automake-patches <at> gnu.org>.
>  
> -nl='
> -'
> -
> -# We need space, tab and new line, in precisely that order.  Quoting is
> -# there to prevent tools from complaining about whitespace usage.
> -IFS=" ""	$nl"
> +# We need space, tab and new line, in precisely that order.
> +IFS=$' \t\n'

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?

Cheers,
  Nick

Message #11 received at 78410 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: nbowler <at> draconx.ca
Cc: ikspress <at> outlook.com, 78410 <at> debbugs.gnu.org
Subject: Re: bug#78410: Patch for tiny improve cl wrapper script
Date: Thu, 15 May 2025 14:07:39 -0600

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 #14 received at 78410 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: Karl Berry <karl <at> freefriends.org>
Cc: ikspress <at> outlook.com, 78410 <at> debbugs.gnu.org
Subject: Re: bug#78410: Patch for tiny improve cl wrapper script
Date: Thu, 15 May 2025 19:30:29 -0400

On Thu, May 15, 2025 at 02:07:39PM -0600, Karl Berry wrote:
> > 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.

"cl" is Microsoft's C compiler.

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

I think libfoo.dll.a would be an import library (a detail of using
shared libraries on Windows) created by a MinGW build environment.

So perhaps this sort of thing will help when a project is being built
with Microsoft tools but depends on a shared library built with MinGW?
But I'm certainly no expert in this area so it would be good to know
what's actually being solved.

Cheers,
  Nick

Message #17 received at 78410 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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)]

Message #20 received at 78410 <at> debbugs.gnu.org (full text, mbox):

From: Yang Kun <ikspress <at> outlook.com>
To: Nick Bowler <nbowler <at> draconx.ca>, Karl Berry <karl <at> freefriends.org>
Cc: 78410 <at> debbugs.gnu.org
Subject: Re: bug#78410: Patch for tiny improve cl wrapper script
Date: Fri, 16 May 2025 16:52:11 +0800

> 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?
Oops, sorry, I didn't noticed that.
>> 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.
> I think libfoo.dll.a would be an import library (a detail of using
> shared libraries on Windows) created by a MinGW build environment.

Oh, I've just write it without a second thought. I just think also find 
.dll.a would be useful when the scripts finds
.a. However, I realised that find .a may useful for some rare cases but 
.dll.a not. For example, I'm trying to compile
libiconv now. The Makefile generates libicrt.a instead of icrt.lib 
(actually it is a static library generated by MSVC)
which used by iconv.exe but not install to system.

$ ls ./srclib/*.a
./srclib/libicrt.a

So I think my changes are bad.

Please just ignore it, I made some mistakes. Sorry for the bother.

Best Regards,

Yang Kun

Message #25 received at 78410-done <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: 78410-done <at> debbugs.gnu.org
Subject: Re: bug#78410: Patch for tiny improve cl wrapper script
Date: Fri, 16 May 2025 15:57:12 -0600

Previous Next

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