Phony targets not being made

[christian]

Hi

I have the following makefile
--
PHON1 := rr1 rr2
PHON2 := rr1-sim

.PHONY: all $(PHON1)
# remove below line to get rr1-sim done
.PHONY: $(PHON2)

all: $(PHON1) $(PHON2)
@echo all done

%-sim: %
@echo doing $@

$(PHON1):
@echo doing $@
--
The command 'make' gives the output
doing rr1
doing rr2
all done
Thus rr1-sim is not done.
The command 'make rr1-sim' gives the output
make: Nothing to be done for 'rr1-sim'.
Removing the phony declaration of rr1-sim makes things work as I expect.
'make' gives the output
doing rr1
doing rr2
doing rr1-sim
all done

Is this a bug or is there anything wrong in the Makefile?

Regards
Christian Paulsen

[bug #25412] mingw32-make crashes when double quotes at end of PATH

[Christian Ehrlicher]

URL:
  

 Summary: mingw32-make crashes when double quotes at end of
PATH
 Project: make
Submitted by: chehrlic
Submitted on: Mo 26 Jan 2009 17:16:10 GMT
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: MS Windows
   Fixed Release: None

___

Details:

When my PATH env vars ends with a double quote, mingw32-make crashes:
mingw32-make: Interrupt/Exception caught (code = 0xc005, addr =
0x41f96e)

As soon as I remove the double quote all works fine:

---8<--

D:\kde\kde-mingw\tmp\qt-4.4.2.20080924\work\qt-win-opensource-src-mingw>set
PATH="d:\kde\kde-mingw\mingw\bin"

D:\kde\kde-mingw\tmp\qt-4.4.2.20080924\work\qt-win-opensource-src-mingw>mingw32-
make
cd src\winmain\ && mingw32-make -f Makefile
mingw32-make: Interrupt/Exception caught (code = 0xc005, addr =
0x41f96e)

D:\kde\kde-mingw\tmp\qt-4.4.2.20080924\work\qt-win-opensource-src-mingw>set
PATH=d:\kde\kde-mingw\mingw\bin

D:\kde\kde-mingw\tmp\qt-4.4.2.20080924\work\qt-win-opensource-src-mingw>mingw32-
make
cd src\winmain\ && mingw32-make -f Makefile
mingw32-make[1]: Entering directory
`D:/kde/kde-mingw/tmp/qt-4.4.2.20080924/work
/qt-win-opensource-src-mingw/src/winmain'
mingw32-make -f Makefile.Release
mingw32-make[2]: Entering directory
`D:/kde/kde-mingw/tmp/qt-4.4.2.20080924/work
/qt-win-opensource-src-mingw/src/winmain'
mingw32-make[2]: Nothing to be done for `first'.
mingw32-make[2]: Leaving directory
`D:/kde/kde-mingw/tmp/qt-4.4.2.20080924/work/
qt-win-opensource-src-mingw/src/winmain'
mingw32-make[1]: Leaving directory
`D:/kde/kde-mingw/tmp/qt-4.4.2.20080924/work/
qt-win-opensource-src-mingw/src/winmain'
cd src\tools\moc\ && mingw32-make -f Makefile




___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #26864] make -j2 fails to rebuild intermediate file

[Christian Häggström]

Follow-up Comment #3, bug #26864 (project make):

I have noticed the same thing, it seems to fix itself with the following pa

(file #18949)
___

Additional Item Attachment:

File name: make.patch Size:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #29074] -include target fails to issue Error in 3.81

[Christian Hujer]

Follow-up Comment #5, bug #29074 (project make):

I agree with Hack Lee.

There was a bug before 3.81.

You wouldn't want make to fall over on an
-include $(sources:%.c=%.d)
in the Makefile because of a source error when you're actually running
make clean

The behavior of GNUmake 3.81 is correct.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40227] Various fixes for MSVC build of 4.0

[Christian Boos]

URL:
  

 Summary: Various fixes for MSVC build of 4.0
 Project: make
Submitted by: cboos
Submitted on: Wed 09 Oct 2013 11:42:35 PM GMT
Severity: 3 - Normal
  Item Group: Build/Install
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.0
Operating System: MS Windows
   Fixed Release: None
   Triage Status: None

___

Details:

Following the announcement, I did a checkout and attempted
to build make from the 4.0 tag, using the MSVC compilers
on Windows.

As I build preferentially from a bash shell, I tried
the "nmake -f NMakefile" way still described in the
README.W32.template file.

Unfortunately, the NMakefile.template was not complete.
This is fixed in 0001-Fix-MSVC-build-using-the-NMakefile.patch.

Second issue was detected at runtime, I had some crashes 
happening in _vsnprintf. Looking at the code in output.c
it seemed that with the MSVC compiler _vsnprintf was not
supposed to be called as there's a msc_vsnprintf 
replacement function. However the macro was called snprintf...
This is fixed in
0002-Fix-typo-preventing-the-msc_vsnprintf-function-to-be.patch.

Last fix, which is more a suggestion than a fix, consists
of increasing the default stack size, which proved to be
insufficient for me with a x64 build (the x86 version was
doing fine, so I suppose that the stack grows faster in the
x64 case). 
See 0003-For-MSVC-build-augment-the-stack-size.patch.

With these patches (plus the fix I submitted separately in 
#40226), make 4.0 seems to work like a charm on Windows
(tested with a big build started with '-j6 -Otarget' using 
make.exes built with MSVC8, MSVC9, MSVC10 and MSVC11, 
x64 builds).

I no longer have earlier versions of MSVC, so I don't know
if /STACK was OK there or not (I suppose it's OK). 
Btw, some of the options used (/YX) are no longer valid, 
others are deprecated (/GX). This results in annoying 
warnings. Should I follow-up with a patch for removing them, 
or is having these options still valued? (presumably they're
needed for older MSVC compilers).




___

File Attachments:


---
Date: Wed 09 Oct 2013 11:42:35 PM GMT  Name:
0001-Fix-test-detecting-when-a-stringlist-must-grow-in-de.patch  Size: 1kB  
By: cboos


---
Date: Wed 09 Oct 2013 11:42:35 PM GMT  Name:
0002-Fix-typo-preventing-the-msc_vsnprintf-function-to-be.patch  Size: 690B  
By: cboos


---
Date: Wed 09 Oct 2013 11:42:35 PM GMT  Name:
0003-For-MSVC-build-augment-the-stack-size.patch  Size: 1kB   By: cboos



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40227] Various fixes for MSVC build of 4.0

[Christian Boos]

Additional Item Attachment, bug #40227 (project make):

File name: 0001-Fix-MSVC-build-using-the-NMakefile.patch Size:1 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

[Christian Boos]

Follow-up Comment #1, bug #40226 (project make):

Second thought... I see now where the bug is coming from.

Some use cases for the stringlist imply it's handled as a null-terminated
array:


  for (pp=output_sync_option->list; *pp; ++pp)


Some others iterate up to idx:


  for (idx = 1; idx < sync_mutex->idx; idx++)


For the second example, the list is initialized like this:


  sync_mutex->list = xmalloc (sizeof (char *));
  sync_mutex->list[0] = xstrdup (hdl_string);
  sync_mutex->idx = 1;
  sync_mutex->max = 1;


(copy/paste from the jobserver_fds code?)

The problem is that decode_switches() assumes the first use case, but when
sync_mutex ends up there, the fact that idx == max prevents the list to expand
as the (sl->idx == sl->max - 1) 
condition is never met.

So how to fix this best? For consistency, perhaps always ensure
such a "list" null-terminated, and fix the initialization.
That would also be in accordance with the struct stringlist
comments. But there's also a simpler fix which would be to
change the expansion check from (sl->idx == sl->max - 1) to
(sl->idx >= sl->max - 1) so that it would also work for the
case when they're both set to 1.

Both solutions tested with success.


(file #29345)
___

Additional Item Attachment:

File name: 0001-Fix-initialization-of-sync_mutex-and-jobserver_fds-o.patch
Size:1 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

[Christian Boos]

Follow-up Comment #3, bug #40226 (project make):

Well, the symptom can even be reproduced without a Makefile...


$ /C/Workspace/src/git/make/WinDebug/make -Otarget -f no-Makefile
make: no-Makefile: No such file or directory
make: *** internal error: multiple --sync-mutex options.  Stop.


The reason for this "multiple --sync-mutex options" problem
can be traced to the memory handling bug I presented earlier.
I'll try to explain better what I saw while I was debugging
this issue.

The initial allocation of the sync_mutex stringlist which 
happens in `prepare_mutex_handle_string ()` (main.c) leads
to the following memory layout at the address pointed to
by `sync_mutex->list`:


   ++
 0 |x.
   ++|
 1 |||
   ++|
 2 | "0xf4" |<---'
   ++


i.e. the blocks returned by the xmalloc and xstrdup
calls happen to be contiguous... So far, so good.

For reasons I didn't bother to check, the program then
enters `decode_switches ()` and one of these
switches is now "--sync-mutex 0xf4" (for example).
When handling this parameter in the `case string:`,
the code first tries to check if the stringlist
is not already allocated (it is), or if the list needs
to be expanded (*that check is wrong*). Here we have
idx == max == 1 for that list, so the expansion check
will wrongly decide all is fine and proceed with the
update code, which will make slot 1 point to "0xf4" 
and *null-terminate the list in the slot 2*.


   ++
 0 |x.
   ++|
 1 |x---.
   ++|  |
 2 |  0 |<---'  |
   ++   v
  "0xf4" (somewhere else in memory)


Now we have the slot 0 pointing to an empty value
(`(char*)0) and slot 1 pointing to "0xf4", and this
is what `decode_output_sync_flags ()` detects and
reports as an error.

