[bug #57242] Non-recursive command passes invalid jobserver file descriptors

[Martin Liška]

Follow-up Comment #14, bug #57242 (project make):

> One note: an ideal implementation would look for the _last_ instance of
--jobserver-auth in MAKEFLAGS, not the first instance.  In the current code in
Git, if we are using anonymous pipes and we invoke a sub-process which is not
considered to be a recursive make, we will add an extra
"--jobserver-auth=-2,-2" to the END of MAKEFLAGS to disable the jobserver
(unfortunately it's complicated to try to replace the existing option so
instead we just add an overriding option.
> 
> This should make the jobserver more reliable than before, even when using
anonymous pipes.  It doesn't solve all problems though: named pipes works
better in many situations.

Yeah, I've done that in v2:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599478.html


___

Reply to this item at:

  

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

Macro arguments

[Gisle Vanem]

Hello folks.

I have a question regarding parenthesis
in GNU-make macros. Like in:

  msg = @echo "$(1)"

  ptest_1:
$(call msg, foo (arg1, arg2, arg3))

  ptest_2:
$(call msg, foo, arg1, arg2, arg3)



A 'make ptest_1' shows:
  foo (arg1, arg2, arg3)

and 'make ptest_2' shows:
  foo

as I'd expect since the macro takes only one arg.

So does a "foo (arg1, arg2, arg3)" becomes one
argument due to the parenthesis or something?

I find this parsing a bit strange and inconsistent;
like a comma has no meaning in 'ptest_1'. I did not
find this "issue" in the manual.

GNU Make 4.3.90
Built for Windows32

--
--gv

Bug with collect2.exe: error: ld returned 1 exit status make: *** [Makefile:2: all] Error 1

[Ibrahim Salma]

Hi, i am having problem with makefile or make command can you please help
me it's giving me an error message like this:

collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:2: all] Error 1



This is the code in the Makefile:

all:
g++ -I src/include -L src/lib -o main main.cpp -lmingw32 -lSDL2main
-lSDL2

[bug #62881] parentheses confuse make parser

[Dmitry Goncharov]

URL:
  

 Summary: parentheses confuse make parser
 Project: make
   Submitter: dgoncharov
   Submitted: Tue 09 Aug 2022 07:02:50 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Tue 09 Aug 2022 07:02:50 PM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

  

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

[bug #62881] parentheses confuse make parser

[Dmitry Goncharov]

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

A user reported the following here
https://lists.gnu.org/archive/html/bug-make/2022-08/msg00017.html


in GNU-make macros. Like in:

   msg = @echo "$(1)"

   ptest_1:
$(call msg, foo (arg1, arg2, arg3))

...



A 'make ptest_1' shows:
   foo (arg1, arg2, arg3)

...


So does a "foo (arg1, arg2, arg3)" becomes one
argument due to the parenthesis or something?


"foo (arg1, arg2, arg3)" indeed becomes one argument due to the parenthesis.
Make needs to chop "foo (arg1, arg2, arg3))" into 3 arguments for 'msg'.
make assumes that any comma after an open parenthesis delimits an argument for
a nested macro. Like in "foo $(arg1, arg2, arg3))".
There is no '$' in this case and make could figure out that the user intended
'foo (arg1' to be the 1st arg, etc.



___

Reply to this item at:

  

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

Re: Macro arguments

[Dmitry Goncharov]

On Tue, Aug 9, 2022 at 10:48 AM Gisle Vanem  wrote:

Thanks for your report.
See here https://savannah.gnu.org/bugs/index.php?62881

regards, Dmitry

Re: Bug with collect2.exe: error: ld returned 1 exit status make: *** [Makefile:2: all] Error 1

[Paul Smith]

On Tue, 2022-08-09 at 17:38 +0200, Ibrahim Salma wrote:
> Hi, i am having problem with makefile or make command can you please
> help me it's giving me an error message like this:
> 
> collect2.exe: error: ld returned 1 exit status
> make: *** [Makefile:2: all] Error 1

This is not the error messages.  This is just make telling you that the
command you asked it to run failed (with an exit code of 1).

You have to look at the messages BEFORE this, that you didn't include,
to see why the command failed.

In any event, I'm sure if you cut and paste that exact same GCC command
that's in your makefile onto your shell prompt you'll get the same
error message, so this issue is not related to make or your makefile.

[bug #62881] parentheses confuse make parser

[Dmitry Goncharov]

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

File name: sv62881_test.diff  Size:1 KB


File name: sv62881_fix.diff   Size:0 KB




___

Reply to this item at:

  

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

The order of compiling multiple c++ source files

[ljh]

make manual / 10.2 Catalogue of Built-In Rules / Linking a single object file




x: y.o z.o




when x.c, y.c and z.c all exist will execute:




cc -c x.c -o x.o  # x.c compiles first

cc -c y.c -o y.o

cc -c z.c -o z.o

cc x.o y.o z.o -o x

rm -f x.o

rm -f y.o

rm -f z.o




--- 




Q1: 

The manual states that the x.c compiles first. 

But in my example code uses C++20 modules with gcc 11.2.0 it compiles last.




Q2:

rm -f *.o 

deleting object files doesn't happen in my test with gcc 11.2.0 too.







    ` x : y.o z.o ` # without x.o




or this:




    ` x : y.o z.o x.o ` # with x.o

    `    $(CXX) $(LDFLAGS) $^ $(LDLIBS) -o $@ ` # with 
recipe




The order of compiling is:




g++ -std=c++2a -fmodules-ts -g -c -o y.o c.cpp

g++ -std=c++2a -fmodules-ts -g -c -o z.o b.cpp

g++ -std=c++2a -fmodules-ts -g x.cpp y.o z.o a.o d.o -o x  # x.c compiles 
last

Re: The order of compiling multiple c++ source files

[Paul Smith]

On Wed, 2022-08-10 at 04:32 +0800, ljh wrote:
> make manual / 10.2 Catalogue of Built-In Rules / Linking a single
> object file

The example in the manual is wrong.  The output you're getting from GNU
make is correct.

The reason is that the implicit rule that make chooses for the rule:

  x: y.o z.o

is not "%.o : %.c" followed by "% : %.o".

Instead, make chooses the default rule "% : %.c" which knows how to
create a binary directly from an similarly-named .c file.  You'll note
in your output that the link line is:

  g++ ... x.cpp y.o z.o a.o d.o -o x

see how you have "x.cpp" on the link line, not "x.o"?  And there's no
"x.o" in your directory.

This may not be what you want, but it's a perfectly valid way to build
things.

As for the "rm" that's clearly just wrong: since these objects are
mentioned as prerequisites they cannot be considered intermediate and
won't be deleted.

So, the manual example needs to be fixed.

Re: Macro arguments

[Paul Smith]

On Tue, 2022-08-09 at 16:45 +0200, Gisle Vanem wrote:
> So does a "foo (arg1, arg2, arg3)" becomes one
> argument due to the parenthesis or something?

I agree it's strange.  I'm not sure I agree with the change proposed in
the patch in the Savannah bug: modifying the way all function arguments
are parsed is something that needs to be carefully considered, if
nothing else from a backward-compatibility standpoint.

For now, and for portability even if this change is adopted, I
recommend using variables to hide special characters, or potentially
special characters, used in make function calls:

  $ cat Makefile
  OP = (
  CP = )

  SHOW_1 = $(info $1)

  all : ; $(call SHOW_1,foo $(OP)x, y, z$(CP))

  $ make
  foo (x

I guess technically you only need to hide the open paren since the
close paren, by itself, is not special.