[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #8, bug #65537 (group make): OK, I've installed that patch into Gnulib and I assume GNU Make will pick it up in due course. ___ Reply to this item at:

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

ing patch to intprops-internal.h and let me know whether it works (I no longer use those old GCC versions). The patch should works without your having to fiddle with MAKE_CFLAGS. If the patch works, I can install it into Gnulib. >From cf67e37e3a9b217c83fdcae5ce883009d94b7ae8 Mon Sep 17 00:00:00 2001 F

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #5, bug #65537 (group make): [comment #0 original submission:] > I don't understand the macro guard there. Why would Paul Eggert want to avoid using the pragma in the half-open region between gcc 4.4 and gcc 5, while using it for the half-open region from gcc 4.0 to gcc

[PATCH] Fix integer overflow test in parse_int

* src/arscan.c (parse_int): Use intprops.h macros rather than trying to detect integer overflow by hand, and doing it incorrectly. Here is an example of why the old code was incorrect. If val == 3689348814741910323, base == 10, *ptr == '0', UINTMAX_WIDTH == 64, then (val * base) + (*ptr - '0')

[PATCH 0/3] fix clock skew and unlikely timestamp crashes

file timestamps. This is the only part of the patch that possibly needs a NEWS entry, as the other two patches are purely bug fixes. Paul Eggert (3): make -p buffer overrun fix with outlandish current time make -p uses same clock as rest of 'make' make -p now uses consistent timestamp format

[PATCH 1/3] make -p buffer overrun fix with outlandish current time

* src/main.c (safer_ctime): New function. (print_data_base): Use it. --- src/main.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/src/main.c b/src/main.c index 8215ed78..76e392de 100644 --- a/src/main.c +++ b/src/main.c @@ -3720,6 +3720,18 @@ print_version

[PATCH 2/3] make -p uses same clock as rest of 'make'

Without this patch, the output of 'make -p' would generate output that sometimes incorrectly implied that the clock jumped backwards. * src/main.c (time_now): New function. (print_data_base): Use it. --- src/main.c | 33 +++-- 1 file changed, 31 insertions(+), 2

[PATCH 3/3] make -p now uses consistent timestamp format

* NEWS: mention this. * src/main.c (safer_ctime, time_now): Remove. (print_data_base): Use file_timestamp_sprintf to format timestamps. --- NEWS | 5 + src/main.c | 51 ++- 2 files changed, 11 insertions(+), 45 deletions(-) diff --git

Two 'make -p' timestamp issues

patch attached. From 2e6355c4f3813c346ded2a90997a4308114d2893 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 19 Mar 2023 14:40:39 -0700 Subject: [PATCH] Fix clock skew / crash issue with 'make -p' * NEWS: Mention this. * src/main.c (print_data_base): Use file_timestamp_sprintf instead of time

Re: "make check" failure on Solaris 10 as File::Temp->newdir is missing

On 2022-10-18 20:08, Paul Smith wrote: On Tue, 2022-10-18 at 14:46 -0700, Paul Eggert wrote: Solaris 10 (supported by Oracle through January 2024) uses Perl 5.8.4. tests/README says Perl 5.004 or later is needed That is wrong. In fact the tests/README file hasn't been updated an a very long

"make check" failure on Solaris 10 as File::Temp->newdir is missing

With GNU Make 4.3.91 on Solaris 10 sparc, 'make check' fails as shown at the end of this email. Solaris 10 (supported by Oracle through January 2024) uses Perl 5.8.4. tests/README says Perl 5.004 or later is needed, so I guess either that README file needs to be updated to say a later Perl

Re: Dependency tracking not working on macOS

On 2022-10-16 14:42, Christoph Grüninger wrote: Any idea what I am missing? I double-checked hat the used make has version 4.3.91. Yes, my idea is that either your bleeding-edge "make" is busted, or your environment variables are messed up. Either way it's not an Autoconf bug. What happens

Re: Dependency tracking not working on macOS

On 2022-10-09 15:43, Christoph Grüninger wrote: TMPDIR is also set, to an uncommon name (/var/folders/lr/5gw1xrv53h1b_9mjjvs2k1drgn/T/). Is that directory searchable, readable, writeable? Does its file system have enough free space? Any problems in that area could cause the symptoms

[PATCH] Fix bug in recipe line count overflow checking

Without this patch, the shell command: awk 'BEGIN { print "x:" for (i = 0; i < 65536; i++) printf "\techo %d\n", i} ' | make -f - incorrectly outputs only "make: 'x' is up to date." * src/commands.c (chop_commands): Report overflow in recipe line count when it occurs, as

Re: Dependency tracking not working on macOS

On 2022-10-09 15:17, Paul Smith wrote: On Sun, 2022-10-09 at 16:39 -0400, Zack Weinberg wrote: can I suggest that this kind of problem would be easier to troubleshoot if make printed the name of the temporary file that it could not fopen? In the current Git version, it does do this: ...

Re: [PATCH] Fix some temp file issues

On 2022-10-08 21:19, Eli Zaretskii wrote: I meant the "b" part, not the "+" part. On systems where that changes the bytestream written to the file, the change might require a suitable change where we read that stuff. If I understand things correctly the code was formerly using tmpfile which

Re: [PATCH] Fix some temp file issues

On 2022-10-08 00:14, Eli Zaretskii wrote: tmpfile uses "wb+" (POSIX requires this) and we should be consistent in all the paths that create temporary FILE *. The attached patch adds a comment about this. I don't remember: where is this temporary file read? It's read by a different process

Re: [PATCH] Fix some temp file issues

6d14599b70719526b6086ed509 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 7 Oct 2022 21:31:15 -0700 Subject: [PATCH] Fix some temp file issues This patch was prompted by a linker warning "warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'" on Fedora 36.

[PATCH] Fix some temp file issues

This patch was prompted by a linker warning "warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'" on Fedora 36. It also fixes a few unlikely bugs and simplifies the code in a couple of places. * src/misc.c (get_tmpdir): Now extern, for os_anontmp. (get_tmpbase): New

Re: [PATCH] Port to 32-bit long + 64-bit time_t

On 10/3/22 12:56, Paul Eggert wrote: In looking through old dev histories it appears Paul pushes changes every now and then, so I'll wait until he's pushed his next batch of changes, which will presumably include some timestamp-related fixes, before looking into this again. Thanks

Re: [PATCH] Port to 32-bit long + 64-bit time_t

On 10/3/22 09:12, rsbec...@nexbridge.com wrote: This happens in AR and TAR also, which appear to be limited to 32-bit time_t on some platforms. It's a struggle but we have some time to deal with it. Yes, I've been part of an ongoing effort to make GNU apps Y2038-safe, even on 32-bit

Re: [PATCH] Port to 32-bit long + 64-bit time_t

On 10/2/22 14:23, Paul Smith wrote: I would be happy to use it, if using it didn't import a ton of other things that require POSIX tools AND an already-working make program. Oh, right, sorry, I was confusing inttypes.h (which takes some configuring) with intprops.h (which doesn't). On