Hope my previous comments now make better sense ;-)

(please ignore the first patch file #29339 which was 
wrong; I believe the second patch file #29345 is correct,
as well as the alternative solution presented in comment #2
of changing the test operator from == to >=, in the expansion
check).




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

[Christian Boos]

Follow-up Comment #9, bug #40226 (project make):

Eli, it looks like the problem is triggered as soon 
as you have some output generated during the 
`read_all_makefiles ()` phase, as it causes a call
to `prepare_mutex_handle_string ()`.

And after reading the Makefiles, `main ()` calls 
`decode_env_switches ("MAKEFLAGS")` which in turn
calls `decode_switches ()` and the added flag
`--sync-mutex=0x44` is now present.

So in my example at the top of comment #3, the trigger
was the `perror_with_name ()`  call for the missing 
no-Makefile file.

The problem indeed doesn't happen with simple 
Makefiles where make doesn't generate any output
while reading the Makefiles.

Examples:


$ cat Makefile.bug
$(info Hello)
all:
@echo All done


$ WinDebug/make.exe -f Makefile.bug -Otarget
Hello
make: *** internal error: multiple --sync-mutex options.  Stop.

$ cat Makefile.ok
all:
$(info Hello)
@echo All done
$ WinDebug/make.exe -f Makefile.ok -Otarget
Hello
All done


Of course, you have to be "lucky" and have that particular
memory layout I described in comment #3, i.e. the initial 
xstrdup in `prepare_mutex_handle_string ()` must allocate
the "0x44" string just after the list itself. Otherwise 
the memory overwrite that happens in `decode_switches ()`
is likely to remain asymptomatic. For example, when I launch
make from the debugger, the allocation pattern is different
and all seems fine, I could only figure this out by
attaching the debugger to the process... 

Also, I just noticed that the problem is only reproducible
with 64-bits builds. I figure it might be difficult to 
reproduce with other builds of make (msys, cygwin).

So the bug is likely to remain unnoticed most of the time,
which doesn't mean it's not there ;-)



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

[Christian Boos]

Follow-up Comment #10, bug #40226 (project make):

Actually, this issue can also be reproduced with a x64 build done using MinGW
(from http://mingw-w64.sourceforge.net/).


c:Workspacesrcgitmake>gnumake.exe -f Makefile.bug -Otarget
Hello
gnumake.exe: *** internal error: multiple --sync-mutex options.  Stop.



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40227] Various fixes for MSVC build of 4.0

[Christian Boos]

Follow-up Comment #3, bug #40227 (project make):

Actually, it seems that this output problem also affects
MinGW builds, not just MSVC builds.

The patch 0004-MinGW-also-needs-the-msc_vsnprintf-replacement-for-v.patch 
fixed it for me. 

As I don't have Cygwin I couldn't verify if the WINDOWS32 define 
is also defined there. If it is, the check must be changed to:


#if defined(WINDOWS32) && !defined(__CYGWIN__)



(file #29374)
___

Additional Item Attachment:

File name: 0004-MinGW-also-needs-the-msc_vsnprintf-replacement-for-v.patch
Size:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40227] Various fixes for MSVC build of 4.0

[Christian Boos]

Follow-up Comment #6, bug #40227 (project make):

I found the _vsnprintf_s declaration in my MinGW installation:

.../mingw64/x86_64-w64-mingw32/include/sec_api/stdio_s.h

And this gets included from .
I suppose this must be a relatively recent addition,
as I installed that version today (major.minor is 3.11).

I added a version check to the patch, the numbers can be 
refined to pinpoint the introduction of _vsnprintf_s, if
the approach is found to be valid and no better fix is
found.

Back to the issue itself. Here are a few quick ways to 
reproduce it reliably.

First without a Makefile:


$ ./gnumake64 -f no-Makefile
gnumake64:
gnumake64: ***.  Stop.

$ ./gnumake32 -f no-Makefile
gnumake32: no-Makefile: No such file or directory
gnumake32: *** No rule to make target 'no-Makefile'.  Stop.


