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
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
Update of bug #63330 (project make):
Status:None => Not A Bug
Open/Closed:Open => Closed
___
Follow-up Comment #12:
Ah! Good news!
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.
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
Update of bug #63329 (project make):
Status:None => Duplicate
Open/Closed:Open => Closed
___
Follow-up Comment #1:
Looks like this is an
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
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
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.
___
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
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.
___
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).
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:
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
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
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
16 matches
Mail list logo
