On Sat, 2022-09-10 at 23:12 +0300, Fosil Crypto wrote:
> ubuntu@ip-172-31-95-154:~$ make ncdu gcc git jq chrony liblz4-tool -y
> make: invalid option -- 'y'
This is not a bug.
You are just invoking make incorrectly.
Ambrus Sumegi (21 March 2022 14:22) wrote:
> If the invocation is a function, i.e., `$(make,"external_target") |
> tee logs/external_task.log` then Make knows exactly where the call to
> the sub-make ends without having to parse a shell command. So, when
> running with the -n switch, it can simply
rget | tee logs/external_task.log"
and proceed to show the output of `make external_target -n`
-Original Message-
From: Paul Smith
Sent: 21 March 2022 14:18
To: Ambrus Sumegi ; bug-make@gnu.org
Subject: Re: GNU Make bug report: broken dry-run functionality with sub-make
invocations
On Mon,
(We generally prefer to use inline replies on the GNU lists, rather
than top-posted replies, thanks)
On Mon, 2022-03-21 at 13:22 +, Ambrus Sumegi wrote:
> If the invocation is a function, i.e., `$(make,"external_target") |
> tee logs/external_task.log` then Make knows exactly where the call to
On Mon, 2022-03-21 at 09:34 +, Ambrus Sumegi wrote:
> For the record, I’ve thought of a sort-of-solution to the “would you
> have Make parse the shell command” question over the weekend. If the
> sub-make was called through a function rather than a variable, the
> whole issue could be a lot mor
From: Martin Dorey
Sent: 17 March 2022 19:27
To: Ambrus Sumegi ; bug-make@gnu.org
Subject: Re: GNU Make bug report: broken dry-run functionality with sub-make
invocations
> the statement after the pipe also gets executed
Would you have Make parse the shell command, assuming that SHELL isn
On Fri, 2022-03-18 at 21:12 +, Lahfa Samy wrote:
> I've reported this bug anonymously :
> https://savannah.gnu.org/bugs/index.php?62200 and would like to
> receive updates/comments on it by mail on my Savannah account, I
> don't know if the bug report could be assigne
Hi,
I've reported this bug anonymously :
https://savannah.gnu.org/bugs/index.php?62200 and would like to receive
updates/comments on it by mail on my Savannah account, I don't know if
the bug report could be assigned to me or the "posted by" field could be
updated to my
> On Mar 18, 2022, at 2:03 PM, Paul Smith wrote:
>
> On Fri, 2022-03-18 at 17:48 +, Martin Dorey wrote:
>> Maybe putting it in the form of a patch on the latest git source will
>> help it over the finish line:
>
> I'm OK with adding some short text about this into the man page. As
> Davi
Paul Smith wrote:
I'm OK with adding some short text about this into the man page. As
David mentions it may be important enough to do that since command
being run by make even when the user gives "-n" could give unexpected
or even unpleasant consequences.
The most unpleasant consequences of u
On Fri, 2022-03-18 at 17:48 +, Martin Dorey wrote:
> Maybe putting it in the form of a patch on the latest git source will
> help it over the finish line:
I'm OK with adding some short text about this into the man page. As
David mentions it may be important enough to do that since command
bei
=\fIfile\fR
Do not remake the file
From: David A. Wheeler
Sent: Friday, March 18, 2022 09:08
To: Ambrus Sumegi
Cc: psm...@gnu.org ; Martin Dorey
; bug-make@gnu.org
Subject: Re: GNU Make bug report: broken dry-run functionality with sub-make
invocations
> On Mar 18, 2022, at 3:19 AM, Ambrus Sumegi wrote:
>
> Thanks a lot for your suggestions, Martin and Paul. I understand the
> reasoning behind why Make cannot improve this behavior, and the conditional
> execution of tee that you both proposed looks like a concise and elegant
> solution to
022 20:08
To: Ambrus Sumegi
Cc: bug-make@gnu.org
Subject: Re: GNU Make bug report: broken dry-run functionality with sub-make
invocations
On Thu, 2022-03-17 at 18:27 +, Martin Dorey wrote:
> That coped with -nj --no-print-directory on the one version of Make
> that I tested it with, but I do
On Thu, 2022-03-17 at 18:27 +, Martin Dorey wrote:
> That coped with -nj --no-print-directory on the one version of Make
> that I tested it with, but I don't know how portable that would
> prove.
Modern versions of make guarantee a canonical format of MAKEFLAGS such
that you can parse them rel
egi
Sent: Thursday, March 17, 2022 08:59
To: bug-make@gnu.org
Subject: GNU Make bug report: broken dry-run functionality with sub-make
invocations
* EXTERNAL EMAIL *
Dear Devs,
I stumbled upon a rather rare case where Make produces a false error with the
--dry-run switch. I’ve attac
Dear Devs,
I stumbled upon a rather rare case where Make produces a false error with the
--dry-run switch. I've attached a sample Makefile for reproduction.
The output of make main_target with this file is the following:
$ make main_target
mkdir logs
make external_target | tee logs/external_task.
t clear to me in a few minutes of googling where the right
place might be. Good luck.
From: Bug-make on behalf of
Sato Ryoma
Sent: Monday, January 10, 2022 15:53
To: bug-make@gnu.org
Subject: Bug report of Oyster River Protocol made by macmanes lab.
* EXTERNAL
Hello, my name is Ryoma Sato.
I am a second-year master's student at the Graduate School of Bioresources and
Environmental Sciences, Kyushu University in Japan.
I have started the Oyster River Protocol, but I found a bug, so I will send you
a report.
Please check the following information. I wou
On Wed, Mar 3, 2021 at 1:00 PM Goran V. wrote:
> Am Mittwoch, den 03.03.2021, 15:41 -0500 schrieb Paul Smith:
> > If by "a feature like that" you mean a way to create multiple pattern
> > rules with a single rule definition in the makefile, then obviously
> > this would require some new syntax bu
On Wed, 2021-03-03 at 22:00 +0100, Goran V. wrote:
> Am Mittwoch, den 03.03.2021, 15:41 -0500 schrieb Paul Smith:
> Yes, that is what I mean with "a feature like that". But I must say
> that I'm in no position to propose a patch as make is huge,
> http://git.savannah.gnu.org/cgit/make.git/tree/ .
Am Mittwoch, den 03.03.2021, 15:41 -0500 schrieb Paul Smith:
> If by "a feature like that" you mean a way to create multiple pattern
> rules with a single rule definition in the makefile, then obviously
> this would require some new syntax but assuming that syntax existed I
> don't see why it would
On Wed, 2021-03-03 at 21:32 +0100, Goran V. wrote:
> Maybe I was wrong to call this a bug but would a feature like that
> break anything?
If by "a feature like that" you mean a way to create multiple pattern
rules with a single rule definition in the makefile, then obviously
this would require som
Maybe I was wrong to call this a bug but would a feature like that
break anything?
Am Mittwoch, den 03.03.2021, 13:55 -0500 schrieb Paul Smith:
> On Wed, 2021-03-03 at 17:31 +0100, Goran V. wrote:
> > $(BUILD)/$(FRONTEND)/%.html \
> > $(BUILD)/$(FRONTEND)/%.js \
> > $(BUILD)/$(FRONTEND)/%.css \
On Wed, 2021-03-03 at 17:31 +0100, Goran V. wrote:
> $(BUILD)/$(FRONTEND)/%.html \
> $(BUILD)/$(FRONTEND)/%.js \
> $(BUILD)/$(FRONTEND)/%.css \
> $(BUILD)/$(FRONTEND)/%.svg \
> $(BUILD)/$(FRONTEND)/%.ico:
> @echo -n "$(FRONTEND) - building $@"
> @$(MD) $(BUILD)/$(FRONTEND)
>
I wrote a makefile with
$(BUILD)/$(FRONTEND)/%.html \
$(BUILD)/$(FRONTEND)/%.js \
$(BUILD)/$(FRONTEND)/%.css \
$(BUILD)/$(FRONTEND)/%.svg \
$(BUILD)/$(FRONTEND)/%.ico:
@echo -n "$(FRONTEND) - building $@"
@$(MD) $(BUILD)/$(FRONTEND)
@cp $(FRONTEND)/$(@F) $@
@ech
On Sun, 2017-03-19 at 01:51 +, Alejandro García Vallejo wrote:
> bar: $(@:%r=foo%z)
> @echo End
>
> foobaz:
> @echo The
>
> """
> GNU Make Output:
> End
>
> Make fails to read $@ (aka, it's empty).
That's not a bug; that's defined behavior. From the GNU make manual:
https:
Hi,
(NOTE: For details on versions used and whatnot see the end of the e-mail,
should apply to all of them, AFAIK.)
I know that this is a corner case, but given a Makefile such as this one:
"""
Makefile
"""
bar: $(@:%r=foo%z)
@echo End
foobaz:
@echo The
"""
GNU Make Output:
End
Hello
I downloaded the JunkyardJumbotron app. I am not able to run the project
for iOS. I am getting this error. "cp: /javascripts/phonegap.js: No such
file or directory". Also, it is written there to contact "bug-make@gnu.org".
I have installed PhoneGap and Cordova.I hope for your response.
Than
bug-make@gnu.org
Hello -
I believe I have found a bug in the online Internet web pages for "make".
I am looking at
http://www.gnu.org/software/make/manual/make.html#How-Make-Works
I see the following two paragraphs, each of which has the same basic error:
"Before recompiling an object
On Tue, 2014-08-12 at 14:48 +0800, clo...@gmail.com wrote:
> [root@localhost ~]# make --help
> -C DIRECTORY, --directory=DIRECTORY
> “在执行钱先切换到 DIRECTORY 目录。 ”
>
> should be
>
> “在执行前先切换到 DIRECTORY 目录。 ”
Hi;
Translations for GNU projects, including GNU make, are handled by the
Translation Pro
[root@localhost ~]# make --help
用法：make [选项] [目标] ...
选项：
-b, -m 忽略兼容性。
-B, --always-make 无条件 make 所有目标。
-C DIRECTORY, --directory=DIRECTORY
在执行钱先切换到 DIRECTORY 目录。
-d 打印大量调试信息。
--debug[=FLAGS] 打印各种调试信息。
-C DIRECTORY, --directory=DIRECTORY
“在执行钱先切换到 DIRECTORY 目录。 ”
should be
“在执行前先切换到
On Tue, 2013-01-29 at 14:42 +0100, Liang, Jian wrote:
> Make cannot handle the word or path that contains space.
You're right. The syntax of makefiles precludes this, and no version of
make supports it.
https://savannah.gnu.org/bugs/?712
___
Bug-mak
Hi,
Make cannot handle the word or path that contains space.
Here's a sample: (tested on 3.81 and 3.82)
--
INC=aa/hdr bb/hdr cc\ mgr/hdr
INC_FLAG=$(addprefix -I,$(INC))
N=$(words $(INC))
all: test
@echo INC_FLAG="$(INC_FLAG)"
@echo N=$(N)
test: $(INC)
On Wed, 25 Apr 2012 20:30:41 -0400, Paul Smith wrote:
On Thu, 2012-04-26 at 00:19 +, Christophe Poncy wrote:
I have a have a bug during the compile phase of my Funtoo GNU/Linux
box. I was trying to emerge the 'boot-update' package, it seems
there
is a problem for compiling one of its depen
On Thu, 2012-04-26 at 00:19 +, Christophe Poncy wrote:
> I have a have a bug during the compile phase of my Funtoo GNU/Linux
> box. I was trying to emerge the 'boot-update' package, it seems there
> is a problem for compiling one of its dependency (lzo ).
[...]
> >>> Compiling source in
>
ces+martin.dorey=hds@gnu.org] On Behalf Of Christophe
Poncy
Sent: Wednesday, April 25, 2012 17:19
To: bug-make@gnu.org
Subject: bug report : ERROR: dev-libs/lzo-2.06 failed (compile phase)
Hi,
I have a have a bug during the compile phase of my Funtoo GNU/Linux
box. I was trying to emerge the &
Hi,
I have a have a bug during the compile phase of my Funtoo GNU/Linux
box. I was trying to emerge the 'boot-update' package, it seems there is
a problem for compiling one of its dependency (lzo ).
Here is the complete build log :
# cat /var/tmp/portage/dev-libs/lzo-2.06/temp/build.log
* P
PS> however, and so I wouldn't expect people to think that messages to
PS> that list would become bug reports and automatically acknowledged, a
PS> la Debian's BTS etc.
Anyways from all the GNU man pages (but not exactly make's, true, but we
just remember bug-make@gnu.org anyway and wouldn't check
mail
> received, like Debian does.
>
> Anybody reading this?
> Anybody get this?
If you want a bug report to be filed and acknowledged, then you want:
https://savannah.gnu.org/bugs/?func=additem&group=make
The FSF does not use an email-based bug tracker, like Debian; we use
Savanna
On Thu, 2011-04-14 at 08:57 +0800, jida...@jidanni.org wrote:
> >>>>> "PS" == Paul Smith writes:
> PS> If you want a bug report to be filed and acknowledged, then you want:
> PS> https://savannah.gnu.org/bugs/?func=additem&group=make
> Thanks for a
>>>>> "PS" == Paul Smith writes:
PS> If you want a bug report to be filed and acknowledged, then you want:
PS> https://savannah.gnu.org/bugs/?func=additem&group=make
Thanks for answering! Well that's not the advertised way to submit bugs.
You advertise bu
I noticed that when submitting bugs to bug-*@gnu.org, unlike other bug
submission by mail systems, e.g., Deb bugs of Debian, the user receives
no cheery auto reply acknowledging the bug was ever even received and
didn't go into a black hole, or expecting the user to dig out what
happened to his sub
erform wildcard expansion when
the command runs."
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Harald
Bergmann
Sent: Tuesday, October 07, 2008 07:10
To: bug-make@gnu.org
Subject: Bug report for "make" documentation
Dear developer,
at
Dear developer,
at the PDF documentation of "make", which I currently loaded from your web
side the following is found at top of page 25:
---
Wildcard expansion is performed by make automatically in targets and in
prerequisites.
In commands the shell is responsible for wildcard expansion. In oth
On Thu, Jun 26, 2008 at 10:43 PM, Eli Zaretskii <[EMAIL PROTECTED]> wrote:
>> Date: Thu, 26 Jun 2008 14:44:38 +0400
>> From: "Vitaly Murashev" <[EMAIL PROTECTED]>
>> Cc: bug-make@gnu.org
>>
>> > . It doesn't add an explicit drive letter to file names such as
>> >"/foo/bar", and generally treat
> Date: Thu, 26 Jun 2008 14:44:38 +0400
> From: "Vitaly Murashev" <[EMAIL PROTECTED]>
> Cc: bug-make@gnu.org
>
> > . It doesn't add an explicit drive letter to file names such as
> >"/foo/bar", and generally treats such names incorrectly.
>
> You are right, and i suppose that the best way is
Vitaly Murashev wrote on 26 June 2008 11:45:
>> . It doesn't produce fully qualified file names from drive-relative
>>names such as "d:foo/bar".
>
> Not really. My patch produces the same output for "d:foo/bar"
> and for "d:/foo/bar", the result is "d:/foo/bar"
That's a mistake, because t
On Wed, Jun 25, 2008 at 9:37 PM, Eli Zaretskii <[EMAIL PROTECTED]> wrote:
>> Date: Wed, 25 Jun 2008 20:19:39 +0400
>> From: "Vitaly Murashev" <[EMAIL PROTECTED]>
>>
>> I found a bug in GNU Make 3.81 on MS Windows. So let me discuss it and
>> suggest a patch.
>
> Thanks. Your code is generally OK,
> Date: Wed, 25 Jun 2008 20:19:39 +0400
> From: "Vitaly Murashev" <[EMAIL PROTECTED]>
>
> I found a bug in GNU Make 3.81 on MS Windows. So let me discuss it and
> suggest a patch.
Thanks. Your code is generally OK, but, unless I'm missing something,
it has a few deficiencies:
. It doesn't add
Hello, FSF community.
I found a bug in GNU Make 3.81 on MS Windows. So let me discuss it and
suggest a patch.
The problem take place in function abspath when trying to expand paths
which are already full qualified.
makefile for test is the next:
---
$(info test - $(abspath C:/))
$(info test - $(a
Hi,
i cant install most of the packages, "make" doesnt work "no C compilers".
Im jus a beginner Linux user, please help, i wanna install VPN cisco client,
which im unable to do to access inet.
cheers
abhishek
-
You rock. That's why Blockbuster's offering
Hello,
the GNU GCC and Binutils packages have the following feature: when
compiled for cross compilation, e.g., for
TARGET=arm-none-eabi
they are compiled with the names $TARGET-gcc, $TARGET-nm, etc. Various
programs such as the compiler driver, the linker etc. automatically
change their
utlook, BlueArc Engineering
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence W.
Thorne
Sent: Sunday, July 09, 2006 16:28
To: bug-make@gnu.org
Subject: Bug Report (SUN Sparc Kernel-2.4)
Following your directions (Gentoo handbook)
Installing N
Following your directions (Gentoo handbook)
Installing Necessary System Tools (Section 9)
At 9.a. Device Manager:
udev is not available for unmerging and when I attempt to
merge devfsd I get the following error/bug
!!! ERROR: sys-fs/devfsd-1.3.25-r9 failed.
!!! Function src_c
Hi,
I find a bug for creating make.exe
in windowns,
It can't get make.exe when compiling
in windowns.
I have resolved this bug as followed:
edit the NMakefile , add "$(OUTDIR)/hash.obj"
in the file,
for example
OBJS = \
$(OUTDIR)/ar.obj
\
$(OUTDIR)/arscan.obj
\
$(
> Date: Tue, 20 Jan 2004 21:47:21 -0500
> From: "Paul D. Smith" <[EMAIL PROTECTED]>
>
> In Windows and DOS, the COMMAND.COM works differently in that the
> current working directory value is global, to some extent, so any change
> to it, in any process, effects future processes.
Actually, it's no
> From: "Gerd Igelmann" <[EMAIL PROTECTED]>
> Date: Tue, 20 Jan 2004 20:14:27 +0100
>
> all:
> cd test
> dir > content.txt
> cd ..
>
> Make 3.76.1 does the change of directory as expected, make 3.79.1 does not
As Paul points out, this is most probably a shell issue, not a Make
%% "Gerd Igelmann" <[EMAIL PROTECTED]> writes:
gi> for more then 5 years we used the GNU Make version 3.76.1 at PCs
gi> with OS Win98. Now we changed to GNU Make version 3.79.1 which
gi> comes with the mingw32 Compiler. Since this time we are not able
gi> to run the old makefiles of alre
Dear Madams and Sirs,
for more then 5 years we used the GNU Make version 3.76.1 at PCs with OS
Win98.
Now we changed to GNU Make version 3.79.1 which comes with the mingw32
Compiler.
Since this time we are not able to run the old makefiles of already existimg
projects.
The result for the followin
%% "Sandeep Nema" <[EMAIL PROTECTED]> writes:
sn> has been set in any way, including to the empty value
OK.
sn> You mentione in your previous answer that "?:" is not supported
sn> syntax, shouldn't it give any kind of error if its used in the
sn> makefile.
Just because the syntax doesn
please see my response/clarification below in bold with >
>>> "Paul D. Smith" <[EMAIL PROTECTED]> 01/05/04 10:08AM >>>
%% "Sandeep Nema" <[EMAIL PROTECTED]> writes:
sn> GNU make version: 3.80
sn> O/S: AIX 5.0
sn> We used "?:" macro substitution on tru64 platform with their
make, and
%% "Sandeep Nema" <[EMAIL PROTECTED]> writes:
sn> GNU make version: 3.80
sn> O/S: AIX 5.0
sn> We used "?:" macro substitution on tru64 platform with their make, and
sn> it works as following:
sn> X= $(EXCLUDE_X?:$(TMP_ADD_X))
sn> in the above if EXCLUDE_X is defined then X will be e
sorry about incomplete bug-report. Following are the details and further
questions.
GNU make version: 3.80
O/S: AIX 5.0
We used "?:" macro substitution on tru64 platform with their make, and
it works as following:
X= $(EXCLUDE_X?:$(TMP_ADD_X))
in the above if EXCLUDE_X is defined t
%% "Sandeep Nema" <[EMAIL PROTECTED]> writes:
sn> In one of my makefile, I have following conditional syntax:
sn> ADDONS_DB_C = $(EXCLUDEFWKLIB?:$(TMP_ADDONS_DB_C))
sn> This gives me an error for MACRO SUBSTITUTION
First, this is not a proper bug report.
In one of my makefile, I have following conditional syntax:
ADDONS_DB_C = $(EXCLUDEFWKLIB?:$(TMP_ADDONS_DB_C))
This gives me an error for MACRO SUBSTITUTION
Thanks,
Sandeep Nema
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/
%% Regarding Bug report & solution: make-3.80: Win32 linking error.; you
%% wrote:
n> It seems that script for assembling binaries of make-3.80 GNU make
n> utility for Win32 platform is incorrect.
This problem has been reported and fixed, and the fix will be available
in the next
Hello!
It seems that script for assembling binaries of make-3.80 GNU make
utility for Win32 platform is incorrect.
PROBLEM
The problem occures when one launches the "build_w32.bat" script with
all other settings made according to the README.
There are messages about unresolved ext
On Sat, Jun 14, 2003 at 01:59:46PM +0400, Aleksej Mazunin wrote:
> Hello!
> I have a problem when trying to make Brahms application.
> Logfiles are attached.
Could you please attach them as plain text files.
Neither gunzip nor bunzip2 understand the format of the .zip file
you have attached.
May
Hello!
I have a problem when trying to make Brahms application.
Logfiles are attached.
Source file name is "brahms-1.02-kde3.tgz".
Say please, what can i do to avoid this problem?
With respect,
Aleksej.
June 13, 2003
Brahms-logs.zip
Description: Zip archive
Hi,
You didn't send the full makefile, since the includes are missing.
Make apparently is considering the line "$(QuellP)/CnGET.h" a command to be
executed, where CnGET.h probably doesn't have execute permissions.
Look for the _exact_ definitions of variables like 'QuellP' and 'StreaP'
(including
Hi, I have a problem with one single line in a Make-File that I cannot
figure out at all. The problem is the same under version 3.77 and
3.79.1 under Linux.
The errro message is as follows:
make: execvp: ../CnGET.h: Keine Berechtigung
make: *** [../CnGET.h] Fehler 127
The version info:
GNU Mak
Hi, thanks for your reaction.
I understand that the most sensible thing for us to do is to upgrade. I
will do so and see whether the problem persists.
More later,
best regards Willi Doeringer
On Mon, 16 Dec 2002, Johan Bezem wrote:
> Please keep the mails on the list (reply-to set).
>
> To star
Please keep the mails on the list (reply-to set).
To start with, I just need the regular stdout from a normal call to make,
using the problematic version, possibly with a binary correct (as
attachment) version of the problematic makefile. If I need more, I'll shout.
But then again: make version 3
The makefile looks quite normal and simple to me. Executing the *.h file
could have resulted from:
- a missing/extraneous tab in the wrong place, or
- a missing/extraneous line continuation character.
Otherwise, please provide the makefile that produces the error (as this one
apparently is not), a
Hi, there is a problem with make I cannot figure out at all. Hence I send
you the make-file causing the headaches. I am more than happy to supply
further information or give you access to my machine to do further tests.
Best regards, W. Doeringer
PS.: Otherwise, I have been using make for years an
I use cygwin on windows2000 server and I install arm-elf-gcc for cygwin.
$ arm-elf-gcc -v
Reading specs from /usr/local/cross-gcc/arm-elf//lib/gcc-lib/arm-elf/3.0/specs
Configured with: ../gcc-3.0/configure=
--prefix=3D/usr/local/cross-gcc/arm-elf/ --t
arget=3Darm-elf --with-newlib --enabl
I'm sorry, but first you're using Cygnus GNU make which is not identical
to the standard GNU make provided by the GNU project; you need to direct
your problem to Cygnus/Red Hat.
Second, unfortunately we don't have the resources at GNU to handle
Windows-specific issues; certainly we can't do anyth
Hello.I found a bug. (I think it may be a bug.)I use Cygnus make.exe on MS Window 2000.Dumping stack errors have occured in my PC.So, I'd like to report the error statusWhen you succeed solving the problem, reply with a mail to explain how to fix it, please...Have a good day...Bye...OS: MS Wind
%% Francis Grolemund <[EMAIL PROTECTED]> writes:
fg> In any case, we ran into a subtle bug that was partially caused by
fg> our environment and how we've used gnumake, but I figured that
fg> since its such a pain in the ass, you guys may want to know about
fg> it. The problem is only occ
52 PM ---
Francis Grolemund
07/16/2001 09:47 PM
To: [EMAIL PROTECTED]
cc:
From: Francis Grolemund/Pittsburgh/IBM@IBMUS
Subject: bug report
I'm sorry this isn't in the proper bug reporting format, but time is pretty
critical right now on our project.
In any case, we ran into a subt
I'm sorry this isn't in the proper bug reporting format, but time is pretty
critical right now on our project.
In any case, we ran into a subtle bug that was partially caused by our
environment and how we've used gnumake, but I figured that since its such a
pain in the ass, you guys may want to k
Hi, I am not sure if this is a problem with gmake or
makedepend. Please let me know. Thanks.
--
sape(122)% gmake -n
cc -c ../include.h
sape(123)% cat Makefile
VPATH = ..
gated_trace.o: gated_trace.c
$(CC) -c $<
# DO NOT DELETE
../gated_trace.o: ../inclu
I believe this is an instance of a problem I've fixed for the next
version of GNU make, which should be appearing fairly soon.
If you like I can add you to the pretest list, if you want to try it and
see if it solves your problem.
--
-
77, and was
compiled from source that I downloaded from the prep.ai.mit.edu site.
A tarball containing another copy of the same makefile, and my config.h
is enclosed. I hope outlook sends it out in MIME format.
I hope this bug report helps.
Thanks,
Dean Fitzgerald
make_report.tar
85 matches
Mail list logo