or with a minimal Makefile, which I inline here using --eval,
but the effect is the same with a Makefile containing that
single line:


$ ./gnumake64.exe --eval "FORCE:;" FORCE
gnumake64:

$ ./gnumake32.exe --eval "FORCE:;" FORCE
gnumake32: 'FORCE' is up to date.


Updated patch: 0004b-MinGW-also-needs-the-msc_vsnprintf-replacement-for-.patch

(file #29376)
___

Additional Item Attachment:

File name: 0004b-MinGW-also-needs-the-msc_vsnprintf-replacement-for-.patch
Size:1 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40227] Various fixes for MSVC build of 4.0

[Christian Boos]

Follow-up Comment #9, bug #40227 (project make):

> (Btw, what is gnumake32.exe in your case, and how is it
different from gnumake64.exe?)

Sorry if that wasn't clear: gnumake32.exe was built with
the 32-bits toolchain from MinGW-w64, and gnumake64.exe
was built with the 64-bits toolchain from MinGW-w64.
Only the 64-bits build presents this issue, which is
also why you don't see it with the (32-bits, obviously)
build done with the mingw.org toolchain.

>  So we need some other preprocessor symbols.

Right. What about simply _WIN64, as it doesn't seem 
that mingw.org will support that anytime soon?
Moreover I just found out that in MinGW-w64 the support 
for _vsnprintf_s function dates back nearly from the 
beginning of the project, so no need for a version check.

Besides, I tried -D__USE_MINGW_ANSI_STDIO=1 and this was
also enough to fix the issue, indeed! So this is probably
the way to go.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40227] Various fixes for MSVC build of 4.0

[Christian Boos]

Follow-up Comment #10, bug #40227 (project make):

... and I just debugged the make built with the MinGW-w64 
toolchain for x64 and *without* the -D__USE_MINGW_ANSI_STDIO=1
flag, the problem is indeed that vsnprintf returns -1 when the
fmtbuf is not large enough.

Also, I must have forgotten to revert my patch when I built 
the 32-bits version earlier, as now I can also reproduce the
problem with also with make built with the MinGW-w64 x32
toolchain.

Bottom line: the mingw.org toolchain probably enables
the ANSI-like behavior by default, whereas the MinGW-w64
toolchains needs the -D__USE_MINGW_ANSI_STDIO=1 flag
for that.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40227] Various fixes for MSVC build of 4.0

[Christian Boos]

Follow-up Comment #12, bug #40227 (project make):

Yes, that would work, but the #define has to be added
much earlier, as even makeint.h includes stdio.h...

See 0004c-Ask-MinGW-w64-to-use-ANSI-style-vsnprintf.patch


(file #29377)
___

Additional Item Attachment:

File name: 0004c-Ask-MinGW-w64-to-use-ANSI-style-vsnprintf.patch Size:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40227] Various fixes for MSVC build of 4.0

[Christian Boos]

Follow-up Comment #13, bug #40227 (project make):

I tested that patch (file #29377) with the mingw.org 
toolchain (gcc 4.4.0) and make still works after that,
so I think it's safe to apply, provided this doesn't disturb
the cygwin build...

I also looked at mingw.org's mingw32/include/stdio.h and in fact
the __USE_MINGW_ANSI_STDIO flag doesn't select another vsnprintf 
function, as opposed to what happens in MinGW32-w64's stdio.h. 

As they write: "if you want the MSVCRT behaviour, 
you *must* use the Microsoft uglified names."
(i.e. _vsnprintf, as a quick -Dvsnprintf=_vsnprintf confirmed).


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40227] Various fixes for MSVC build of 4.0

[Christian Boos]

Follow-up Comment #15, bug #40227 (project make):

As requested, 3 debugging sessions that recap the whole problem
with vsnprintf for MinGW-w64.

(file #29378)
___

Additional Item Attachment:

File name: gdb-trace-vsnprintf.txtSize:13 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40227] Various fixes for MSVC build of 4.0

[Christian Boos]

Follow-up Comment #18, bug #40227 (project make):

Yep, patch in file #29381 works for me as well
(tested with both x32 and x64 toolchains of
MinGW-w64). Thanks!



Googling shows that lots of projects stumble upon
this issue. MinGW-w64 chose to be compatible with
the behavior of the MS API by default, see
http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/7132/focus=7133
and this different approach is indeed a problem when 
MinGW-w64 is used as a drop in replacement for MinGW32.

They have documented the vsnprintf behavior here:
http://sourceforge.net/apps/trac/mingw-w64/wiki/printf%20and%20scanf%20family

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40227] Various fixes for MSVC build of 4.0

[Christian Boos]

Follow-up Comment #20, bug #40227 (project make):

Thanks for applying!

As for the /STACK patch, the issue I got in my early tries was an exception
with code 0xC0FD (STATUS_STACK_OVERFLOW). Now my problem is that I can't
reproduce it anymore, even with x64 bits and the "default" /STACK.

But googling for "make 0xC0FD" shows quite a lot of such similar issues,
so I'm not (wasn't) alone with this ;-)

In my patch, 0x400 was indeed probably excessive and setting it to
0x40 should be enough as it's 4 times the default. Note that if I *lower*
this value instead (e.g. to 0x8) I can again trigger a crash but this time
with a less informative 0c005 exception code (STATUS_ACCESS_VIOLATION).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

make doesn't complain if target cannot be built

[Christian Eggers]

Hint: There's no file present from which foo.o can be built with implicit 
rules.

Makefile 1:
--snip---
all: foo.o
--EOF---
# make foo.o
make: *** No rule to make target `foo.o'.  Stop.
# echo $?
2

Makefile 2:
--snip---
all: foo.o
foo.o: generated.h
--EOF---
# touch generated.h
# make foo.o
make: Nothing to be done for `foo.o'
# echo $?
0

In Makefile 2 my intention was to state that foo.o depends on some generated 
header which must be generated first (might be in another rule). But I didn't 
want to change the be behaviour if foo.o cannot be built because e.g. there's 
no foo.c.

The example in make's manual, chapter "4.11 Multiple Rules for One Target", 
suffers from the identical problem.



Regarding to the make source code, foo.o ..
- has no cmds.
- is not "phony"
- is a target

