Follow-up Comment #3, bug #30370 (project make):
The major issue here, besides the effort involved of course, is finding a
syntax or format that is backward compatible, at least enough to avoid
breaking a lot of makefiles.
I also have to say that the request at stackoverflow.com and the request
Follow-up Comment #5, bug #30381 (project make):
But it isn't just a matter of infinite recursion; there's a very serious
issue of performance as well, even without infinite recursion. Computing
pattern rule matches can already take quite a while: if we add more ways in
which patterns can
Update of bug #17381 (project make):
Assigned to:None = eliz
___
Follow-up Comment #2:
Eli: I don't see this patch in the current CVS version. Is this still
needed?
Thanks!
Update of bug #24513 (project make):
Status:None = Works for me
Open/Closed:Open = Closed
___
Follow-up Comment #2:
No response here so
Follow-up Comment #1, bug #25713 (project make):
I'm not sure the best way to handle this. What's the triplet printed by
running config.guess on your system?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25713
Update of bug #26921 (project make):
Open/Closed:Open = Closed
___
Follow-up Comment #2:
No response so I'm marking this closed. Please add a comment if you still
see this and I can
Update of bug #26891 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #2:
In 3.82 we have
Update of bug #17381 (project make):
Status:None = Fixed
Fixed Release:None = CVS
___
Reply to this item at:
Follow-up Comment #3, bug #25713 (project make):
A log would be helpful. The problem is that from what you say, it's not that
functions are missing. It seems more like there are errors in the system
headers; for example if u_long is not available when compiling getloadavg.c
then why not? I
Follow-up Comment #7, bug #25713 (project make):
OK, the problem seems to be that in config.h, we have HAVE_BSD_SIGNAL set.
But, in the output of the preprocessor for main.c that function is not defined
anywhere. So, the C compiler gives it the default prototype where it returns
int, instead
Update of bug #30463 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #2:
I suppose it might be
Follow-up Comment #4, bug #30328 (project make):
Make can handle simple quoting without falling back to the shell, including
the difference between single- and double-quotes etc.
___
Reply to this item at:
Update of bug #30551 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Closed as a duplicate
Update of bug #30606 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #3:
Tim is correct; as far
Follow-up Comment #5, bug #30606 (project make):
If by already expanded ... when the template is being defined you mean
after the define T ... endef, then you're not correct. define, by itself,
uses deferred expansion (just like T = $(foo)) and so right after the define
the value of T has NOT
Follow-up Comment #6, bug #30606 (project make):
Ugh, my comment got truncated. I used this example:
define T
b := $(subst aa,,$(1))
yn := $(if $(strip $(b)),y,n)
vs := $(vs) $(1):$(yn)
endef
$(info $(value T))
will show the string that make is storing as the value of T, without any
Update of bug #30614 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #2:
See the GNU make
Follow-up Comment #1, bug #30723 (project make):
Hm. Is there any way for you to provide a smaller example? I tried to
follow your directions but I think the build failed for some other reason,
earlier than the problem you hit:
make[2]: *** No rule to make target
Follow-up Comment #3, bug #30723 (project make):
Hm, I believe I found the bug. Please try this patch:
--- main.c 19 Jul 2010 07:10:53 - 1.243
+++ main.c 10 Aug 2010 07:12:15 -
@@ -2093,6 +2093,7 @@
const char *pv = define_makeflags (1, 1);
char
Update of bug #30723 (project make):
Item Group:None = Bug
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:
Update of bug #30612 (project make):
Item Group:None = Bug
Assigned to:None = psmith
Component Version: CVS = 3.82
Triage Status:
Update of bug #30612 (project make):
Summary: make-3.82 parse error = error parsing library
references with multiple objects
___
Reply to this item at:
http://savannah.gnu.org/bugs/?30612
Follow-up Comment #4, bug #30714 (project make):
I don't have any Windows systems; all my systems run Linux or some UNIX
variant. So, I can't support Windows myself and I rely on a group of
volunteers to maintain that platform (just like with VMS and other non-POSIX
platforms).
One concern
Update of bug #30612 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Fixed Release:None = CVS
Update of bug #30809 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
The documentation
Update of bug #30823 (project make):
Triage Status:None = Verified
___
Follow-up Comment #1:
Yes, I see this too. It definitely looks like a bug.
Update of bug #30833 (project make):
Item Group: Bug = None
Status:None = Not A Bug
Open/Closed:Open = Closed
Component Version:
Follow-up Comment #5, bug #30662 (project make):
I've modified the options for the files that appeared to have CRLF characters
in them, but did not have -kb set, to use -kb so they are treated as binary.
Please let me know if I've missed any or this causes any issues.
Update of bug #30662 (project make):
Component Version: CVS = 3.82
Fixed Release:None = CVS
___
Reply to this item at:
Update of bug #30807 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #30762 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Component Version:
Update of bug #111 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #1, bug #31002 (project make):
This is due to this change, from the NEWS file:
* WARNING: Backward-incompatibility!
The pattern-specific variables and pattern rules are now applied in the
shortest stem first order instead of the definition order (variables
and rules with
Follow-up Comment #1, bug #31003 (project make):
Hm. I specifically set the LC_ALL environment variable to C before
invoking tests, which is supposed to revert to the built-in strings and avoid
all translations.
It may be that the test suite that comes with GNU make 3.81 is not updated in
this
Follow-up Comment #3, bug #31002 (project make):
Ah I see, because the pattern matches different parts of the stem. Good
point. Let me discuss with Boris.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?31002
Update of bug #31003 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Fixed Release:None = 3.82
Follow-up Comment #7, bug #31002 (project make):
I think we should move this to the make-alpha or bug-make lists. I don't
think Savannah bug trackers are the right way to address the larger conceptual
issues of when backward-compatibility breaks are OK and when they're not.
Update of bug #31087 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Thanks for the note;
Follow-up Comment #4, bug #28456 (project make):
See also duplicate bug #31087
___
Reply to this item at:
http://savannah.gnu.org/bugs/?28456
___
Message sent via/by Savannah
Update of bug #31110 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Fixed Release:None = 3.82
Update of bug #31149 (project make):
Triage Status:None = Verified
Summary: The rule for generation dependency file (%.d)
doesn't work = Rules to build -include makefiles cause unexpected
side-effects
Update of bug #31278 (project make):
Status:None = Fixed
Fixed Release:None = 3.82
___
Follow-up Comment #1:
The current behavior
Update of bug #31278 (project make):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?31278
___
Message
Follow-up Comment #1, bug #31326 (project make):
Isn't Makefile:40 the file/line information you're looking for?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?31326
___
Message
Follow-up Comment #6, bug #31361 (project make):
Nothing I've seen so far indicates that this is a bug in make. Make has no
visibility into, or even concept of, intermediate files created by your
compiler, and it's certainly not going to be deleting them. From what I've
seen it's your compiler
Follow-up Comment #1, bug #31430 (project make):
I've nothing against adding != for portability. However this level of work
will require copyright assignment to the FSF. Please let me know if you need
paperwork/assistance.
Cheers!
___
Update of bug #31743 (project make):
Triage Status:None = Verified
___
Follow-up Comment #1:
Actually it doesn't work (always) in 3.81; there's a memory corruption bug
here that shows up
Update of bug #31762 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This is not a bug.
Follow-up Comment #1, bug #31847 (project make):
Have you tried with the latest version (GNU make 3.82)?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?31847
___
Message sent
Update of bug #31940 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #32473 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This works as
Update of bug #32498 (project make):
Triage Status:None = Verified
___
Follow-up Comment #2:
I don't know, something seems wrong here to me. If you have:
export AA
$(eval export AB)
tst =
Update of bug #32484 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Duplicate of bug #32485
Follow-up Comment #5, bug #31430 (project make):
Those lines were never ignored (GNU make never ignores malformed lines).
Instead, because the prefix ! was not recognized, GNU make assumed that it
was part of the variable name. If you look at the output of GNU make -p with
your sample makefile
Update of bug #33034 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #3:
This is an intentional
Follow-up Comment #3, bug #33125 (project make):
So I'm happy to make this change, because it does seem cleaner, but I must
confess I don't understand how the original error is caused by it.
The code uses isspace() to count spaces the first time through the list.
isspace() matches spaces and
Update of bug #32871 (project make):
Triage Status:None = Verified
___
Follow-up Comment #1:
I agree, this is a bug.
___
Reply to this
Update of bug #33125 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Operating System:
Update of bug #32753 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Component Version:
Follow-up Comment #8, bug #33125 (project make):
I added a regression test with my fix. It won't show any difference in
behavior unless you run it in valgrind or similar though.
___
Reply to this item at:
Update of bug #32872 (project make):
Triage Status:None = Verified
___
Follow-up Comment #1:
I agree, this is a bug
___
Reply to this
Update of bug #32058 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #2, bug #32307 (project make):
The primary intent of the GNU make manual is to be printed into a paper book.
Maybe that's anachronistic now, but I still am not terribly jazzed about the
idea of sprinkling little parenthetical comments throughout the text such as
(added in
Update of bug #31582 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #23922 (project make):
Assigned to:None = eliz
___
Reply to this item at:
http://savannah.gnu.org/bugs/?23922
___
Message
Update of bug #32872 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #33274 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Duplicate of (already
Update of bug #33344 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Regarding the leading
Follow-up Comment #5, bug #33034 (project make):
I'm not trying to be flip, but what do you do when you upgrade to a new
version of the compiler and older code no longer builds correctly due to more
stringent requirements? I see this in code all the time (not GNU make) with
new versions of GCC
Follow-up Comment #3, bug #30612 (project make):
whoops, you're right: fixed now in CVS.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?30612
___
Message sent via/by Savannah
Follow-up Comment #1, bug #34167 (project make):
GNU make 3.81 was released almost 5 1/2 years ago. Many bugs, including
memory bugs, have been resolved since then. Please try with the latest version
(3.82) or even the latest version available from CVS and see if you still have
memory errors.
Update of bug #31614 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Duplicate of bug #712
Follow-up Comment #3, bug #34167 (project make):
It's not clear to me that this is due to a bug in make. Offhand it looks like
a configuration or environment problem, not a bug in make. Are you still
seeing Purify errors when you try to run this version of make?
If you are please attach the
Update of bug #33958 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #11, bug #712 (project make):
bug #31614 closed as a duplicate of this bug
___
Reply to this item at:
http://savannah.gnu.org/bugs/?712
___
Message sent via/by Savannah
Update of bug #33399 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
It isn't the backslash
Update of bug #31489 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #32202 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
Triage Status:None = Need Info
Update of bug #32498 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #1, bug #34309 (project make):
I believe this has been fixed in GNU make CVS already. Can you check and see
if that works better for you?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?34309
Update of bug #34310 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Make cannot give such
Update of bug #32511 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #33873 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #3, bug #31326 (project make):
There's nothing make can do about this, that I can see. If your variable
contains invalid syntax for a target then you won't see a problem until the
variable is used in a target context, and that's where the error will happen.
I suppose make
Update of bug #34747 (project make):
Item Group:None = Enhancement
Status:None = Duplicate
Open/Closed:Open = Closed
Update of bug #34806 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This has already been
Update of bug #34608 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
It turns out that this
Update of bug #34530 (project make):
Status:None = Later
Triage Status:None = Medium Effort
___
Follow-up Comment #1:
I'm not too excited
Follow-up Comment #3, bug #34608 (project make):
Hm. This change is not identical to the original. To get that you'd need to
write !((t) -1 = 0) and if you do that then GCC warns again.
However I'm not aware offhand of any numeric implementations where casting a
-1 to an unsigned value yields
Follow-up Comment #4, bug #34530 (project make):
Eli: Using '' or instead of `' is also pure ASCII...? I agree with Markus,
really, that this is a throwback to broken terminal fonts from the 1980's,
that it looks ugly in virtually every font available today, and I don't see
any reason to
Update of bug #34608 (project make):
Status: Not A Bug = None
Open/Closed: Closed = Open
___
Reply to this item at:
Follow-up Comment #6, bug #34608 (project make):
This is what I get:
$ cat foo.c
#define INTEGER_TYPE_SIGNED(t) !((t) -1 = 0)
int foo() { return INTEGER_TYPE_SIGNED(unsigned int); }
$ gcc --version
gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
$ gcc -Wextra -g -c -o foo.o foo.c
foo.c: In function
Follow-up Comment #6, bug #34530 (project make):
The strings are the keys to the translation lookup table, yes. So changing
the string changes the lookup key. I don't know what you mean by change the
hashes at our end? The hashes are generated at runtime by the gettext
library when you ask for
Update of bug #15719 (project make):
Operating System: MS Windows = Any
Summary: Make jobserver feature not supported on WINDOWS32
platforms = Test suite not reliable for parallel build support
Update of bug #32567 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Operating System:
Update of bug #34608 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Operating System:
Update of bug #34519 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #3:
I believe this bug is
Update of bug #33399 (project make):
Status: Not A Bug = Fixed
Assigned to:None = psmith
Operating System: POSIX-Based = Any
Fixed Release:
Follow-up Comment #3, bug #34818 (project make):
Maybe I don't understand the context. For typical Windows, VMS, OS2, etc.
builds GNU make doesn't run autotools (as I understand it). It has predefined
config.h variations for those targets and you copy the right one over to
config.h before you
Follow-up Comment #5, bug #34818 (project make):
Gotcha. I didn't realize people were using autotools with Windows targets.
Cross-compiling for a Windows target sounds funky to me but I definitely see
the attraction there :-).
___
Reply
901 - 1000 of 2097 matches
Mail list logo