Re: [PATCH] Port to 32-bit long + 64-bit time_t

On 10/2/22 14:09, Paul Smith wrote: I applied these changes but made a few mods: Thanks. I assume you'll push this to savannah at some point? I had been working on merging with your more-recent changes to GNU Make, and it wouldn't hurt to have another pair of eyes look at this finicky

Re: [PATCH] Pacify GCC -Wsign-compare

On 9/22/22 21:29, Sam James wrote: Thanks and looks good. Thanks for reviewing. How can I get this installed into GNU Make on savannah? Or are we in some sort of quiet period before the next release, and I should wait? [1] https://lists.gnu.org/r/bug-make/2022-09/msg00126.html

Re: [PATCH] Port to 32-bit long + 64-bit time_t

t;<" to make sure the updated archive header would be readable. There are still some potential buffer read overruns in the sscanf calls in arscan.c but these could be handled by a separate patch (and are less important).From d6b8ac5e3051f863463df5ff03c295df984245cc Mon Sep 17 00:00:00 20

Re: [PATCH] Port to 32-bit long + 64-bit time_t

:00:00 2001 From: Paul Eggert Date: Tue, 20 Sep 2022 14:18:00 -0700 Subject: [PATCH] Port to 32-bit long + 64-bit time_t Don't assume that time_t fits in long, as some hosts (e.g., glibc x86 -D_TIME_BITS=64) have 32-bit long and 64-bit time_t. This fix uses C99 sprintf/scanf %jd and %ju, which

