Re: GNU Make 4.4.0.90 on Solaris 11 OpenIndiana

[Bruno Haible]

On Solaris 11 OpenIndiana (from 2022), aside from the 4 well-known test
failures in 'features/archives', in 64-bit mode I also see a test failure
in category 'features/output-sync', with an error message
"timeout after 10 seconds".

I don't know why only this 1 out of 3 output-sync tests (compared with
OmniOS) and why only in 64-bit mode.

Find attached the logs.


makeerror-4.4.0.90-x86_64-pc-solaris2.11-nx4l.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on Solaris 11 OmniOS

[Bruno Haible]

On Solaris 11 OmniOS, aside from the well-known 4 features/archives failures,
I see 3 test failures in the 'features/output-sync' category. They come
with an error message "timeout after 10 seconds".

Here the logs:
  - 32-bit build: makeerror-4.4.0.90-x86_64-pc-solaris2.11-thix.tar.gz
  - 64-bit build: makeerror-4.4.0.90-x86_64-pc-solaris2.11-hhav.tar.gz

These 3 failures were already seen at
.


makeerror-4.4.0.90-x86_64-pc-solaris2.11-thix.tar.gz
Description: application/compressed-tar


makeerror-4.4.0.90-x86_64-pc-solaris2.11-hhav.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on Solaris 11.4

[Bruno Haible]

The same 4 failures in features/archives ("cc: not found") also occur
on Solaris 11.4. On this platform, 'cc' does not exist in $PATH, but 'gcc'
does.

Find attached the logs.



makeerror-4.4.0.90-x86_64-pc-solaris2.11-q6is.tar.gz
Description: application/compressed-tar

Re: [PATCH] Check .exe as well when a target does not exist on OS/2

[Paul Smith]

On Tue, 2023-01-17 at 01:38 +0900, KO Myung-Hun wrote:
> What I meant is checking the existence of a rule for a target not a
> real file built for a target.

But how do you check for a "rule for a target"?

What if the pattern rule is "%e" not "%.exe"?  That will still match of
course.  Or "%xe" or whatever?  Or even "%o.exe"?  Are we going to
check to find any possible pattern rule that might match a ".exe" and
behave differently if we find one, even if it has nothing to do with
actually creating a .exe file?

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

[Paul D. Smith]

Follow-up Comment #21, bug #63307 (project make):

This should be fixed in the for the 4.4.1 release; you can download and try a
pre-release of it here:

https://alpha.gnu.org/gnu/make/make-4.4.0.90.tar.gz


___

Reply to this item at:

  

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

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

[Eric Blake]

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

For reference, another failure caused by make's change in behavior:
https://listman.redhat.com/archives/libguestfs/2023-January/030474.html


___

Reply to this item at:

  

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

Re: [PATCH] Check .exe as well when a target does not exist on OS/2

[KO Myung-Hun]

Hi/2.

Paul Smith wrote:
> On Mon, 2023-01-16 at 22:14 +0900, KO Myung-Hun wrote:
>>> But this does not seem like an easy thing to accomplish, at all. 
>>> What if there is a "%.exe" pattern rule, not an explicit rule for
>>> "foo.exe"?
>>
>> I think, it's possible to do so by finding a target as GNU Make finds
>> dependencies.
> 
> GNU Make doesn't try to resolve all the targets including all implicit
> targets first, then after they're all done try to build them.
> 
> Instead, it tries to build every target as it is needed.  So if you try
> to build "foo.exe" first and it finds an implicit target "%.exe" then
> you try to build "foo" second, it will see that the target "foo.exe"
> already exists.
> 
> But if you try to build "foo" first before "foo.exe", then there will
> be no target "foo.exe" yet because you haven't tried to build it, and
> it won't be found.  Note here the "foo.exe" has to be intermediate of
> course, otherwise it will be known to make even using an implicit rule.

What I meant is checking the existence of a rule for a target not a real
file built for a target.

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v6.1.40 on Intel Core i7-3615QM 2.30GHz with 12GB RAM

Korean OS/2 User Community : http://www.os2.kr/

Re: [PATCH] Check .exe as well when a target does not exist on OS/2

[Paul Smith]

On Mon, 2023-01-16 at 22:14 +0900, KO Myung-Hun wrote:
> > But this does not seem like an easy thing to accomplish, at all. 
> > What if there is a "%.exe" pattern rule, not an explicit rule for
> > "foo.exe"?
> 
> I think, it's possible to do so by finding a target as GNU Make finds
> dependencies.

GNU Make doesn't try to resolve all the targets including all implicit
targets first, then after they're all done try to build them.

Instead, it tries to build every target as it is needed.  So if you try
to build "foo.exe" first and it finds an implicit target "%.exe" then
you try to build "foo" second, it will see that the target "foo.exe"
already exists.

But if you try to build "foo" first before "foo.exe", then there will
be no target "foo.exe" yet because you haven't tried to build it, and
it won't be found.  Note here the "foo.exe" has to be intermediate of
course, otherwise it will be known to make even using an implicit rule.

Re: [PATCH] Check .exe as well when a target does not exist on OS/2

[KO Myung-Hun]

Hi/2.

Paul Smith wrote:
> On Mon, 2023-01-16 at 00:15 +0900, KO Myung-Hun wrote:
>> Then, this patch is acceptable? Or MSYS is a special case ?
> 
> I don't think this patch is a good idea.  I said in my initial email:
> 
>> I don't think I like this change.  I understand its usefulness but in
>> general make never tries to manipulate the target names like this.
> 
> And I haven't changed my mind.
> 
> Also I asked:
> 
>> What do you do in situations where there are targets for BOTH "foo"
>> and "foo.exe" in the makefile?  Then when you want to build "foo" it
>> may decide that it's up to date, because it sees the "foo.exe" file
>> instead.
> 
> and you replied:
> 
>> In this case, Make should not find "foo.exe" for "foo" target.
> 
> But this does not seem like an easy thing to accomplish, at all.  What
> if there is a "%.exe" pattern rule, not an explicit rule for "foo.exe"?

I think, it's possible to do so by finding a target as GNU Make finds
dependencies.

> It seems like this behavior would be very confusing for users, where
> sometimes you would get one behavior and sometimes another, based on
> what other rules did or didn't exist.
> 
> The real problem here is that GCC is behaving in an unusual way, where
> you ask it to generate an output file with one name and instead it
> generates an output file with a different name.  My opinion is that
> this is a problem or an issue for GCC, and that we should not attempt
> to paper over that issue by making changes in GNU Make.

Ok, and thanks for your explanation!

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v6.1.40 on Intel Core i7-3615QM 2.30GHz with 12GB RAM

Korean OS/2 User Community : http://www.os2.kr/