Re: Archive Members as Targets

[Henrik Carlqvist]

On Tue, 10 May 2022 22:05:22 -0400
Dmitry Goncharov  wrote:

> > But not on the Linux boxes there make always rebuild everything. On all
> > machines I am using GNU Make.
> ...
> > Can anyone confirm that?
> 
> i can confirm that for me on linux the latest make from git as well as
> make-4.3 correctly detect that libfoo.a is up to date.

I can confirm that it works fine also on Slackware Linux 14.2 using make
version 4.1:

nazgul:/tmp> make
cc-c -o foo.o foo.c
ar cr libfoo.a foo.o
ranlib libfoo.a
rm foo.o
nazgul:/tmp> make
make: Nothing to be done for 'all'.
nazgul:/tmp> make --version
GNU Make 4.1
Built for x86_64-slackware-linux-gnu
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
nazgul:/tmp> cat /etc/slackware-version
Slackware 14.2

regards Henrik

Re: Archive Members as Targets

[Dmitry Goncharov]

On Tue, May 10, 2022 at 5:12 PM Michael Lehn  wrote:
> But not on the Linux boxes there make always rebuild everything. On all 
> machines I am using GNU Make.
...
> Can anyone confirm that?

i can confirm that for me on linux the latest make from git as well as
make-4.3 correctly detect that libfoo.a is up to date.
What version of make do you use?

> (or tell me what obvious stupid mistake I have done …?)

you don't really need ranlib any longer.

regards, Dmitry

Archive Members as Targets

[Michael Lehn]

I have a problem with GNU make when using [Archive Members as 
Targets](https://www.gnu.org/software/make/manual/html_node/Archive-Members.html#Archive-Members).
 The problem is that on some machines (e.g. running MacOS, Solaris) it works 
fine, i.e. builds the library and the next `make` gives `Nothing to be done for 
'all'`. 

But not on the Linux boxes there make always rebuild everything. On all 
machines I am using GNU Make.

Here the example with one source file `foo.c` and the `Makefile`


foo.c
```
void foo() {}
```

Makefile
```
all: libfoo.a

libfoo.a(%.o) : %.o
$(AR) cr $@ $^

libfoo.a: libfoo.a(foo.o)
ranlib libfoo.a
```

Run on Solaris 

```
theon$ make
gcc-c -o foo.o foo.c
ar cr libfoo foo.o
ranlib libfoo
rm foo.o
theon$ make
make: Nothing to be done for 'all'.
```


Run on Linux
```
acker$ make
gcc-c -o foo.o foo.c
ar cr libfoo foo.o
ranlib libfoo
rm foo.o
acker$ make
gcc-c -o foo.o foo.c
ar cr libfoo foo.o
ranlib libfoo
rm foo.o
```


Can anyone confirm that? (or tell me what obvious stupid mistake I have done …?)

Best regards,
Michael

Re: Crash in 'find_and_set_default_shell()'

[Eli Zaretskii]

> From: Paul Smith 
> Date: Tue, 10 May 2022 11:05:40 -0400
> 
> I will say that this does work as expected and doesn't throw an error
> with the latest GNU make Git version, on GNU/Linux.

On MS-Windows, we can barely _emulate_ Posix, so what might, by sheer
luck, work on GNU/Linux, regardless of its being invalid, can
legitimately crash on Windows, which actually assumes the value is
valid.

Re: Crash in 'find_and_set_default_shell()'

[Paul Smith]

On Tue, 2022-05-10 at 15:03 +0200, Gisle Vanem wrote:
> SHELL := env "PATH=$(PATH)" /bin/bash

Well, I dunno.  The problem is that at some point you have to choose
which command to use to invoke something.  The SHELL variable is
intended to contain a shell program that make will exec().  Here you're
saying that either (a) make has to invoke a shell which will invoke the
SHELL command (and how does it choose which shell?  It clearly can't
use the SHELL variable...), or else (b) make has to parse this string
and break it up into words that it can use to call exec() without going
through a shell: normally make leaves this sort of command parsing up
to the shell.

I will say that this does work as expected and doesn't throw an error
with the latest GNU make Git version, on GNU/Linux.

Crash in 'find_and_set_default_shell()'

[Gisle Vanem]

Hello list.

Some resent (?) change has caused a crash in
'find_and_set_default_shell()' with this minimal
Makefile:

export PATH := $(PATH):node_modules/.bin
SHELL := env "PATH=$(PATH)" /bin/bash

all:
   @echo "Hello"

---

Without the 'SHELL ..' line, all is good.
Or even a 'SHELL=/bin/bash' works; no ':='.
Not sure what Gnumake is trying to do here.

The MSVC-2022 built version exits with a
"Security check failure or stack buffer overrun
- code c409" at 'gnumake!__report_gsfailure(void)+0x18'

followed by a bogus call-stack; 185 lines of
junk.

I discovered this while trying to build this
project:
  https://github.com/Financial-Times/n-fetch

But I'm not sure if the above shell syntax should
work on Windows or not. And I use 32-bit Cygwin
as my POSIX toolbox.

--
--gv