[bug #63329] readdir() error in 4.4 on Solaris 8

[Paul D. Smith]

Update of bug #63329 (project make):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Looks like this is an accidentally-created duplicate of bug #63330


___

Reply to this item at:

  

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

[bug #63330] readdir() error in 4.4 on Solaris 8

[Paul D. Smith]

Update of bug #63330 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #12:

Ah!  Good news!  Thanks for letting us know.


___

Reply to this item at:

  

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

[bug #63330] readdir() error in 4.4 on Solaris 8

[anonymous]

Follow-up Comment #11, bug #63330 (project make):

I was working from a git checkout and it appears that it somehow got into a
strange state.  A build of a fresh download of the 4.4 tarball is fine.  My
apologies for the confusion, this can be closed.


___

Reply to this item at:

  

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

Re: [bug #63330] readdir() error in 4.4 on Solaris 8

[Jeffrey Walton]

On Tue, Nov 8, 2022 at 10:40 AM Dmitry Goncharov
 wrote:
>
> Follow-up Comment #9, bug #63330 (project make):
>
> Depending on _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS dirent has d_ino and
> d_off fields 32 or 64 bits wide.
> Looks like in your case the remote machine has 64bit d_ino and d_off and make
> is built with 32bit d_ino and d_off.
>
> i don't see checks for _FILE_OFFSET_BITS in your config.log.
> Does make work if you build 64 bit or set -D_FILE_OFFSET_BITS=64?
> What is the difference, in regards to large file support, between your good
> working make-4.3 config.log and config.status and this one that fails?
>
> In regards to the error see
> https://docs.oracle.com/cd/E19455-01/806-1075/msgs-2215/index.html

If I recall correctly, Sun recommends building 64-bit binaries on
64-bit OSes, but AutoTools still defaults to 32-bit builds on the
platform.

>From https://docs.oracle.com/cd/E37838_01/html/E66175/features-1.html :

All new applications must be developed as 64-bit
applications and many of the existing 32-bit applications
might require conversion to 64-bit.

Jeff

[bug #63330] readdir() error in 4.4 on Solaris 8

[Paul D. Smith]

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

Wow I'm REALLY confused.  I've examined the config.log file you provided and I
can't make heads or tails of it.  There is no reference anywhere in that file,
to checking for largefile support.  This likely explains why it's not enabled
on this system.

Just to be clear, you did download the official source build from
https://ftp.gnu.org/gnu/make/make-4.4.tar.gz right?  Or, did you create the
package yourself from Git?

Can you run md5sum on the downloaded package and the "configure" script in the
directory; I get:

d7575a26a94ee8427130e9db23cdaa78  make-4.4.tar.gz
3d5221bb26db5cfa8b297738320f33b3  make-4.4/configure


When I look at your log file, I see this:

configure:6535: checking for ranlib
configure:6556: found /usr/ccs/bin/ranlib
configure:6567: result: ranlib
configure:6647: checking for size_t


Right in between the check for ranlib and the check for size_t, is where the
check for largefile support is supposed to be.  Not only is there no output
for it here, but the line numbers in the script are such that it doesn't seem
like there's even any space in the configure script where this might be run!

When I run configure from make-4.4 on my system, I get this:

configure:6506: checking for ranlib
configure:6527: found /usr/bin/ranlib
configure:6538: result: ranlib
configure:6572: checking for special C compiler options needed for large
files
configure:6620: result: no
configure:6626: checking for _FILE_OFFSET_BITS value needed for large files
configure:6652: gcc -c -g -O2  conftest.c >&5
configure:6652: $? = 0
configure:6687: result: no
configure:6962: checking for size_t


Note that it does do the check, and note that all the line numbers are a
little off but the size_t check is a full 300 lines different (presumably
where the largefile support check should be).


PS. from the config.log I note you invoked the configure script as just
"configure".  I recommend you use "./configure" explicitly, if building from
within the source directory, to avoid relying on the PATH settings.  I have no
reason to believe this is the problem since the config.log appears to have
been created from the GNU Make 4.4 configure, but I still recommend using a
specific path.


___

Reply to this item at:

  

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

[bug #63330] readdir() error in 4.4 on Solaris 8

[Dmitry Goncharov]

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

Depending on _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS dirent has d_ino and
d_off fields 32 or 64 bits wide.
Looks like in your case the remote machine has 64bit d_ino and d_off and make
is built with 32bit d_ino and d_off.

i don't see checks for _FILE_OFFSET_BITS in your config.log.
Does make work if you build 64 bit or set -D_FILE_OFFSET_BITS=64?
What is the difference, in regards to large file support, between your good
working make-4.3 config.log and config.status and this one that fails?

In regards to the error see
https://docs.oracle.com/cd/E19455-01/806-1075/msgs-2215/index.html




___

Reply to this item at:

  

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

Re: [bug #63330] readdir() error in 4.4 on Solaris 8

[Jeffrey Walton]

On Tue, Nov 8, 2022 at 8:16 AM anonymous  wrote:
>
> Follow-up Comment #8, bug #63330 (project make):
>
> Just checked and this also affects Solaris 10.  The issue looks identical, let
> me know if you want details from that system.

For testing, gcc210 at the Compile Farm is Solaris 10. See
https://cfarm.tetaneutral.net/machines/list/ .

Jeff

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

[Dmitry Goncharov]

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

> Speaking only for myself, the most realistic scenario I can think of where I
would encounter this myself is if I run 'make 2>&1 | less' and then quit less.
In that case I would not be interested in having any build continue, I would
just want to get back to my prompt

In this scenario the user quit less.
i was thinking about automated builds (jenkins, build farms, etc). Those build
systems get really messy with miriads of pieces of shell code. Should make
abort a build if one of those pipelines fail? My thinking was, if the failed
pipeline was supposed to produce something, then its failure will fail the
build anyway.


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

> It appears that make still performs the same build.  But maybe I just got
something wrong in my test.

For example something like this


$ cat makefile
all: one
one: two
@echo cp $< $@ >&2
@cp $< $@
two:
@echo touch $@ >&2
@touch $@
$ rm one two
$ # this is make-4.3
$ (sleep 2 ; ~/src/make/4.3/make --debug=b)|:
$ ls one two
ls: cannot access 'one': No such file or directory
ls: cannot access 'two': No such file or directory
$ # this is make which handles sigpipe and completes the build
$ (sleep 2 ; ~/src/make/l64/make --debug=b)|:
received sigpipe
received sigpipe
received sigpipe
received sigpipe
received sigpipe
received sigpipe
received sigpipe
received sigpipe
received sigpipe
received sigpipe
received sigpipe
touch two
received sigpipe
received sigpipe
cp two one
received sigpipe
received sigpipe
received sigpipe
make: write error: stdout
$ ls one two
one  two


~/src/make/l64/make is a modified make which has the following sigpipe handler
installed

static void
sigpipe_handler (int sig)
{
static const char msg[] = "received sigpipe\n";
write (STDERR_FILENO, msg, sizeof msg);
}


i remember you reported that on your system you had to modify make to set
sigpipe to default, otherwise it was ignored.
What about something like

$ cat test.pl
#!/usr/bin/perl

$SIG{'PIPE'} = 'DEFAULT';
system('bash -c "(sleep 4 ; ~/src/make/l64/make --debug=b)|:"');



___

Reply to this item at:

  

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

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

[anonymous]

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

Whether that's "equally likely" is something we are probably going to disagree
over, especially in the case where output (or potentially error) is piped to
another process, but not worth getting into a discussion about. Suffice to
say, it is indeed possible that the spawned processes would produce no output,
and letting make continue would potentially allow a build to complete
successfully. Whether that's desirable is going to depend on the user.
Speaking only for myself, the most realistic scenario I can think of where I
would encounter this myself is if I run 'make 2>&1 | less' and then quit less.
In that case I would not be interested in having any build continue, I would
just want to get back to my prompt, but I'm happy to accept that other
scenarios may exist where other users may want something different.


___

Reply to this item at:

  

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

[bug #63330] readdir() error in 4.4 on Solaris 8

[anonymous]

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

Just checked and this also affects Solaris 10.  The issue looks identical, let
me know if you want details from that system.


___

Reply to this item at:

  

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

[bug #63330] readdir() error in 4.4 on Solaris 8

[anonymous]

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

Oh and yes, 4.3 works just fine on NFS mounts.  It's what I've been using to
build 4.4.  The NFS mount is definitely over 4GB but this is the first time
I've run into issues with that.


___

Reply to this item at:

  

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

[bug #63330] readdir() error in 4.4 on Solaris 8

[anonymous]

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

I definitely don't expect everything to work perfectly on a system this old,
and if it does turn out to be a Solaris bug I'll certainly find a way to deal
with it locally.  That being said I find that compiling on these older systems
sometimes turns up interesting corner cases.

Attached are config.log and config.status from a build configured with GCC
4.7.4.  Note that I had to manually remove -Wformat-signedness and
-Wduplicated-cond from the generated Makefile because GCC 4.7.4 doesn't
understand them, and disable -Werror for src/getopt.c, src/misc.c, and
src/posixos.c all for harmless/unrelated warnings.

(file #53940, file #53941)

___

Additional Item Attachment:

File name: config.log Size:185 KB


File name: config.status  Size:46 KB




___

Reply to this item at:

  

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

Re: GNU Make 4.4 released!

[KO Myung-Hun]

Hi/2.

Paul Smith wrote:
> On Mon, 2022-11-07 at 20:40 +0900, KO Myung-Hun wrote:
>> May I take over OS/2 port maintenance ?
>> For this, what should I do ?
> 
>1. Subscribe to this mailing list and announce your intention to
>   work on this (to prevent possible duplication of effort).

Already done.

>2. Download the latest release (currently GNU Make 4.4).
>3. Get it to compile on OS/2 and, if possible, run the regression
>   test suite (if you have Perl on OS/2).
>4. If you can't run the regression test suite, then generate your
>   own set of tests (for example some other software that you can
>   use GNU Make to build, especially software that makes use of GNU
>   Make features).

I've built successfully with a little changes. I'll try to run
regression test suite later.

>5. Once you're satisfied that it works properly, post a patch or set
>   of patches for the changes you needed to make to get it working,
>   to this mailing list.
>6. Likely there will need to be a conversation about the best way to
>   address various issues so be prepared to rework your changes if
>   necessary.

Ok, I'll post later.

>7. If your changes are at all extensive, you will need to fill out
>   paperwork to assign copyright for your changes to the FSF, and
>   your employer (if they have rights to your work which most do)
>   will need to approve this as well. Contact me to get the needed
>   paperwork.

I have this already for GNU Make.

>8. Commit to testing and updating the port when new prereleases of
>   GNU Make are announced.
> 
> That's pretty much it.
> 
> You should consider carefully whether it's really worthwhile to make
> this effort. Presumably there is already some version of GNU Make that
> works on OS/2 and can be used there which satisfies all current needs.
> That version obviously will continue to be available: no one is
> suggesting changing published versions.
> 

I know. And I'm already maintaining GNU Make v3.81 for OS/2 at
https://github.com/komh/make-os2. I'll try to merge the patches in there.

> Most of the new features available in GNU Make, such as Guile support,
> dynamic object loading, jobserver, output sync, etc. almost certainly
> can't be made to work on OS/2 and so will just need to be disabled. So
> the question is, is keeping this port up-to-date a good use of
> resources?
> 

I think so. And if some projects requires newer GNU Make, working on GNU
Make at that time needs more resources.

> Of course, only the OS/2 users can answer this question.
> 
> If you decide it is worthwhile, and you have the bandwidth and ability
> to do it, then welcome aboard!

I willing to do.

Thanks!

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

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

[Andreas Schwab]

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

The SIGPIPE failure only happens when the process actually produces output to
the broken pipe.  But it is equally likely that a recipe doesn't actually
produce any output on stdout.


___

Reply to this item at:

  

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

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

[anonymous]

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

When SIGPIPE is set to the default action, then yes, writing to a closed pipe
is expected to get make to die abnormally. That's how SIGPIPE is designed to
work. :) This is different from a regular failure to write to stdout.

There is little benefit to continuing the build in that case: if the build
continues, spawned processes will see the same closed pipe that make saw, and
those spawned processes will likely fail anyway because they too would be
terminated by SIGPIPE if they attempt to write to stdout.


___

Reply to this item at:

  

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