remake.c
---snip---
remake_file (struct file *file)
{
  if (file->cmds == 0)
{
  if (file->phony)  

/* Phony target.  Pretend it succeeded.  */ 

file->update_status = us_success;   

  else if (file->is_target) 

/* This is a nonexistent target file we cannot make.

   Pretend it was successfully remade.  */  

--->

---> foo.o matches this case

--->

file->update_status = us_success;   

  else  

{   

  /* This is a dependency file we cannot remake.  Fail.  */ 

  if (!rebuilding_makefiles || !file->dontcare) 

complain (file);
  file->update_status = us_failed;
}
}
  else
---snap---

regards
Christian


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: make doesn't complain if target cannot be built

[Christian Eggers]

Am Montag, 13. Januar 2014, 17:20:43 schrieb Paul Smith:
> On Mon, 2014-01-13 at 22:23 +0100, Christian Eggers wrote:
> > In Makefile 2 my intention was to state that foo.o depends on some
> > generated header which must be generated first (might be in another
> > rule). But I didn't want to change the be behaviour if foo.o cannot be
> > built because e.g. there's no foo.c.
> 
> Unfortunately, this behavior is correct, and even required by the POSIX
> standard (and is implemented by every version of make).
> 
> Once a target is listed in the makefile it becomes "known" to 'make'.
> When make wants to build a target it will try to find an implicit rule
> for it.  However, if there is no implicit rule found it just means that
> there were no commands available for that target, not that the target
> couldn't be built.
> 
> According to the POSIX spec:
> 
> If there are no commands listed for the target, the target shall
> be treated as up-to-date.
> 
> This is actually useful behavior and is definitely taken advantage of in
> real makefiles.
> 

Is there a workaround for this? Using explicit rules seems to be difficult in 
my case because some objects are built from .c sources, other from .cpp.
Is there a better way instead of this:

SOURCES_C := foo.c
SOURCES_CPP := bar.cpp
SOURCES_ASM := ...

OBJS := $(SOURCES_C:%.c=%.o) $(SOURCES_CPP:%.cpp=%.o) ...

$(SOURCES_C:%.c=%.o):
$(COMPILE.c) ...

$(SOURCES_CPP:%.cpp=%.o):
$(COMPILE.cpp) ...

$(OBJS): generated.h

EOF

regards


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: make doesn't complain if target cannot be built

[Christian Eggers]

-Philip Guenther  schrieb: -
>Betreff: Re: make doesn't complain if target cannot be built

> In many cases, I've found it completely unnecessary to
> list the source files.  Just list the objects that should be built and
> provide pattern rules for the source types, then let make figure out which
> source files generate which objects from the patterns, ala:  
>
> OBJS = foo.o bar.o ... 
> 
> %.o: %.c:
> $(COMPILE.c) 
> 
> %.o: %.cpp
> $(COMPILE.cpp) 
>
> ...
> 
> $(OBJS): generated.h   
>
> You only need to match sources
> to objects if there's a naming conflict...which I would tend to solve by
> renaming the file that doesn't belong.   

This is the pattern I normally use. But as I described in my first mail,
the line "$(OBJS): generated.h" does two things:
1. state that foo.o and bar.o depend an generated.h
2. state the foo.o and bar.o are target
The second has the side effect, that make doesn't complain if foo.o cannot
be generated because there no matching implicit rule. A "make foo.o" wouldn't
complain and exit with 0 even if there's no foo.c.

> Side point: you only list an
> explicit dependency for a file named generated.h, which suggests you're using
> some sort of automated dependency technique (gcc -MD, make depend, etc) for
> handling dependency tracking for other .h files.
Yes, I do.

> If that's the case, then it can be slightly better to use an order-only
> prerequisite for the generated file, ala:  
> $(OBJS): | generated.h  
> That guarantees the generated.h file will
> exist before trying to build any objects, but if generated.h gets rebuilt,
> only the objects that have real dependencies from the automated dependency
> tracking setup will get rebuilt.

That makes sense.

>
> Philip Guenther 

regards
Christian


-- 
Registergericht / Register Court: Amtsgericht Traunstein, HRA 460 / Local Court 
Traunstein, registered under HRA 460 
vertreten durch / authorized representative: Anton Kathrein 

This e-mail is confidential and may contain privileged information. If you have 
received this communication in error, please notify us immediately by 
responding to this email and then delete it from your system. The sender 
therefore does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission. We believe but 
do not warrant that this e-mail and any attachments are virus free. You must 
therefore take full responsibility for virus checking. 

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: make doesn't complain if target cannot be built

[Christian Eggers]

Am Dienstag, 14. Januar 2014, 08:12:38 schrieb Paul Smith:
> Can you add the prerequisite to the pattern rules?
> 
>   %.o : %.c generated.h
>   $(COMPILE.c) ...
>   %.o : %.cpp generated.h
>   $(COMPILE.cpp) ...
> 
> This has the definite potential downside that if "generated.h" changes
> then _every_ object file will rebuild, even if they do not use it.  But
> maybe they all use it anyway.

generated.h will only be used by some object files, so this seems to be no 
good way

> Alternatively you could use order-only prerequisites:
> 
>   %.o : %.c | generated.h
>   $(COMPILE.c) ...
>   %.o : %.cpp | generated.h
>   $(COMPILE.cpp) ...
> 
> Now you have the opposite problem: generated.h will be rebuilt BUT none
> the object files will be recompiled (if the only thing that's changed is
> the generated.h file).

I think this issue can be avoided by using automatically generated dependency 
files.

> Really, I'm not sure I see the ultimate problem.  First, it seems that
> you will always need to define header files, etc., so you will already
> have plenty of rules of the form:
> 
> foo.o: bar.h biz.h
> 
> and so this issue already exists.

As I'm using generated dependency files which at least don't exist when make 
is run for the 1st time. So missing sources will be detected. For further 
runs, there will be an explicit dependency for each object file which 
recognizes, whether the source file is missing.

> Second, if all you're worried about is someone adding a bogus file to
> the makefile list of objects, that doesn't seem like a real issue; sure,
> it won't be caught here but the build will still fail (presumably you're
> using that list of objects to construct something else and THAT will not
> work if one of the object files is missing).

Yes, this is catched by the linker. But I think this is not optimal (and not 
what I expect).

> If you really want to catch it early you can just do a specific check to
> make sure all the listed files exist:
> 
> SOURCES := foo.c foo.cpp foo.asm ...
> 
> MISSING := $(filter-out $(wildcard $(SOURCES)),$(SOURCES))
> ifneq (,$(MISSING))
>   $(error Missing files: $(MISSING))
> endif
> 
> It's definitely true that you won't be able to get the traditional make
> error message; I just don't think it's worth the hoops you'll need to
> jump through to make that happen.
> 
> But maybe you have some other requirement.

I've tested your second hint (order-only prerequisites in implicit pattern 
rules) in combination with automatically generated dependency files:

---Makefile---
.PHONY: all clean

OBJS := foo.o bar.o

all: $(OBJS)

$(OBJS): CPPFLAGS += -MMD -MF $(@:%=%.d) -MP -MT $(@:%=%.d) -MT $(@)

%.o: %.c | generated.h
$(COMPILE.c) $(OUTPUT_OPTION) $<

generated.h: generated.x
touch $(@)

clean:
$(RM) $(OBJS) $(OBJS:%=%.d) generated.h

-include $(OBJS:%=%.d)
---EOF---

This avoids $(OBJS) to become a target (unless the dependency files are 
generated). This seems to work correctly for all cases I tested 

