On Fri, 2023-10-13 at 13:13 +0530, Nachiketa Gupta wrote:
> Hi All,
> MAKE version 3.8
> So my question is why does it always print -j independent of -j
> value?
> is some make.conf file located in our area which is overriding this
> variable with -j?
> I have also confirmed that with the 4.3 vers
Hi All,
MAKE version 3.8
I am facing some issues with Makefile :
[image: 6f8cecfc-ceda-487f-8150-07aaf4239d73.png]
So my question is why does it always print -j independent of -j value?
is some make.conf file located in our area which is overriding this
variable with -j?
I have also confirmed
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 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.
ot contain the "FOO=foo".
>
> Environment variables from outside the Makefile seem to be inherited
> just fine.
>
>
> --
> Erich Stefan Boleyn http://www.duckytech.com/
>
> _______
> Bug-make mailing list
On Tue, 2015-02-10 at 10:35 -0800, Erich Boleyn wrote:
> Summary:
> Environment variables set in the Makefile do not get inherited
> into anything run via the "shell" subcommand.
Yes, this is known:
https://savannah.gnu.org/bugs/index.php?35323
_
Summary:
Environment variables set in the Makefile do not get inherited
into anything run via the "shell" subcommand.
Tested on GNU Make versions:
3.81 (on Ubuntu)
4.1 (on FreeBSD)
Example Makefile contents which can show the bug:
export FOO=foo
mai
Update of bug #35397 (project make):
Status:None => Fixed
Assigned to:None => psmith
Open/Closed:Open => Closed
Fixed Release:
URL:
<http://savannah.gnu.org/bugs/?35397>
Summary: make bug with ONESHELL and SHELLFLAGS
Project: make
Submitted by: boyski
Submitted on: Sun 29 Jan 2012 08:22:36 PM GMT
Severity: 3 - Normal
Item Grou
2:43 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: bug-make@gnu.org
Subject: Re: make bug with ONESHELL and SHELLFLAGS
I believe the patch below would fix this. It's up to Paul of course whether he
considers it a bug and considers the patch worthy. The only concern I have with
it is that th
a single value,
> i.e. –ec.
>
>
>
> I am using
>
>
>
> Michael Rytting
>
> Agilent Technologies
>
> michael_rytt...@agilent.com
>
> 719-590-3708
>
>
>
>
> ___
> Bug-make mailing list
> Bug-make@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-make
>
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Sorry if this has already been reported but I haven't found anything searching
through the archives.
SHELL = /bin/bash
.SHELLFLAGS = -e -o pipefail -c
Works
.ONESHELL:
SHELL = /bin/bash
.SHELLFLAGS = -e -o pipefail -c
Doesn't
When the ONESHELL target is set .SHELLFLAGS must be set to a single
On Sun, 2010-11-28 at 13:14 +0100, Sergio Villone wrote:
>you ill find in the allegate a directory containg a possible guilty
> makefile (prova), a text file f the result of running this makefile
> and a text file (comment) explaining the misleading results
Hi Sergio; in the future we prefer i
you ill find in the allegate a directory containg a possible guilty
makefile (prova),
a text file f the result of running this makefile and a text file (comment)
explaining the misleading results
thanks for your attention,
Sergio Villone
--
sv
possible_make_bug.tar.gz
Description: GNU Zip c
On 19 October 2007 11:52, Jon Grant wrote:
> Hi,
>
> [...]
>> /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
>> prorex.o: relocation R_X86_64_32 against `a local symbol' can not be
>> used when making a shared object; recompile with -fPIC
>> prorex.o: could not read
Hi,
[...]
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
prorex.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
prorex.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
mak
Hi
I sent a report about a bug but forgot the link to the actual
product. Sorry this is the link
http://www.mirrorservice.org/sites/ftp.sourceforge.net/pub/sourceforge/c/ch/chwp/
The error I get upon trying to make is
/tmp/prorex-1.3 # make
gcc -g -Wall -D__USE_F
%% Michael Matz <[EMAIL PROTECTED]> writes:
mm> Ah, right, good idea. Btw. funnily I can't reproduce the effect
mm> of the deferred output on one of the machines even with your
mm> makefile. The child is left running, but the echo "ok done" is
mm> missing, probably because the parent mak
Hi Paul,
On Sun, 7 Aug 2005 [EMAIL PROTECTED] wrote:
> Thanks for a most excellent bug report! I was able to easily follow the
> path you described and see the bug. I used essentially your fix (with a
> few minor syntactic tweaks).
Nice.
> FYI, following your notes I was able to produce a mak
Hi Michael;
Thanks for a most excellent bug report! I was able to easily follow the
path you described and see the bug. I used essentially your fix (with a
few minor syntactic tweaks).
FYI, following your notes I was able to produce a makefile which is
guaranteed to show the bug every time, reg
Hi,
[please keep me CCed, I'm not subscribed to bug-make]
I've noticed the problem with make 3.80 during building GCC. I can
reproduce it with a small makefile, also with current CVS of GNU make.
First I describe the symptoms, and then the bug. The former is a bit
long, so you might skip to
Oh whoops, I see you already tried with the latest CVS code; sorry I
missed that the first time.
OK, thanks, I'll take a look.
--
---
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gn
Hi Michael;
Can you please test this with the latest beta version of make? A number
of fixes to the jobserver code have been made in that version:
ftp://alpha.gnu.org/gnu/make/make-3.81beta3.tar.gz
or
ftp://alpha.gnu.org/gnu/make/make-3.81beta3.tar.bz2
Thanks!
--
--
%% Pierre B <[EMAIL PROTECTED]> writes:
pb> The problem is with the backquote AND/OR addprefix.
pb> The following makefile illustrates the bug.
I think you're misunderstanding something basic here.
Make does not process backquotes. The shell processes backquotes. Make
only processes functi
The problem is with the backquote AND/OR addprefix.
The following makefile illustrates the bug.
Notice the doubled ././ in the test output.
Version information is in the output.
#
# Make file illustrates a problem with back quote
# by juxtaposing results with back quote and shell
#
#
nice_string:=$
As requested by Mr. Paul Smith.
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
%% David Buehler <[EMAIL PROTECTED]> writes:
db> I'm expecting this makefile to echo "mylib", but it echos
db> "Makefile" then "mylib"... perhaps there's something esoteric
db> going on that I haven't figured out from the documentation.
The latter :).
Check the GNU make manual section "How
I'm expecting this makefile to echo "mylib", but it echos "Makefile" then
"mylib"... perhaps there's something esoteric going on that I haven't
figured out from the documentation.
Running on Debian GNU/Linux Stable. I installed make version 3.80 just to
check that the behavior is the same as 3.79
This looks like an instance of bug #775:
https://savannah.gnu.org/bugs/?func=detailbug&bug_id=775&group_id=71
--
---
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org
On a Pentium 4, using Windows 2000 (service pack 3) and cygwin.
-
$ uname -a
CYGWIN_NT-5.0 ALPHA 1.3.17(0.67/3/2) 2002-11-27 18:54 i686 unknown
-
$ make -v
GNU Mak
%% Tim Noell <[EMAIL PROTECTED]> writes:
tn> Attached please find gnumakebug.tar.gz, containing my minimum
tn> example.
Offhand I'd prefer the files to be attached outside of a compressed tar
file, unless they're large; it's much simpler to read them in your email
than it is to save off the
Hi GNU Make Team:
I have encountered a situation with GNU Make that doesn't seem right. It could
be something simple that I am overlooking, but wanted to forward the example so
you folks could check it out.
Attached please find gnumakebug.tar.gz, containing my minimum example.
I am running G
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
Paul:
Thank you very much. I will try 3.79.1 to see what happens. Wind River
Systems technical support engineer is using 3.79 and it seems to resolve
the problem.
- Abe
"Paul D. Smith" wrote:
> GNU make does support Windows, but not at version 3.74.
>
> Support for Windows was not added until
GNU make does support Windows, but not at version 3.74.
Support for Windows was not added until version 3.75.
If you have a version of GNU make for 3.74 on Windows it must be part of
the Cygnus package: that version of GNU make is slightly different than
the standard GNU version and you need to
To Whom It May Concern:
This problem only appears in WindowsNT GNU make. If GNU make does
not support WindowsNT, please just indicate so.
I am using Wind River Systems (www.windriver.com) Tornado software which
employes GNU make as well as other GNU tools. I am using it in WindowsNT
platform.
The patch I believe you refer to is below.
I couldn't reproduce your second problem, with $@. If you can construct
a test case that reliably reproduces it, I'm interested. Thanks.
--- make-3.79.1/job.c Fri Jun 23 11:54:56 2000
+++ make/job.c Wed May 2 01:17:08 2001
@@ -895,8 +895,14 @@
Back in April I sent the following message to [EMAIL PROTECTED] I believe a
patch was developed although I don't have it. How can I get the patch?
"The attached make file should echo the command "echo dummy compile"
when make is invoked as "make _ECHO=". It does not. As is noted by Mike
Evan
%% Luke <[EMAIL PROTECTED]> writes:
l> I'm still a new guy to linux, but whenever i try to 'make' a file,
l> eg 'Make install' I get the error "Makefile:3:: *** missing
l> separator. Stop."
There's a section in the GNU make manual on error messages which will
explain it.
This is GNU make
Hi,
I'm still a new guy to linux, but whenever i try to 'make' a file, eg 'Make
install' I get the error "Makefile:3:: *** missing separator. Stop."
Why would this be?
Looking forward to your reply
Luke Stanbury
___
Bug-make mailing list
[EMAIL
%% Agnes Voisard <[EMAIL PROTECTED]> writes:
av> Hi I try to install emacs under redhat 6.2 I got emacs-20.5.rpm
av> but to install it I need make.
av> I hence tried to install make. I got make-3.78.1.rpm and I try to
av> install it.
If you get a binary RPM, you don't need to compile i
Hi
I try to install emacs under redhat 6.2
I got emacs-20.5.rpm
but to install it I need make.
I hence tried to install make.
I got make-3.78.1.rpm
and I try to install it.
Unfortunately I get the following message:
[root@redhat make-3.78.1]# sh build.sh
compiling main.c...
In file included fr
%% "P. Jeffrey Ungar" <[EMAIL PROTECTED]> writes:
pju> If a command for a rule is a submake, but the command is
pju> contained in a variable, then it can't run the submake in
pju> parallel. You get an error message:
pju> gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to pa
If a command for a rule is a submake, but the command is contained in a
variable, then it can't run the submake in parallel. You get an error
message:
gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to parent
make rule.
Here is a sample Makefile that shows the problem (for all vers
57 matches
Mail list logo