Re: [PATCH] Pacify GCC -Wsign-compare

On 9/21/22 16:11, Sam James wrote: For these, could you consider including the full version? Sure, revised patch attached.From 83808d17d9fd28166ca174d522441edea3257804 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 20 Sep 2022 14:00:34 -0700 Subject: [PATCH] Pacify GCC -Wsign-compare

[PATCH] Pacify GCC -Wsign-compare

* src/arscan.c (ar_scan): Pacify GCC 12.2.1 -Wsign-compare by copying an unsigned value into a signed variable before comparing it. Make sure it is in range before copying. --- src/arscan.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/arscan.c b/src/arscan.c index

[PATCH] Port to 32-bit long + 64-bit time_t

Don't assume that time_t fits in long, as some hosts (e.g., glibc x86 -D_TIME_BITS=64) have 32-bit long and 64-bit time_t. This fix uses C99 sprintf/scanf %jd and %ju, which is safe to assume nowadays. * bootstrap.conf (gnulib_modules): Add largefile, to support files with timestamps after Y2038

Re: $(info xxx) output interleaved with other $(info) output

On 1/20/22 15:02, Dmitry Goncharov wrote: Will $(warning) suit your needs? Although it would fix the interleaved output, it would prepend each log line with something like "Makefile:231:" which would clutter the log format Emacs builders are currently used to. The log format is the same

Re: $(info xxx) output interleaved with other $(info) output

better, other than outputting the information with the shell rather than with $(info). I'm mentioning this here in case anyone else needs a workaround for current and older GNU Make.From 153f3d9af2b3d021d9ba8eb17d979c772a7c09cd Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 20 Jan 2022 10:11

Re: $(info xxx) output interleaved with other $(info) output

On 1/19/22 15:28, Paul Eggert wrote: Proposed patch attached. I see that patch's commit message has the wrong URL for the bug report. Here's a fixed patch, attached. Only the commit message is changed.From 1b9f1bb7f95699e9c0d59b177e83c1b3bc3852a0 Mon Sep 17 00:00:00 2001 From: Paul Eggert

$(info xxx) output interleaved with other $(info) output

and the following newline with two syscalls (it should be one). Proposed patch attached.From d1d2269fbafde7c1b0115dd5c85d82ac4b58677d Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 19 Jan 2022 15:20:40 -0800 Subject: [PATCH] Fix interleaved $(info) output MIME-Version: 1.0 Content-Type: text/plain

Re: [PATCH] Port functions/shell to Solaris 10

On 10/10/19 3:28 PM, Paul Smith wrote: Perhaps Perl on Solaris does some magic to convert this non-standard behavior into standard behavior. Yes, I think it's something along those lines. POSIX doesn't specify how signal numbers and exit statuses are shoehorned into the 'int' status updated

tests/features/output-sync failure on Solaris 10

'make check' fails on Solaris 10 in multiple ways. I posted a fix for the functions/shell problem recently . This bug report is about a different problem, with features/output-sync, which fails as follows: $ cd tests

[PATCH] Port functions/shell to Solaris 10

