RE: not able start Dansguardian service

>From the evidence you have provided, it looks like you have a pre-installed version of dansguardian that isn't working and that you've successfully configured but not tried to build or install a version of dansguardian from source. If I were you, I'd be looking in /var/log/messages or /var/log/sy

RE: Need Help

help-make might be an appropriate mailing list to send this request to. Googling for a make tutorial might turn up something useful. There's always the make manual, which contains a fairly simple example: http://www.gnu.org/software/make/manual/make.html#Simple-Makefile You might, however, be

[bug #18963] -include suppressing errors for too long?

Follow-up Comment #1, bug #18963 (project make): -include never issues warnings or errors. I'd previously suggested a change to that section of the manual in http://lists.gnu.org/archive/html/bug-make/2007-01/msg2.html. Perhaps you'd like to suggest a further or alternative change to make t

RE: BUG while running the make file

Yes, that is a bug *while running* make. Perhaps we should rename the mailing list to [EMAIL PROTECTED] or otherwise try to indicate in the error message that this isn't likely to be a bug in make. Perhaps we're doomed though. For one thing, this bug looks unlikely to be a bug in lprng, which

RE: BUG while running the make file

> 2007-02-07-15:28:15.682 sbkdgdbdev1 Init_tempfile: bad tempdir '/var/spool/lpd/%P' ... > *** glibc detected *** double free or corruption (fasttop): 0x080a0bc8 *** Now those are definite lprng issues. Suggest googling or taking that to an lprng list. This list is only for bugs in make. We try

[bug #19035] Make recompiles source files eventhough the files are not modified

Follow-up Comment #2, bug #19035 (project make): Also, if your source was last written on machine A and you're now trying to compile those files on machine B and machine B's clock is so far behind machine A's that the source files' timestamps still appear to be the future, then you'd see this beh

RE: $(and) and $(or) not working

Works for me. 3.81 was released early in 2006 (the release note (http://savannah.gnu.org/forum/forum.php?forum_id=4380) uses non-ISO date format, so I'm unsure how to parse the month and day). You'll want to submit a minimally-sized example makefile with copy-and-pasted output. Like this: [EMAI

[bug #19900] Target-specific variables not honored for rules generated by $(eval)

Follow-up Comment #1, bug #19900 (project make): See the note about double expansion here: http://www.gnu.org/software/make/manual/make.html#Eval-Function You want the rule to read: echo $$(var) That then works for me. ___ Reply to th

[bug #20033] parallel (-j2) make with $(eval) construct segfaults

Follow-up Comment #2, bug #20033 (project make): (I can reproduce a crash with that example.) ___ Reply to this item at: ___ Message sent via/by Savan

RE: Problem with make...

That sounds unlikely to be a bug with make, so the help-make list would be more appropriate. The make maintainer has a paper on dependencies which you can find here: http://web.archive.org/web/20061205233409/http://make.paulandlesley.org/ autodep.html That focuses on automatic generation of the

RE: Single-suffix rules broken?

> .SUFFIXES = .in Your makefile works for me (with "make foo", given a foo.in) if I change that line to read: .SUFFIXES: .in -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ludovic Courtès Sent: Sunday, August 12, 2007 00:30 To: bug-make@gnu.org Subje

[bug #21198] Wrong order of prerequisites with 3.81/CVS

Follow-up Comment #1, bug #21198 (project make): In which order do you think the prerequisites should be built? And why? If C should be built before D, for example, then we have to tell make that D depends on C. Mentioning D after C in a list of prerequisites is not sufficient. Mentioning D o

[bug #21198] Wrong order of prerequisites with 3.81/CVS

Follow-up Comment #2, bug #21198 (project make): Robin Williams points out there is a different issue here which can be seen by adding $< to the echo command, so the test reads: all : A B C all : ; @echo $@ -- $^, $< all : D E F A B C D E F : ; @echo $@ With that change, make-3.80 says: A B C

RE: canonicalization/stripping of leading ./

http://www.gnu.org/software/make/manual/make.html#Makefile-Basics suggests you follow your final suggestion, as you (seem to) have a $(srcdir) variable. It suggests ./ otherwise, although I've tripped over doing that and generally use $(CURDIR)/ myself. It's helpful elsewhere that ./file and file

RE: canonicalization/stripping of leading ./

age- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, November 28, 2007 14:42 To: bug-make@gnu.org Subject: RE: canonicalization/stripping of leading ./ On Wed, 28 Nov 2007, Martin Dorey wrote: > http://www.gnu.org/software/make/manua

RE: install problem

You haven't installed docbook2man but libieee1284-0.1.6 seems to require it. Google's first match for your error message looks to have some advice for exactly this error: http://canon-fb330p.sourceforge.net/howto-fb630p-english This mailing list is for bugs with make. That isn't a make bug. Go

RE: make command

> I need the latest and greatest for Red Hat 9 Try http://rpmfind.net/linux/rpm2html/search.php?query=make. Please though, if you need more help, bear in mind that this mailing list is for bugs with make itself. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED

RE: THIS PROGRAM BUILT FOR i686-pc-cygwin

> When a make command MAKE Any bug report should contain: What exactly did you type? What did the computer say? Paste all of the output into the bug report. Why do think that is a bug? That last point is the most interesting. You don't say what you expect "make" to do. You don't say which

RE: make 3.81 crash: make: double free or corruption (!prev)

Didn't happen for me with the same makefile and similar make, kernel and architecture. In any case it sounds more like bad ram. Suggest burning a CD of http://www.memtest.org/ and leaving it running overnight. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] O

RE: Reg Make build on LINUX

If you can reduce the test case makefiles to a few lines such that they still demonstrate behavior that you can show is inconsistent with the documentation, then we'd be very happy to help. In that case, you'd want to supply the makefiles and the output when you run make and any instructions neces

RE: File timing bug

This example is certainly simple, thanks. The Makefile isn't telling make that the rule for making c from d will also update b. Make caches modification times and doesn't know to invalidate its cache of b's time. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Beh

RE: File timing bug

t a Static Pattern Rule.) I was rather hoping I'd provoke a more authoritative response from one of the real gurus but perhaps the warnocking should be taken as agreement.) -Original Message- From: Herbert Euler [mailto:[EMAIL PROTECTED] Sent: Monday, June 09, 2008 23:41 To: Martin

RE: Help : how to use $(or condition ) & $(and condition ) inmakefile

Try make -f and.mk A=22 B=44. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Murphy Sent: Tuesday, June 17, 2008 09:31 To: bug-make@gnu.org Subject: Re: Help : how to use $(or condition ) & $(and condition ) inmakefile Hi, I have amended an

[bug #23928] Add MAKEFILE variable

Follow-up Comment #1, bug #23928 (project make): Simply add this to rules.mk and you're done: MAKEFILE = $(firstword $(MAKEFILE_LIST)) ___ Reply to this item at: _

RE: [bug #23928] Add MAKEFILE variable

tional variable, perhaps called MAKEFILE_STACK. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2008 03:01 To: bug-make@gnu.org Cc: [EMAIL PROTECTED]; Martin Dorey; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [bug #23928] Add MAKEFILE variabl

Re: dry-run (-n) has no effect with include file generation

It's not dry when the command in question is a recursive call to make either. That's because, in both cases, it's more useful to more people to behave this way by default. If you want a different behavior, you can have your including makefile decide not to include if the included file doesn't

Re: Order of consideration of missing include files is not documented

The order of generation of any targets that don't have dependencies is not documented. This is deliberate because there is no defined ordering. The targets may even be generated in parallel. - Original Message - From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> To: bug-make@gnu.org Sent: Mo

[bug #24251] Random error including rebuilt makefiles

Follow-up Comment #1, bug #24251 (project make): Looks like https://savannah.gnu.org/bugs/?102 to me. ___ Reply to this item at: ___ Message sent via/b

[bug #24251] Random error including rebuilt makefiles

Follow-up Comment #3, bug #24251 (project make): I reproduced the behavior you saw without svn by replacing the end of the makefile with: $(ECOS_MAKE) : $(ECOS_DIR) $(ECOS_DIR) : mkdir -p $(ECOS_DIR)/include/pkgconf/ { echo 'ECOS_GLOBAL_CFLAGS = -mcpu=arm7tdmi -Wall -Wp

RE: Bug report for "make" documentation

I'm not sure I've understood. Perhaps rewording the second stanza like this would address your concern? "However, if you use the value $(objects) in a target or prerequisite, wildcard expansion will take place there. If you use the value $(objects) in a command, the shell may perform wildcard ex

[bug #24509] doc for wildcard expansion in commands could be clearer

URL: Summary: doc for wildcard expansion in commands could be clearer Project: make Submitted by: mdorey Submitted on: Thu 09 Oct 2008 06:20:47 PM GMT Severity: 3 - Normal

Re: possible bug in documentation for make

> last updated 04 April 2000, of `The GNU Make > Manual', for `make', Version 3.79. I use: GNU Make > version 3.79.1 (Wow, that's pretty old skool.) > It seems as if it is not possible to change the value > of a variable inside an ?ifeq? conditional that test > against that very variable Th

RE: make switch options

> To install this software correctly "make" must run as follows That sounds like a bug in the documentation you're reading rather than a bug in make. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Siraj Rathore Sent: Friday, November 21, 2008 11

RE: make --guaranteed-real-dry-run

It's not clear whether you're complaining about rules whose commands are run even with -n or -t, or whether you're complaining about commands run by eg $(shell). Assuming the former, the documentation already explains: The `-n', `-t', and `-q' options do not affect command lines that begin with

RE: make --guaranteed-real-dry-run

make --help in CVS has been updated with the "recipe" clarification but still says: -n, --just-print, --dry-run, --recon\n\ Don't actually run any recipe; just print them.\n" I agree that make --help is on particularly dubious ground when saying "any recipe". Sayi

RE: Bug in make-3.81: variable_buffer moves out from under buffer

> it looks like this bug is still there And it looks like there are several other instances of it too. >> What I am looking for is some help writing a makefile that >> is simple enough to post in a bug report. I had a few goes but it looks like the variable_buffer is always already big enough by

RE: Bug in make-3.81: variable_buffer moves out from under buffer

, 2009 13:44 To: bug-make@gnu.org Subject: Re: Bug in make-3.81: variable_buffer moves out from under buffer Martin Dorey bluearc.com> writes: > And it looks like there are several other instances of it too. That's what I was afraid of. I looked at the other places where xreallo

RE: Bug in make-3.81: variable_buffer moves out from under buffer

ces+mdorey=bluearc@gnu.org] On Behalf Of David Wuertele Sent: Tuesday, January 20, 2009 15:07 To: bug-make@gnu.org Subject: Re: Bug in make-3.81: variable_buffer moves out from under buffer Martin Dorey bluearc.com> writes: > In the original makefile, does > the long rule really not co

RE: make --guaranteed-real-dry-run

to the current source and generate a patch to attach to the bug. Someone might then commit the changes. -Original Message- From: jida...@jidanni.org [mailto:jida...@jidanni.org] Sent: Friday, January 23, 2009 12:16 To: Martin Dorey Cc: m...@packages.debian.org; bug-make@gnu.org Subject: Re

RE: Minor documentation bug

The link to the Errors in Commands section, http://www.gnu.org/software/make/manual/make.html#Errors, explains what the - is for. From: bug-make-bounces+mdorey=bluearc@gnu.org [mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Yakup Akbay Sent:

[bug #25697] Segmentation fault setting .DEFAULT_GOAL

Follow-up Comment #1, bug #25697 (project make): Can reproduce with latest make from CVS. ns is null at the penultimate line: 2175/* In case user set .DEFAULT_GOAL to a non-existent target 2176 name let's just enter this name into the table and let 2177

RE: Error 127

This is not a bug in make. It may be a problem with the makefile in question. Google has a number of matches for 'mpfr "no such file or directory"' although none of them grabbed my attention as relevant. I see there's an MPFR mailing list. That would be the best place to ask, if you've follo

RE: conditionals not working for conditional variables in sub-make?

You misunderstand something. > it outputs: > VAR=foo VAR2=bar VAR3=foo That's only a small fraction of what I see, with make-3.81. This is what I see: mart...@whitewater:~/tmp/bug-make-2009-05-07$ make make var1 make[1]: Entering directory `/home/martind/tmp/bug-make-2009-05-07' VAR=foo VAR

RE: conditionals not working for conditional variables in sub-make?

rsday, May 07, 2009 12:58 To: Martin Dorey Cc: bug-make@gnu.org Subject: Re: conditionals not working for conditional variables in sub-make? Hi, 2009/5/7 Martin Dorey : > That's only a small fraction of what I see, with make-3.81.  This is what I > see: > [...] > VAR=foo VAR2=bar VAR3=

RE: conditionals not working for conditional variables in sub-make?

st's effect. A thought experiment might help you to see the light. Imagine in the "all" rule, that instead of running "make var1", you ran "a-script-which-happens-to-invoke-make-var1". -Original Message- From: Szekeres István [mailto:szeke...@iii.h

RE: conditionals not working for conditional variables in sub-make?

n earlier phase of make's execution. It's not reevaluated for every target. At the time, and in the scope, when it was evaluated, $(VAR) was unset, hence empty. -Original Message- From: Szekeres István [mailto:szeke...@iii.hu] Sent: Thursday, May 07, 2009 14:50 To: Martin Dore

[bug #27374] fatal error reading included makefile silently ignored

Follow-up Comment #1, bug #27374 (project make): I see the error message: mart...@whitewater:~/playpen/make-27374$ make -f make.bug > /dev/null && echo success make.bug:1: make.bug: Too many open files success mart...@whitewater:~/playpen/make-27374$ The failure happens (for me) here in the st

RE: executing perl problem with make 3.81 versus 3.80

>From make's NEWS file for the 3.81 release: * WARNING: Backward-incompatibility! In order to comply with POSIX, the way in which GNU make processes backslash-newline sequences in recipes has changed. If your makefiles use backslash-newline sequences inside of single-quoted strings

RE: Splitting lines problem in make-3.80 versus 3.81

> All you have to do is use recursive assignment ("=") and NOT simple assignment (":="). The attachment did use =, making the coworker's assertion odder. The lack of need for target-specific variables can be illustrated with a simple example: mart...@whitewater:~/playpen/make-splitting$ ca

RE: debian:/usr/src/dahdi-linux-2.2.0.2#

> kann mir da bitte jemand weiter helfen Leide nicht. Ihre Problem ist irgendwo anders - es gibt keine Bug mit make(1) hier. Vielleicht koennen sie Hilfe finden auf einen Mailing Liste oder Website fuer "dahdi". (Wenn sie meinen schrecklichen Denglish verstehen koennen.) ___

[bug #27437] Problems with make in a directory with present Makefiles. make does not function.

Follow-up Comment #3, bug #27437 (project make): Neither makefile.am nor Makefile.in are usually makefiles. makefile.am is, as I understand it from eg the first google match for that file's name, used to generate Makefile.in. Makefile.in is used, as I understand it from eg the second google mat

RE: [bug #27809] several win64 fixes

> why can't you get rid of the cast altogether Because there is no implicit conversion from pointer to integer. > users of MinGW will then complain about compiler warnings, right? Because of an implicit conversion from unsigned int (the definition of uintptr_t on w32) to long, on a platform wher

RE: issue when using MAKEFILES variable

I'm having trouble understanding what you mean. When you've read my example below, if the lack of "hello from theconffile" output in the first run of make, and its presence in the second run, doesn't answer your question and show you how to solve the problem, then please modify my example to il

Re: issue when using MAKEFILES variable

for compiler bugs and, while I can attest that it's tedious work, it rarely takes longer than, say, an hour. - Original Message - From: jean-luc malet To: Martin Dorey Cc: bug-make@gnu.org Sent: Sat Oct 31 12:24:45 2009 Subject: Re: issue when using MAKEFILES variable Hi! thank

RE: not a bug but some strange behaviour

Can you contrive a simple test case - something that you can post here in its entirety to help someone reproduce the problem? -Original Message- From: bug-make-bounces+mdorey=bluearc@gnu.org [mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of jean-luc malet Sent: Monday

RE: not a bug but some strange behaviour

-- From: jean-luc malet [mailto:jeanluc.ma...@gmail.com] Sent: Monday, November 30, 2009 14:27 To: Martin Dorey Cc: bug-make Subject: Re: not a bug but some strange behaviour $cat make.bat set PATH=cygwin_Path;oldPath make %* $ cat /tmp/Makefile export TEST_FLAG=test SHELL=/bin/bash

debian/stamp/build/kernel) Fehler2

Perhaps the 2 corresponds to ENOENT, which means that a name wasn't found in a directory. mart...@whitewater:~/work/tiger$ sgrep ENOENT /usr/include/asm-generic /usr/include/asm-generic/errno-base.h:5:#define ENOENT2/* No such file or directory */ mart...@whitewater:~/work/ti

RE: Weird text-dependent bug in $(eval ...), simple test case

> (b) the messages are only produced for some words That's not the case for me, with Debian Lenny's 3.81. mart...@whitewater:~/tmp$ dpkg -S `which make` make: /usr/bin/make mart...@whitewater:~/tmp$ dpkg --status make ... Version: 3.81-5 ... mart...@whitewater:~/tmp$ make -f buggyMakefile buggyM

RE: Weird text-dependent bug in $(eval ...), simple test case

> completely reproducible without using $(eval)! "How", I wondered to myself, "is Philip defining multiple rules in one line without using $(eval)?". Eventually, I realized that the essence of one of the OP's allegations - the one we can reproduce - is that this, much simpler test case, demons

RE: Make manual update

> What's the most recent edition; @set EDITION 0.70 @set RCSID $Id: make.texi,v 1.64 2009/11/12 16:42:36 bosk Exp $ > where can I find an authoritative copy ? http://cvs.savannah.gnu.org/viewvc/make/doc/make.texi?revision=HEAD&root=make&view=markup Instructions for setting up a Cvs work area ar

RE: Static multiple target rules

> instead of a touch-file, use a tar-file ! Yeah, one of my company's makefiles uses a similar intermediate file to good effect. We've been using the touch-file or "sentinel" solution elsewhere for years. I'd previously suggested replacing the sentinels with tar files so we could get rid of a

Re: Bug

That isn't a problem with a makefile. That's a problem with main.cpp. I might guess that you should try changing iostream.h to iostream but that's only a guess out of goodwill. This mailing list isn't for helping with C++ problems. I don't know where you can turn for help. Perhaps wherever you g

RE: Shorter and less error-prone rule for automatic prerequisite generation in the GNU Make manual

>> If an update to new source code, that would compile just fine in a clean >> checkout, breaks the incremental build, the build system is errornuous. > I would like to agree with you, but this constraint is, in general, > incompatible with incremental building That's a entertainingly provocativ

[bug #30105] Recipes defined for special targets like .SUFFIXES are silently ignored: make should warn about them

Follow-up Comment #2, bug #30105 (project make): So ifeq (yes, yes) counts a "a blank line" because it evaluates to nothing? "a blank line" would be consistent with "next line that does not begin with a TAB", so that wording's not optimal. "next line that begins with something other than a TAB"

[bug #30105] Recipes defined for special targets like .SUFFIXES are silently ignored: make should warn about them

Follow-up Comment #4, bug #30105 (project make): (That explanation is clear, thanks. That'll teach me to search for TAB in capitals, as is used sometimes elsewhere in the manual.) ___ Reply to this item at:

Re: Installing GoogleEarth

You typed a space instead of a hyphen after "make". sudo make-googleearth-package --force sudo make googleearth-package --force Don't blush. If only all bug reports were so complete. From: bug-make-bounces+mdorey=bluearc@gnu.org To: bug-make@gnu.org Sent:

RE: source file extension

> define assert > $(call assert,$($ARGS), The variable "$ARGS" is null) > endef This code is dead - nothing calls it. I see that it includes an expression that will be evaluated (if it's ever called) as $(A)RGS when it was probably intended to say $(ARGS). > SRCS = $(wordlist 2, 999, $(ARGS))

[bug #31361] MinGW make inexplicably invokes as.exe

Follow-up Comment #8, bug #31361 (project make): If your bug isn't in make, then it doesn't belong in make's bug database, under any name. ___ Reply to this item at: ___

[bug #31361] MinGW make inexplicably invokes as.exe

Follow-up Comment #11, bug #31361 (project make): > I just thought a more appropriate name might help others in my position And it might well do. (I too can't see how to change the name.) I just feared that you were hoping that someone would look at a gcc issue here. > could you point me tow

[bug #32247] ../make/main.c:534: error: static declaration of ‘bsd_signal’ follows non-static declaration

URL: Summary: ../make/main.c:534: error: static declaration of ‘bsd_signal’ follows non-static declaration Project: make Submitted by: mdorey Submitted on: Tue 25 Jan 2011 09:20:18 PM GMT

RE: [bug #33134] spurious error when stdout is already closed

> maybe there's a better way of checking for closure than ftell http://software.jessies.org/svn/salma-hayek/trunk/native/all/ruby-launcher/ruby-launcher.cpp suggests: // This might look obscure but the man page suggests that it's a POSIX-compliant way // of testing whether a file descri

$(sort) - what is "lexical order"? (was RE: Follow-up)

OP has something of a point: contrast the locale-dependent behavior of sort(1) with make's $(sort): $ echo 'L:=$(sort B a)' | make -f - -p 2>&1 | grep '^L ' L := B a $ { echo B; echo a; } | sort a B $ { echo B; echo a; } | LC_ALL=C sort B a $ I present this more to provoke "we can't change that!

RE: $(sort) - what is "lexical order"? (was RE: Follow-up)

uot; | fmt -w1 | sort)'; echo 'L:=$(call strcoll,B a)'; } | make -f - -p 2>&1 | grep '^L ' L := a B martind@whitewater:~$ From: Rob Holbert [mailto:robholb...@gmail.com] Sent: Sunday, July 17, 2011 10:13 To: Martin Dorey Subject: Re: $(sor

RE: $(sort) - what is "lexical order"? (was RE: Follow-up)

Putting OP's reply on the record. From: Rob Holbert [mailto:robholb...@gmail.com] Sent: Tuesday, July 19, 2011 04:49 To: Martin Dorey Subject: Re: $(sort) - what is "lexical order"? (was RE: Follow-up) Wow, Just putting your sources in order y

RE: $(sort) - what is "lexical order"? (was RE: Follow-up)

er, +regardless of LC_COLLATE's value. @cindex removing duplicate words @cindex duplicate words, removing -Original Message- From: David Boyce [mailto:david.s.bo...@gmail.com] Sent: Tuesday, July 19, 2011 12:09 To: psm...@gnu.org Cc: Martin Dorey; robholb...@gmail.com; Bug-m

[bug #33958] Segfault in a 'define' with sort, foreach and newlines...

Follow-up Comment #1, bug #33958 (project make): I think the whitespace was preserved in the email to me. I could certainly reproduce the problem using the snippet from the mail in 3.82.90. But not in CVS. ___ Reply to this item at:

RE: Evaluation of shell functions in recipes

> if we just read the docs wrong, or if they *are* wrong. I don't think this is clearly explained in the docs. Suggest: Index: doc/make.texi === RCS file: /sources/make/make/doc/make.texi,v retrieving revision 1.72 diff -u -

RE: bug report : ERROR: dev-libs/lzo-2.06 failed (compile phase)

That's not a bug in make. It's a bug in whatever called make. You'd have to take that up with whoever maintains, what, lzo? They seem to have done: martind@whitewater:~$ make -j7-l7 make: the `-j' option requires a positive integral argument Usage: make [options] [target] ... When they probab

RE: [bug #33138] .PARLLELSYNC enhancement with patch

> They surely store the uncompressed size somewhere NTFS certainly stores that. It's the field referred to as "real" at eg http://ftp.kolibrios.org/users/Asper/docs/NTFS/ntfsdoc.html#id4793056. ("allocated" is what it says on the tin. "initialized" would be smaller than "real" if it's compre

RE: [bug #39028] [patch] fix and uniformize four error messages

> I think "integer" is meant instead of "integral". Eg C99 uses "integral" as an adjective meaning "of integers", per 1 b (1) from http://www.merriam-webster.com/dictionary/integral. My googling suggests that the OP's right, though, that the patched would be more widely understood. -Origin

RE: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

Frank wrote: > the two-step procedure (remove and ">>"). Woah, *truncate* and ">>". Removal wouldn't do the right thing for symlinks. > That said, I'm now going back to my own programs which redirect > stdout in forked child processes and add O_APPEND to O_TRUNC ... Me too! _

RE: Help:Stop compile due to Segmentation Fault Error

(Bcc: help-m...@gnu.org - this is definitely a make bug) Ø part of Makefile So not enough for us to try to repeat it. It looked vaguely familiar and Google turned up something similar, sadly with no obvious resolution: http://lists.gnu.org/archive/html/bug-make/200

RE: Help:Stop compile due to Segmentation Fault Error

> the problem is that Ubuntu (and Debian) ship a very outdated release of > GNU make The current, recent Debian stable, "Wheezy", ships with a version of make that it pleases Debian to call 3.81-8.2, per http://packages.debian.org/wheezy/make. Per the changelog link to http://ftp-master.metada

[bug #39709] a few typos fixes

Follow-up Comment #1, bug #39709 (project make): The patch looks good to me and I'm a picky native speaker. My one not-really quibble was why not also fix the "pattrn" targets in tests/scripts/features/patspecific_vars. I'm not seeing the reason why "pattern" has to be avoided, but it's unfamili

[bug #40159] Premature exit with incorrect error message, or garbage output characters.

Follow-up Comment #5, bug #40159 (project make): On a version (3.99.92) from Git the other day, the example's output ends with: Makefile:12: i Makefile:12: i make: Nothing to be done for 'dummy'. It exits with status zero. valgrind doesn't notice anything scary. With the make ("3.81-8")

[bug #40159] Premature exit with incorrect error message, or garbage output characters.

Follow-up Comment #6, bug #40159 (project make): Debian's make 3.81-8.2, from Wheezy and Sid, behaves like Squeeze, as does make-3.82 built on Debian via Paul's instructions here. ___ Reply to this item at:

[bug #40159] Premature exit with incorrect error message, or garbage output characters.

Follow-up Comment #9, bug #40159 (project make): I repeated all my tests with both makefiles. In all tests, they behaved like the original. So this is a bug that's been fixed here since 3.82. Debian has taken many patches from here but hasn't taken whichever one fixed this. Can we say which it

[bug #33034] "Makefile:23: *** mixed implicit and normal rules. Stop." for Linux kernel out of source builds

Follow-up Comment #19, bug #33034 (project make): The attached version of boyski's patch with, as Paul suggests, just the change from fatal to error and the addition of "warning: ", fixes the kernel eg 2.6.32-5 driver build problem I otherwise have with eg make-3.82, make-4.0. (I've been using a

RE: Excessive $(strip)

> this also removes the newlines. ... > IMHO make 4.x has a too strict definition of white-space. http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap07.html sayeth: "In the POSIX locale, at a minimum, the , , , , , and shall be included." Case closed? -Original Message- F

RE: Excessive $(strip)

bug-make-bounces+martin.dorey=hds@gnu.org [mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of Gisle Vanem Sent: Thursday, April 03, 2014 07:37 To: bug-make@gnu.org Subject: Re: Excessive $(strip) "Martin Dorey" wrote: >> this also removes the newline

RE: Excessive $(strip)

> I'd say that make itself is sloppy wrt whitespace, where sometimes > newlines are considered to be whitespace, othertimes not. ... > the "word" family of functions do not. Nice example. The source seems to draw a distinction between isblank, terminology available, I learn, in C99, and the more

Re: GNU make 4.0 crashes on Solaris 8

The vsnprintf thing was (probably) fixed in git under http://savannah.gnu.org/bugs/?40361. From: Tom Kacvinsky [mailto:tom.kacvin...@vectorcast.com] Sent: Thursday, April 17, 2014 07:23 AM To: Bug-make@gnu.org Subject: GNU make 4.0 crashes on Solaris 8 I have successfully built GNU make 4.0 on

RE: Make does not throw an error for target without a recipe?

> Why is it trying to build target test.mk...??? That's explained by https://www.gnu.org/software/make/manual/make.html#Remaking-Makefiles. > Then it decides it was successful? For some value of "successful". With your makefile: martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo

RE: Make does not throw an error for target without a recipe?

x27; is up to date. 0 martind@swiftboat:~/tmp/batrick-2014-06-26$ -Original Message- From: Patrick Donnelly [mailto:batr...@batbytes.com] Sent: Thursday, June 26, 2014 13:43 To: Martin Dorey Cc: bug-make@gnu.org Subject: Re: Make does not throw an error for target without a recipe? Hi Martin, On

RE: Make does not throw an error for target without a recipe?

nelly [mailto:batr...@batbytes.com] Sent: Thursday, June 26, 2014 14:06 To: Martin Dorey Cc: bug-make@gnu.org Subject: Re: Make does not throw an error for target without a recipe? On Thu, Jun 26, 2014 at 5:02 PM, Martin Dorey wrote: >> I'm afraid none of this exercise is helpful for solving t

RE: Buffer overflow in orig/implicit.c

3.82 isn't the latest. It looks like someone beat you to it: Differences between revisions 3f6bb04e75e5a02f23339c9d4bec99b22d430803 and 6405534814f04899890a2d932db9a4985fd772fe: 2012-02-26 21:34:51 + psm...@gnu.org (6405534814f04899890a2d932db9a4985fd772fe) Check for possible buffer overf

[bug #44660] possible buffer overflow?

Follow-up Comment #1, bug #44660 (project make): Reproduced on amd64 with up-to-the-minute make from git. valgrind reports things going south starting here: martind@swiftboat:~/tmp/make-44660$ valgrind ~/download/make-git/make ==30211== Memcheck, a memory error detector ==30211== Copyright (C) 2

[bug #44660] possible buffer overflow?

Additional Item Attachment, bug #44660 (project make): File name: strcache.c.take2.patch Size:0 KB ___ Reply to this item at: ___ Message sent

RE: Using hash instead of timestamps to check for changes.

> I spent a few hours trying to work out how to fake this up with a > secondary file whose "modified" time-stamp serves as "up-to-date" for > the primary it represents. I imagine we're not alone, but perhaps an existence proof would have some value: we have generic makefile code that provides thi

[bug #45211] Add option to MAKEFLAGS (How to set RM variable?)

Follow-up Comment #1, bug #45211 (project make): The claim being, I presume, that the second RM='' should either be RM='rm -f' or RM='rm', the latter only being the case if changing MAKEFLAGS takes effect implausibly quickly. It's the former with a Debian Wheezy make 3.81 (origin says "default"),

  1   2   3   4   >