If interested, see attached tar archive and run "run_tests.sh".

thanks
Christian



make_missing_implicit.tar.gz
Description: application/compressed-tar
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #41730] Make doesn't show text for error messages when using the Microsoft C runtime

[Christian Boos]

Follow-up Comment #1, bug #41730 (project make):

Duplicate of bug #40227 which is already fixed in git.

You'll soon realize that there are some other issues with stock 4.0 when it's
built with msvc, so better go with the latest in git ;-)

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

GNU make 4.1 features/archives test failure on OpenBSD

[Christian Weisgerber]

When running the GNU make 4.1 regression test suite on OpenBSD 5.6,
the final features/archivers test fails.  This is a problem with the
test.

features/archives ... FAILED (9/10 passed)

--->
*** work/features/archives.base.9   Tue Nov 25 18:53:44 2014
--- work/features/archives.log.9Tue Nov 25 18:53:44 2014
***
*** 1 
- make: Nothing to be done for 'default'.
--- 0 
<---

Here's the respective archives.mk.6 makefile:

--->

DIR = artest
vpath % $(DIR)
default: lib(foo)
(%): %.vhd ; @cd $(DIR) && touch $(*F) && $(AR) $(ARFLAGS) $@ $(*F) >/dev/null 
2>&1 && rm $(*F)
.PHONY: default
<---

It is invoked twice.  The idea is that there should be "nothing to be
done" on the second invokation.

The problem is that OpenBSD's ar(1) (GNU ar 2.15) skips zero-length
files.  E.g.:

$ rm -f foo lib
$ touch foo
$ ar rv lib foo
ar: creating lib
$ ar tv lib
$ 

The other tests succeed because the touch() function from test_driver.pl
actually creates non-zero files.

With a change like the one below, this regression test will pass
just fine on OpenBSD.

--->
--- tests/scripts/features/archives.origSun Oct  5 18:24:51 2014
+++ tests/scripts/features/archives Tue Nov 25 18:40:08 2014
@@ -83,7 +83,7 @@ run_make_test(q!
 DIR = artest
 vpath % $(DIR)
 default: lib(foo)
-(%): %.vhd ; @cd $(DIR) && touch $(*F) && $(AR) $(ARFLAGS) $@ $(*F) >/dev/null 
2>&1 && rm $(*F)
+(%): %.vhd ; @cd $(DIR) && echo foo >$(*F) && $(AR) $(ARFLAGS) $@ $(*F) 
>/dev/null 2>&1 && rm $(*F)
 .PHONY: default
 !,
   '', "");
<---

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #43887] shell function blocks for x64 builds with MSVC compiler

[Christian Boos]

URL:
  

 Summary: shell function blocks for x64 builds with MSVC
compiler
 Project: make
Submitted by: cboos
Submitted on: Thu 25 Dec 2014 05:55:11 PM GMT
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.1
Operating System: MS Windows
   Fixed Release: None
   Triage Status: None

___

Details:

Season's greetings!

I've recently built Make 4.1 using Visual Studio 2012, for the x64 platform
(i.e. a 64-bits build).
The build went well, but using this make.exe for my usual build hanged.
Debugging it, I saw that the hang happened in a $(shell ...) function call,
never returning and stuck in reap_children().

I figured out that the "pid == shell_function_pid" comparison that needs to
succeed for setting the shell_function_completed flag and exiting
reap_children() could actually never succeed:
 - "pid" is obtained from process_wait_for_any() and is actually a pointer,
cast from sub_process* to HANDLE to pid_t
 - "shell_function_pid" got its value from process_init_fd() via
windows32_openpipe(), but here the cast chain is sub_process* to HANDLE to
int!
For that specific compiler/platform combination, pointers and pid_t are
64-bits values, while ints are 32-bits values 

Using pid_t when declaring shell_function_pid fixed the problem. Patch
attached.

I've looked for other potential problems in the code, but all the other
int/pid_t mismatches seem to happen for platforms where it shouldn't be a
problem (EMX, Amiga).

Nearly forgot to say: everything else seems to work like a charm after that!
Thanks!




___

File Attachments:


---
Date: Thu 25 Dec 2014 05:55:11 PM GMT  Name:
0001-Use-correct-pid_t-type-for-shell_function_pid.patch  Size: 1kB   By:
cboos
fix for this issue, on top of 4.1


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #44308] combination of $(call ...) and $(value ...) functions

[Christian Boos]

Follow-up Comment #4, bug #44308 (project make):

Your example reminded me similar constructions I use a lot in my own
Makefiles.

I use a technique which I call the eval/value style which allows me to
generate parametric Make code without having to deal with annoying levels of $
quoting.

Here's how I would write your example:
{{{

code = $(eval $(value code.mk))

define code.mk
x_$1 = some value
y_$1 = $(x_$1) append value
echo-$1: 1 := $1
echo-$1:
@echo x = $(x_$1)
@echo y = $(y_$1)
endef
$(call code,foo)
$(call code,bar)
all: echo-foo echo-bar

}}}

It then works as you expected.

Well, I actually won't recommend the `1 := $1` hack, use rather some
expressive name here ;-)

A better example:
{{{

x_foo = some FOO value
x_bar = some BAR value

code = $(eval $(value code.mk))

define code.mk
y_$1 = $(x_$(param)) append value
echo-$1: param := $1
echo-$1:
@echo x = $(x_$(param))
@echo y = $(y_$(param))
endef

$(call code,foo)
$(call code,bar)
all: echo-bar

}}}

Gives:
{{{
$ make all
x = some FOO value
y = some FOO value append value
x = some BAR value
y = some BAR value append value
}}}

That being said, you have to be extra careful about where you place your
numerical parameters.
If you don't want to rely on the fact that your `$(y_$1)` variable gets only
used within rules where `$(param)` is defined, then you should use an `:=`
assignment (e.g. `y_$1 := $(x_$1) append value`). 


So having a special kind of variable which would expand only the numerical
parameters like Paul suggested would avoid the need to think too hard about
what happens when that code is executed, as the parameters would no longer be
there at this point.

Since these variables would probably only be useful when defining Make code,
it wouldn't be a big limitation to reserve them to multiline variable
definition, something like:

{{{
defmacro code
x_$1 = some value
y_$1 = $(x_$1) append value
echo-$1:
@echo x = $(x_$1)
@echo y = $(y_$1)
endef
$(call code,foo)
$(call code,bar)
all: echo-foo echo-bar
}}}


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #46077] SHELL process handling does not work under Windows 10 in x64 build -> endless waiting

[Christian Boos]

Follow-up Comment #2, bug #46077 (project make):

Eli, I just saw that make-4.1-2-w32-src.zip from your ezwinports doesn't have
that fix. Any chance for a 4.2pre build?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #46077] SHELL process handling does not work under Windows 10 in x64 build -> endless waiting