* tests/scripts/functions/shell: Port exit-status calculation to Solaris 10 with Perl 5.8.4. --- tests/scripts/functions/shell | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tests/scripts/functions/shell b/tests/scripts/functions/shell index 54514e8..93ff7cb 100644 ---

Re: "make check" failure on Solaris 10 with make 4.2.91

On 9/21/19 10:55 AM, Paul Smith wrote: perl -we 'use File::Spec; my @o = File::Spec->splitpath("../make"); print "@o\n"' It outputs a single line containing " ../ make". Hmm, I already wrote that, in one of my comments here: https://lists.gnu.org/r/bug-make/2019-09/msg00101.html Perhaps

Re: "make check" failure on Solaris 10 with make 4.2.91

On 9/16/19 11:20 AM, psm...@nuodb.com wrote: On Mon, 2019-09-16 at 11:04 -0700, Paul Eggert wrote: syntax error at ./run_make_tests.pl line 473, near "or continue" Ugh. Can you change this line: -x $prog or continue; to this: -x $prog or next; Thanks, that got

"make check" failure on Solaris 10 with make 4.2.91

On Solaris 10 sparc, "make check" fails with the attached output. Solaris 10 has Perl v5.8.4 (with 46 registered patches), which is still maintained by Oracle (most recently updated in 2016). I guess the GNU Make test procedure currently requires a later version of Perl. If so, it'd be

Re: GNU make 4.2.90 release candidate available

Dennis Clarke wrote: I am wondering what is the actual dialect to adher to. We need to be portable to C99 and later. C89 and later if the programmer wants to and if it's not too much work. K C is almost surely not worth the effort. OpenSSL is a different project from OpenSSL and uses

Re: GNU make 4.2.90 release candidate available

Dennis Clarke wrote: On 9/2/19 12:28 PM, Paul Smith wrote: On Mon, 2019-09-02 at 18:20 +0200, Robert Pluim wrote: is this intended to build on macOS using clang, or using gcc only? It should work with any C compiler that supports the C89 standard. I was looking for this sort of answer

Re: more GNU make 4.2.90 issues on Solaris 10

Dennis Clarke wrote: This is on a very up to date Oracle M3000 which is on contract support. You've got better hardware than mine, which is a Sun Fire 280R (circa 2005) with two 750 MHz UltraSPARC III CPUs. It was most recently patched three weeks ago so it's reasonably up-to-date. Our

Re: more GNU make 4.2.90 issues on Solaris 10

Paul Smith wrote: One problem seems to be that some tests assume that 'make check' runs GNU Make instead of /usr/ccs/bin/make, which chatters less. I don't think (I hope!!) this is not the problem. If any part of the tests don't run GNU make it's a serious fail clearly. Can you expand upon

Re: [PATCH] Pacify Oracle Studio c99

Paul Smith wrote: I saw this warning on Windows as well. I seem to recall that this was done on purpose to pack data structures more tightly, which can save a lot of memory on large build systems. However looking at it now I don't think it will actually end up saving any space. I don't

[PATCH] Pacify Oracle Studio c99

* src/dep.h (DEP): * src/function.c (struct function_table_entry): Use unsigned int, not unsigned short. Without this patch, c99 complains ‘warning: nonportable bit-field type’. --- src/dep.h | 10 +- src/function.c | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff

more GNU make 4.2.90 issues on Solaris 10

After applying the patches I recently sent to bug-make, I still see several tests failing on native Solaris 10 sparc (32-bit), built with Solaris tools (including Oracle Studio 12.6) instead of with GNU tools. Please see attached files, giving the relevant part of the 'make' output and the

[PATCH] Port grouped_targets test to Solaris 10

* tests/scripts/features/grouped_targets: Use ‘printf ''’ instead of ‘echo -n’, as POSIX says the latter is not portable. --- tests/scripts/features/grouped_targets | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/scripts/features/grouped_targets

[PATCH] Remove useless code in eval

* src/read.c (eval): Remove useless code. Without this patch, Oracle Studio 12.6 complains ‘"src/read.c", line 1405: warning: loop not entered at top’. --- src/read.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/src/read.c b/src/read.c index 175d714..546280c 100644 --- a/src/read.c

[PATCH] Pacify Oracle Studio 12.6 in init_switches

* src/main.c (init_switches): Use a cast to convert char const * to char *. Without this patch, the compiler complains ‘"src/main.c", line 2643: warning: assignment type mismatch: pointer to char "=" pointer to const char’. --- src/main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH] Pacify Oracle Studio 12.6

* src/arscan.c [VMS]: Use ‘#if !defined LBR$_HDRTRUNC’ instead of ‘#ifndef LBR$_HDRTRUNC’ to pacify Oracle Studio 12.6, which looks inside unused #if branches for preprocessor syntax errors. Without this patch it complains ‘"src/arscan.c", line 43: warning: tokens ignored at end of directive

Re: Requiring Automake 1.16.1 due to Gnulib getloadavg?

Paul Smith wrote: It appears that the target that's failing for me, that you didn't try in your test, is "make distclean". Thanks, that explains it. Yes, "make distclean" fails for me too. I don't see a trivial fix so I guess I'll let this sleeping dog lie too. Sorry about the noise. As

Requiring Automake 1.16.1 due to Gnulib getloadavg?

Paul Smith wrote: * Replace local portability code with Gnulib content. Unfortunately due to a problem with Gnulib support for getloadavg, this forces a requirement on Automake 1.16 or above in order to build from Git. See README.git. bootstrap.conf and configure.ac say "1.16.1" so

Re: [PATCH] Do not assume glibc glob internals

Eli Zaretskii wrote: OK, and where is the support for that implemented in GNU Make? There is no special implementation for it. GNU Make calls stat("foo/", ...), and on POSIXish systems this returns -1 and sets errno==ENOTDIR if foo is a regular file, so GNU Make acts on the assumption that

Re: [PATCH] Do not assume glibc glob internals

On 09/29/2017 01:06 AM, Eli Zaretskii wrote: Are there other situations where Make uses "foo/" and expects that to mean that 'foo' is a directory? It's pretty much any situation where Make looks for file names that the user specifies. As a trivial example, the Makefile rule: foo/:; mkdir -p

Re: [PATCH v2 1/2] posix: Add compat glob symbol to not follow dangling symbols

, int quote) -attribute_hidden; static int prefix_array (const char *prefix, char **array, size_t n) __THROWNL; static int collated_compare (const void *, const void *) __THROWNL; >From 3869eefa5b430ec8b23e71b5f150c6a7d8aacb50 Mon Sep 17 00:00:00 2001 From: Paul Eggert &

[bug #52018] suggestion: test case for glob with dangling symlink

Follow-up Comment #4, bug #52018 (project make): You'd have to run bleeding-edge-from-git glibc to get the new behavior, or copy glob.c from bleeding-edge Gnulib and use that instead of glibc glob. The new implementation will use gl_lstat when testing for existence, and will use gl_stat only

Re: [PATCH] Do not assume glibc glob internals

Paul Smith wrote: I can't answer your question, but the previous version of this function didn't do anything special with a "foo/" path, so if it doesn't work here it didn't work there either...? Now I *know* I should have kept my mouth shut. :-) Sorry, I'm lost here, partly because I don't

Re: [PATCH] Do not assume glibc glob internals