[Christian Boos]

Follow-up Comment #4, bug #46077 (project make):

Oh right, #43887 was indeed about a 64-bits (msvc) build. 

As sometimes my ez-make-4.1 builds hang with -j, I thought it could be because
of this reason... but it could well be something else. I'll try to have a
closer look by rebuilding 4.1-2 32-bits myself, so that I can debug it when it
happens again. If I find anything I'll create a new issue. Thanks for your
quick reply!

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Nonexistent phony prerequisite

[Christian Weisgerber]

I ran into this surprising behavior (GNU Make 4.2.1):


foo: phony
touch foo

.PHONY: phony


$ gmake
touch foo

A nonexistent prerequisite is ignored if it is marked as phony.
Is this a bug or a strange feature?  A different make(1) implementation
complains:

$ make
make: don't know how to make phony (prerequisite of: foo)

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

make says that file does not exist even if it just built it a few lines before?

[Christian Schuhegger]

hello,

i have a problem with a makefile where make tells me that a file does
not exist even if it just remade it a few lines (in the log file)
earlier. if i do a second make everything works fine?

i am talking about:
GNU Make version 3.77, by Richard Stallman and Roland McGrath.

on redhat linux 6.1.

the relevant lines from the make log are:
Successfully remade target file
`/home/cschuheg/makeproblem/obj/debugobj/libcommondevices/libcommondevices.o'.

... some other output ...

File
`/home/cschuheg/makeproblem/obj/debugobj/libcommondevices/libcommondevices.o'
does not exist.

if i then do the same make command again it builds the project without
problems.

can anybody tell me why this happenes or what i can do to circumvent
this behaviour?

i send a little hellow project with this mail. change into the root of
this project and type
source env.sh
then go into the src directory and type
make all

and the problem should appear. if you type
make all

again the project should build correctly.

this archive also contains a make.log file in the src directory from my
build.

many thanks for any comments!

--
MfG,
Christian Schuhegger


makeproblem.tar.bz2
Description: Binary data

make 3.80 on Ultrix 4.3

[Christian Krackowizer]

Hallo,

I've problems compiling 3.80 on Ultrix 4.3. Compiler is gcc 2.5.3
3.80 built well on Dec OSF 1 3.2C, AIX 4.1.5 and HP-UX 10.20 using the same 
compiler.
If you need further information please let me know

Date: Tue, 8 Jul 2003 13:09:31 +0200
From: System APRIVILEGED Account <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
make[2]: Entering directory `/users/make-3.80'
source='main.c' object='main.o' libtool=no \
depfile='.deps/main.Po' tmpdepfile='.deps/main.TPo' \
depmode=gcc /bin/sh ./config/depcomp \
gcc -DLOCALEDIR=\"/usr/local/share/locale\" -DLIBDIR=\"/usr/local/lib\" 
-DINCLUD
EDIR=\"/usr/local/include\" -DHAVE_CONFIG_H -I. -I. -I.  -I./glob   -g -O2 
-c `t
est -f 'main.c' || echo './'`main.c
main.c: In function `open_tmpfile':
main.c:818: `O_CREAT' undeclared (first use in this function)
main.c:818: (Each undeclared identifier is reported only once
main.c:818: for each function it appears in.)
main.c:818: `O_EXCL' undeclared (first use in this function)
main.c:818: `O_WRONLY' undeclared (first use in this function)
make[2]: *** [main.o] Error 1
make[2]: Leaving directory `/users/make-3.80'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/users/make-3.80'
make: *** [all] Error 2
ds5000:/users/make-3.80 ==>
with best regards

Christian Krackowizer
Schuler Business Solutions GmbH
Jakob-Haringer-Strasse 6
A-5020 Salzburg
Phone: +43(0)662/2282-0
FAX: +43(0)662/2282-9
e-Mail: [EMAIL PROTECTED]


___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make

make check for 3.80

[Christian Krackowizer]

Hi,

I have 1 error in 'make check' on

Ultrix 4.3
*** work/features/parallelism.base.2Wed Jul 16 15:56:35 2003
--- work/features/parallelism.log.2 Wed Jul 16 15:56:35 2003
***
*** 1,7 
- ONE.inc
  THREE.inc
  TWO.inc
  ONE
- THREE
  TWO
  success
--- 1,7 
  THREE.inc
+ ONE.inc
  TWO.inc
  ONE
  TWO
+ THREE
  success
and DEC OSF 3.2C
*** work/functions/eval.baseWed Jul 16 15:15:49 2003
--- work/functions/eval.log Wed Jul 16 15:15:49 2003
***
*** 1,2 
! AA
  BA
--- 1,2 
! A
  BA
with best regards

Christian Krackowizer
Schuler Business Solutions GmbH
Jakob-Haringer-Strasse 6
A-5020 Salzburg
Phone: +43(0)662/2282-0
FAX: +43(0)662/2282-9
e-Mail: [EMAIL PROTECTED]


___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make