Paul Smith wrote: +  size_t plen = strlen (path); + +  /* If path ends in /. make sure it is a directory.  This is because + 'lstat' on Windows normalizes the argument foo/. => foo without + checking first that foo is a directory.  */ +  if (plen > 1 && path[plen - 1]

Re: [PATCH] Do not assume glibc glob internals

Paul Smith wrote: Thanks for this patch, Paul. One question: On Sun, 2017-09-10 at 09:40 -0700, Paul Eggert wrote: +  /* Make sure the parent of "." exists and is a directory, not a + file.  This is because 'lstat' on Windows normalizes the argument + foo/. => foo wit

[bug #52018] suggestion: test case for glob with dangling symlink

URL: Summary: suggestion: test case for glob with dangling symlink Project: make Submitted by: eggert Submitted on: Thu 14 Sep 2017 07:07:30 AM PDT Severity: 3 - Normal

[PATCH] Do not assume glibc glob internals

It has been proposed that glibc glob start using gl_lstat, which the API allows it to do. GNU 'make' should not get in the way of this. See: https://sourceware.org/ml/libc-alpha/2017-09/msg00409.html * dir.c (local_lstat): New function, like local_stat. (dir_setup_glob): Use it to initialize

"make" puts stdout into append mode?

I'm following up to this bug report for 'grep' https://bugs.gnu.org/25283 Although this was a grep bug (grep mishandles /dev/null output when stdout is in append mode), it seems to me that GNU make helped trigger the bug. GNU make puts stdout and stderr into append mode, which is surprising.

backslash-newline mishandled in some commands

With the attached Makefile in an otherwise-empty directory, GNU 'make' 4.2.1 outputs: V=$(expr " " : '\(.*[^ ]\)') && printf '%s\n' "$V" make: *** [Makefile:2: this-should-work] Error 1 It should output: V=$(expr " " : '\(.*[^\ ]\)') && printf '%s\n' "$V" (The line after the 'printf' line

minor glitches in make 4.1.90 found by GCC warning flags

Attached is a patch that fixes the following minor glitches that I found when building GNU Make 4.1.90 with GCC warnings enabled: Use 'unsigned int', not 'int' for modes printed via %o, as GCC warns when printing a signed value with %o (is this undefined behavior?). Rename ar.c's

Re: POSIX ruling on up-to-date vs. identical timestamps

Paul Smith wrote: It's trivial to determine the filesystem in POSIX via the device ID available from stat() Yes, that's what the Gnulib utimecmp module does: the idea is that after every stat-like operation you look at the file's time stamps to infer more information about the containing

Re: POSIX ruling on up-to-date vs. identical timestamps

Paul Smith wrote: It needs to be considered carefully. How about having GNU 'make' do what GNU 'cp -u' does? The idea is to infer filesystem timestamp resolution by looking at every file timestamp that crosses your desk. When you see a file timestamp whose tv_nsec is nonzero modulo

Re: POSIX ruling on up-to-date vs. identical timestamps

Eric Blake wrote: You may want to check out http://austingroupbugs.net/view.php?id=857 and add comments and/or change GNU make behavior accordingly. Let's leave GNU 'make' alone. Its behavior is better for rules like this: copy: original cp -p original copy I've added a comment to

Re: POSIX ruling on up-to-date vs. identical timestamps

Ray Donnelly wrote: There was a bug in libfaketime so that the nanosecond field wasn't cleared That sounds like it's a different issue. If a program botches the nanosecond component of timestamps, it shouldn't matter whether 'make' uses the traditional/GNU or the HP-UX approach; either way,

Re: POSIX ruling on up-to-date vs. identical timestamps

David Boyce wrote: The obvious compromise would be to change the behavior only in the presence of the .POSIX: special target. We should limit .POSIX to what POSIX requires. Even if the ruling stands POSIX won't require the HP-UX behavior, so .POSIX should be independent of this issue.

make 4.0 mishandles UTF-8 characters in macros

Given the attached Makefile, which uses the UTF-8 encoding and which contains a macro whose definiens contains the UTF-8 character '–' (U+2013, EN DASH), 'make' 4.0 fails on my Fedora 20 x86-64 host in the C locale, with the following symptoms: echo '\342 /bin/sh: -c: line 0: unexpected EOF

can't build GNU make from savannah git

README.git says that the following should work, but it fails for me: git clone git://git.savannah.gnu.org/make.git cd make autoreconf -i I get failures under both Fedora 20 and Ubuntu 14.04 (attached). Evidently I'm doing something wrong but it's not clear what, and this makes it hard to

Re: make 4.0 mishandles UTF-8 characters in macros

Hmm. The problem went away when I rebuilt GNU make 4.0 from scratch. The old make-4.0 executable was built back in October 2013 on Fedora 20 and I've been using it since then without problems, but perhaps I used a bad build tool back then. So please disregard this bug report.

Re: can't build GNU make from savannah git

Mike Gran wrote: You might remove the -Wall -Werror text of that line in configure.ac, and that could fix it. Thanks, I tried that (patch attached) and the build got further, but the build failed in a different way (log attached), with the following puzzling diagnostics at the point of

Re: make -q and timestamps

On 08/13/2011 03:02 PM, Bruno Haible wrote: is it possible to extend GNU Make in a way that supports this? Possibly by defining a new kind of special built-in target? Well, one can imagine a new special target .TIME, say, which would look like this: .TIME: foo.h foo.h: a b c etc

Re: bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions

than the other, where we can create files in the latter. I suspect this goes beyond what coreutils's test cases can easily do. From 409c6b774c25afce33f8b67fbf7af3eb3304f6cf Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Wed, 1 Dec 2010 21:25:56 -0800 Subject: [PATCH] utimecmp

compile-time warnings on Solaris 8 64-bit sparc (gcc 4.1.0)

Hey, congratulations on the new version! On Solaris 8 (sparc) with GCC 4.1.0 installed, I built GNU make 3.81 as follows: ./configure --prefix=/r/share1/src/make CC='gcc -m64' make and got some worrisome warnings as shown below. Spot-checking some of the generated machine code, it appears to

Re: compile-time warnings on Solaris 8 64-bit sparc (gcc 4.1.0)

Paul D. Smith [EMAIL PROTECTED] writes: At that time it would be a good idea to look through gnulib etc. for opportunities for re-use. OK, thanks for the heads-up. I expect that gnulib should be able to import some fixes from 'make' as well, e.g., for the glob/fnmatch area. PS. I checked

make 3.80 subscript error if environ has small string

GNU make 3.80 assumes that every string in the environment has at least MAKELEVEL_LENGTH bytes in it, and it executes a subscript error otherwise. Normally this is harmless, but Here is a patch. 2003-10-05 Paul Eggert [EMAIL PROTECTED] * main.c (main): Avoid potential

make 3.80 sprintf potential buffer overruns

that have 5-digit file descriptor numbers. 2003-10-06 Paul Eggert [EMAIL PROTECTED] * arscan.c (ar_member_touch): Don't overrun buffer if a time stamp is so large that it doesn't fit into ar_hdr.ar_date. Report overflow instead. * function.c (func_words

Re: diffutils 2.8.4 bug when make -j is used

Date: Mon, 14 Oct 2002 11:30:12 -0400 From: Paul D. Smith [EMAIL PROTECTED] -cmp.$(OBJEXT) diff3.$(OBJECT) diff.$(OBJECT) sdiff.$(OBJECT): paths.h +cmp.$(OBJEXT) diff3.$(OBJEXT) diff.$(OBJEXT) sdiff.$(OBJEXT): paths.h Wow, thanks. I had to look at that fix twice before I saw the change.

Re: diffutils 2.8.4 bug when make -j is used

From: Chris Bainbridge [EMAIL PROTECTED] Date: Sun, 13 Oct 2002 08:03:42 +0100 Hi, theres a bug in src/Makefile.in/am. It does: paths.h: (echo '#define DEFAULT_DIFF_PROGRAM $(bindir)/'`echo diff|sed '$(transform)'`'' \ echo '#define LOCALEDIR $(localedir)')

Re: diffutils 2.8.4 bug when make -j is used

From: Chris Bainbridge [EMAIL PROTECTED] Date: Sun, 13 Oct 2002 11:43:51 +0100 make 3.79.1. bash 2.05a. I've been testing some more. I have only seen the problem at make -j5 or -j6. Even then its intermittent. I tried it on 2 computers. It doesn't show up at all on a p3-700, only on

obsolete section in make 3.79.2a1 README

A section of the GNU make 3.79.2a1 README file describes the configure option --disable-nsec-timestamps, which no longer exists. Here's a patch. 2002-05-17 Paul Eggert [EMAIL PROTECTED] * README: Remove mention of --disable-nsec-timestamps. This change was part of the 2000-07

Re: Reporting GNUmake3.78.1

From: Paul D. Smith [EMAIL PROTECTED] Date: 19 Sep 2001 23:03:01 -0400 It looks like you're using a version of GNU make packaged for your system by someone else; it's that packaging that's failing. GNU make 3.79.1 is shipped as part of Solaris 8. You can get it as part of the SFWgmake

GNU make 3.79.1 suggestion: .LOW_RESOLUTION_TIME

uot; by having .LOW_RESOLUTION_TIME depend on them. This proposed change affects behavior only on hosts that have high resolution time stamps. 2000-07-23 Paul Eggert [EMAIL PROTECTED] * NEWS, make.texinfo: Document .LOW_RESOLUTION_TIME, which supersedes --disable-nsec-timestamps.

Re: GNU make 3.79.1 suggestion: .LOW_RESOLUTION_TIME

Date: Mon, 24 Jul 2000 16:38:29 -0400 (EDT) From: "Paul D. Smith" [EMAIL PROTECTED] What about an enhancement that allows .LOW_RESOLUTION_TIME: with no targets to apply to all files, essentially duplicating what the old --disable-nsec-timestamps option did? Something like that

Re: make-3.79.1 on glibc-2.1.91 (2)

-23 Bruno Haible [EMAIL PROTECTED] and Paul Eggert [EMAIL PROTECTED] * file.c (file_timestamp_now): Use preprocessor-time check for FILE_TIMESTAMP_HI_RES so that clock_gettime is not linked unless needed. * filedef.h (FILE_TIMESTAMP_HI_RES): Remove

make 3.79.1 configure shouldn't cache --disable-nsec-timestamps

When configuring GNU make 3.79.1, if I run "configure --disable-nsec-timestamps" and then run "configure" again, the fact that I disabled nsec timestamps in the earlier run is cached. This is inconsistent with the other --disable options. Here's a patch. 2000-07-23

Re: make 3.79.1 configure shouldn't cache --disable-nsec-timestamps

Date: Sun, 23 Jul 2000 20:33:27 -0400 (EDT) From: "Paul D. Smith" [EMAIL PROTECTED] Is there anything about this in the GNU standards? Not that I can see. The GNU standards don't talk about the cache. But the tradition is pretty clear. E.g. "configure --disable-nls" isn't cached. I

vms_hash assumes chars are nonnegative (GNU make 3.79.1)

By code inspection I found one more place where the code incorrectly assumes that chars are nonnegative. This code is executed only on VMS. Here's a patch. 2000-06-26 Paul Eggert [EMAIL PROTECTED] * dir.c (vms_hash): Ensure ctype macro args are nonnegative

GNU make 3.79 fix for nanosecond timestamps on 64-bit Solaris sparc

shrinks GNU make a bit on 32-bit Solaris, perhaps because it uses shifting and masking to manipulate timestamps (instead of multiplication and division). 2000-06-10 Paul Eggert [EMAIL PROTECTED] Support nanosecond resolution on hosts with 64-bit time_t and uintmax_t (e.g. 64-bit

revised patch for WINDOWS32 odd future time typo in GNU make 3.79

that turned out to be undesirable as it missed some skews; sorry about that. Here's a patch that fixes just this problem, and cleans up the code a bit so it's easier to follow. 2000-05-22 Paul Eggert [EMAIL PROTECTED] * remake.c (f_mtime): Fix bug when handling future odd