[bug #56449] job.c (construct_command_argv_internal): Must use shell if '%' character is present in recipe line

[Christian Eggers]

Follow-up Comment #8, bug #56449 (project make):

[comment #5 comment #5:]
> Sorry, I think there's some confusion.  All this patch does is detect if we
see a % in the command line and if so we do not take the fast path: instead we
take the slow path and invoke command.com.
> 
> So we're not trying to handle environment variables etc., we're just saying
"hey make, if the recipe contains % then give up and pass it to command.com to
take care of".

Yes, that is exactly what I intended to change.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #56449] job.c (construct_command_argv_internal): Must use shell if '%' character is present in recipe line

[Christian Eggers]

Follow-up Comment #9, bug #56449 (project make):

[comment #6 comment #6:]
> But the result is wrong when %..% doesn't specify a known variable, most
probably because we invoke the command through a batch file.

The question may be, which of both results is the correct one. So if cmd.exe
has something like an "interactive" and "batch" mode, I personally would
consider the batch mode as the correct one (I would rather enter all my build
commands into a long batch file than typing everything manually).

So I would expect that recipe lines in make behave equally to the batch
mode...

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #56449] job.c (construct_command_argv_internal): Must use shell if '%' character is present in recipe line

[Christian Eggers]

Follow-up Comment #7, bug #56449 (project make):

Hi, I'm the original author of this bug. It's some time ago I wrote this, so
maybe I've forgotten some details...

[comment #2 comment #2:]
> I see that this bug was fixed and closed, but looking at the result, I'm not
sure the fix is correct.  If I invoke a Windows program from the cmd.exe
prompt with %% as argument, the program gets "%%" as its argv[1], not just a
single %.
> 
> So I guess I don't understand why the OP expected to get a single %
character.  Am I missing something?

I guess that cmd.exe may distinguish between "interactive mode" and "script
mode".
So in interactive mode it will not change double % to a single %. But in
script mode it does. For this moment I have no windows machine, but on
wineconsole I get different output when I 

- type "echo %%" --> I get double %
- insert "echo %%" into a test.cmd file  --> I get single %

I also remember that using *echo* is not a good idea for demonstration with
*make*. As make recognizes echo as a shell builtin it always invokes this via
a shell.
That is the reason why I sent the demo program.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #56449] job.c (construct_command_argv_internal): Must use shell if '%' character is present in recipe line

[Christian Eggers]

Follow-up Comment #12, bug #56449 (project make):

[comment #10 comment #10:]
> GNU Make emulates the behavior of the shell as if the user typed the
commands at the shell's prompt.  It is true that you need to double the %
characters in batch files, but GNU Make doesn't behave like batch files do.
> 
> So I think this change is for the worse, and should be reverted.

Ack. If I remember correctly, the double % were caused by cmake (unfortunately
I cannot verify this in short term). Maybe cmake expects that for MingW
Makefiles it needs to convert a single % into a double one. If this is wrong,
this behavior should changed in cmake.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

output-sync test mistake?

[Christian Weisgerber]

GNU make 4.3

There is some suspicious code in tests/scripts/features/output-sync
that looks like a copy-and-paste error.  Note that changing it also
breaks one of the tests run there because the output order changes.

Is this an actual mistake?  Maybe I should try to understand the
logic of the test...

--- tests/scripts/features/output-sync.orig
+++ tests/scripts/features/output-sync
@@ -59,8 +59,8 @@ $set_bar_start = output_sync_set('bar_start');
 
 $wait_foo = output_sync_wait('foo');
 $wait_bar = output_sync_wait('bar');
-$wait_foo_start = output_sync_set('foo_start');
-$wait_bar_start = output_sync_set('bar_start');
+$wait_foo_start = output_sync_wait('foo_start');
+$wait_bar_start = output_sync_wait('bar_start');
 
 open(MAKEFILE,"> foo/Makefile");
 print MAKEFILE <

output-sync test can fail due to race condition

[Christian Weisgerber]

GNU make 4.3

I have been struggling with test suite failures on OpenBSD/arm64.
Specifically, the output-sync test frequently shows failures.  I
have attached the work directory from such a test run.

After closer examination, I think the failures are due to a race
condition in the test itself.  It has nothing to do with the actual
feature being tested nor with the platform the test is run on.

The issue surfaces in bar/Makefile:

--->
all: bar baz

bar: bar-base ; @#HELPER# -q file ../mksync.bar
bar-base:
@echo bar: start
@echo bar: end

[...]

baz: baz-base
baz-base:
@echo baz: start
@#HELPER# -q wait ../mksync.foo sleep 1
@echo baz: end
<---

When the first two tests have a parallel make descend into the "bar"
directory, they expect a particular execution order:
1. the bar-base recipe
2. the bar recipe
3. the baz-base recipe

However, frequently the order is this:
1. the bar-base recipe
2. the baz-base recipe
3. the bar recipe

baz-base is waiting to be unlocked by mksync.foo, but over in the
"foo" directory a parallel job is waiting for mksync.bar, so if the
bar recipe is scheduled AFTER baz-base, the parallel jobs deadlock
and error out with the observed wait timeouts.

As far as I can tell, make does not promise an inherent execution
order here.  bar can come before or after baz, or the commands of
their respective recipes can be interleaved.  So the test is wrong
and needs additional sequencing.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de


work.tgz
Description: application/gtar-compressed

Suggestion: Modernization of the include path

[Christian Hujer]

Hello everyone,


I suggest that
a) $HOME/.local/include is effectively added to the include_directories, as
if it were inserted in default_include_directories before /usr/gnu/include.
b) Change function src/read.c/eval_makefile() to loop over .INCLUDE_DIRS
instead of include_directories when searching for another Makefile.

Rationale for a):
The $HOME/.local directory tree is a directory tree for user-installed
software established beside /usr and /usr/local.
By supporting $HOME/.local/include as a default include directory, users of
make could share modules by "installing" them into their
$HOME/.local/include directory without needing administrator privileges
(required for installing in /usr/include or /usr/local/include or
/usr/gnu/include), and without appending -I ~/.local/include to each of
their make calls which would be inconvenient.

This feature looks portable:
* The entry $HOME/.local/include can be assumed on all POSIXy systems.
  No harm is done if that directory is part of the include path but doesn't
exist.
  This assumes that the mechanism that scans the include paths for include
files will continue to silently ignore non-existent directories.
* On Windows, there is a corresponding directory, I can create a VM if the
details are needed.
* On Amiga OS, the variable $HOME is optional and usually only set if
something like MuFS or GNU is used in an extended configuration.
  Make could check if $HOME is set and include the entry based on that
condition.

Rationale for b):
INCLUDE_DIRS+=${HOME}/.local/include has no effect and does not print any
error message, which is not friendly towards users of make.
Something should either work, or when it doesn't, it should print an error
message.


Best regards,
-- 
Christian Hujer
CEO/CTO
Nelkinda Software Craft Pvt Ltd
📧 Christian Hujer  | 🐦 @nelkinda
<https://twitter.com/nelkinda> | 🌐 http://nelkinda.com
☏ 🇮🇳 ✆ +91 77 2003 6661 <+917720036661>

Re: Parallel job instance identifiers?

[Christian Hujer]

Hi,

Have you considered using port 0 instead to tap into the ephemeral port
range and communicate that port somehow?

>From what I understand, you want to use the job id as an offset to a base
port to choose a port from a range, right? That sounds non-portable to me,
spelling all sorts of ports conflict trouble.

Christian

On Fri, Aug 13, 2021, 18:44 Howard Chu via Bug reports and discussion for
GNU make  wrote:

> In my original jobserver implementation, I filled the job pipe with
> up to 256 bytes, numbers from 0-255. The idea being that then make
> could distinguish each job with a unique ID number. That idea got
> thrown away when we decided to raise the limit to PIPEBUF (4096 on
> traditional Unix, much larger now on Linux).
>
> I'm looking for a way to expose a job ID number to the individual
> jobs, in a consecutive range from 1-[number of jobs]. Not just unique
> numbers, for that we could just use $$ already. The purpose is to
> e.g. assign non-overlapping network port numbers when firing off a
> number of client/server test scripts in parallel.
>
> Is there anything that could do this now, exposed as a Make variable?
> --
>   -- Howard Chu
>   CTO, Symas Corp.   http://www.symas.com
>   Director, Highland Sun http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/
>
>

Re: Parallel job instance identifiers?

[Christian Hujer]

Hi,

I'm afraid there's a lot to consider.
> That would require starting up a server first, and somehow getting it to
report its port# to us.
> But the server configs must know port#s in advance because they need to
talk to each other.
Bootstrapping from leaf servers up the dependency tree should be possible.
Cyclic dependencies could get in the way.
Cyclic dependencies usually are a bad idea.
But that's off-topic.

> Currently we use the range of 9000-9020. On a build/test machine we don't
worry about conflicts,
> a developer has no business running conflicting software at the same time
as building/testing
> our software. And of course, the baseport 9000 can be moved at will.

Well, well. I don't subscribe to the idea that anyone can dictate what a
developer would run at the same time and what constitutes such software.
IDEs might use ports.
The system itself uses ports.
Other software might use ports.
The developer might want to build/test two version of the software in
parallel at the same time to do comparative analysis and comparative
debugging.
The definition of the port range for ephemeral ports could change.
There's just so much that could go wrong.
In my experience, assuming the availability of ports leads to flaky tests.
Developers can lose a lot of time to get tests running if they first have
to resolve port conflicts.

I get that you want to use job identifiers for this. But the mechanism is
just not made for that.
That the job identifier is a number is only by coincidence.
Job identifiers are identifiers first, and numbers only coincidentally.
If someone decides, for whatever reason, to replace them with UUIDs, so
what?
I'm not saying that using UUIDs would be a good idea in this case, it's
just about making the point about the difference between an identifier and
a number.

But I totally get that you need something that helps you to get unique
numbers.
Have you considered using a simple shell script that counts up and writes
the count into a named pipe, and then having each job read one line from
that named pipe to get "your" number?
This should do the job:

$ mkfifo counter
$ for ((uniqueNumber = 0; uniqueNumber < 1000; uniqueNumber++)) ; do echo
$uniqueNumber >counter ; done &

You can then get a - for that run - unique number using
$ head -n 1 counter

It should be easy to do this from a Makefile.
If you do this directly from the Makefile, this might require
SHELL:=/bin/bash, recursive make, and an exit handler.

Here is how you could use an exit handler from within a Makefile:
https://stackoverflow.com/questions/28597794/how-can-i-clean-up-after-an-error-in-a-makefile/52159940#52159940

I hope that this helps you and provides you with a pathway solution that
allows you even more control without accidental coupling to internal
features of make.
And while I think that using make is great, this solution would even work
if you use something else than make.

Q'aplah!


On Sat, Aug 14, 2021 at 5:57 PM Howard Chu  wrote:

> Christian Hujer wrote:
> > Hi,
> >
> > Have you considered using port 0 instead to tap into the ephemeral port
> range and communicate that port somehow?
>
> That would require starting up a server first, and somehow getting it to
> report its port# to us.
> But the server configs must know port#s in advance because they need to
> talk to each other.
> >
> > From what I understand, you want to use the job id as an offset to a
> base port to choose a port from a range, right? That sounds non-portable to
> me, spelling
> > all sorts of ports conflict trouble.
>
> Currently we use the range of 9000-9020. On a build/test machine we don't
> worry about conflicts,
> a developer has no business running conflicting software at the same time
> as building/testing
> our software. And of course, the baseport 9000 can be moved at will.
> >
> > Christian
> >
> > On Fri, Aug 13, 2021, 18:44 Howard Chu via Bug reports and discussion
> for GNU make mailto:bug-make@gnu.org>> wrote:
> >
> > In my original jobserver implementation, I filled the job pipe with
> > up to 256 bytes, numbers from 0-255. The idea being that then make
> > could distinguish each job with a unique ID number. That idea got
> > thrown away when we decided to raise the limit to PIPEBUF (4096 on
> > traditional Unix, much larger now on Linux).
> >
> > I'm looking for a way to expose a job ID number to the individual
> > jobs, in a consecutive range from 1-[number of jobs]. Not just unique
> > numbers, for that we could just use $$ already. The purpose is to
> > e.g. assign non-overlapping network port numbers when firing off a
> > number of client/server test scripts in parallel.
> >
> > Is there

RE: GNUmake v4.4 port on Solaris with gcc 9.5.0

[Christian Jullien]

I'm sorry, I was also compiling less 608 and I've read the wrong PuTTY window.

Here is the correct one for make v4.4 on Solaris 10 with gcc 9.5.0:


gcc -DHAVE_CONFIG_H -I. -I../src   -I/usr/local/include  -Wno-cast-qual 
-Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef 
-Wno-unused-function -Wno-unused-parameter -Wno-float-conversion 
-Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits 
-Wno-unsuffixed-float-constants -g -O2 -MT libgnu_a-concat-filename.o -MD -MP 
-MF .deps/libgnu_a-concat-filename.Tpo -c -o libgnu_a-concat-filename.o `test 
-f 'concat-filename.c' || echo './'`concat-filename.c
concat-filename.c: In function 'concatenated_filename':
concat-filename.c:69:7: warning: implicit declaration of function 'stpcpy' 
[-Wimplicit-function-declaration]
   69 |   p = stpcpy (p, filename);
  |   ^~
concat-filename.c:69:7: warning: incompatible implicit declaration of built-in 
function 'stpcpy'


-Original Message-
From: Christian Jullien [mailto:eli...@orange.fr] 
Sent: Thursday, November 03, 2022 06:51
To: psm...@gnu.org; jull...@eligis.com; make-...@gnu.org
Subject: GNUmake v4.4 port on Solaris with gcc 9.5.0

Hi again,

If you care, here are few warnings I've got compiling v4.4 on Solaris 10 using 
gcc 9.5.0 which is the latest gcc version supported by Solaris 10.

[jullien@pastre]less-608$ ./configure; make
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for library containing strerror... none required
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/local/bin/grep
checking for egrep... /usr/local/bin/grep -E
checking whether gcc needs -traditional... no
checking for a BSD-compatible install... /usr/local/bin/install -c
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for tgoto in -ltinfo... no
checking for tgoto in -ltinfow... no
checking for initscr in -lxcurses... no
checking for initscr in -lncursesw... no
checking for initscr in -lncurses... yes
checking for initscr in -lcurses... yes
checking for tgetent in -ltermcap... yes
checking for tgetent in -ltermlib... yes
checking for library containing regcmp... none required
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking ctype.h usability... yes
checking ctype.h presence... yes
checking for ctype.h... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking termcap.h usability... no
checking termcap.h presence... no
checking for termcap.h... no
checking termio.h usability... yes
checking termio.h presence... yes
checking for termio.h... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking for unistd.h... (cached) yes
checking values.h usability... yes
checking values.h presence... yes
checking for values.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/stream.h usability... yes
checking sys/stream.h presence... yes
checking for sys/stream.h... yes
checking wctype.h usability... yes
checking wctype.h presence... yes
checking for wctype.h... yes
checking whether stat file-mode macros are broken... no
checking for an ANSI C-conforming const... yes
checking for off_t... yes
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for working terminal libraries... using -lncurses
checking for off_t... (cached) yes
checking for void... yes
checking for const... yes
checking for time_t... yes
checking for st_ino in struct stat... yes
checking for procfs... no
checking for ANSI function prototypes... yes
checking return type of signal handlers... void
checking for fchmod... yes
ch