virtual memory exhausted

[jagabandhu panda]

Dear Sir,
 
While compiling an atmospheric model it says
 
Entering the directory /directory path
make[3] *** virtual memory exhausted. StopLeaving the directory /directory path 
I came to know that this is a bug. I am using gnu-make. Please help me out to solve this problem.
 
regards,
-- Jagabandhu#Jagabandhu PandaSenior research fellowCentre for Atmospheric SciencesIIT DelhiHauz KhasNew Delhi-110016Ph:(011)2659-6052(lab), 6911(hostel)
# 
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

[Boris Kolpackov]

Follow-up Comment #1, bug #15919 (project make):

> This one looks like it's going to be a big PITA to fix.

Do you have any thoughts on why it hangs when we use the implicit rule and
does not when we use a normal one. After instantiation of the implicit rule,
the two cases should be equivalent.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

[anonymous]

URL:
  

 Summary: Make-3.81 rc1 hangs with -j 2 but not with -j 1
 Project: make
Submitted by: None
Submitted on: Mon 02/27/06 at 18:38
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
   Component Version: CVS
Platform Version: Any
   Fixed Release: None

___

Details:

Running make-3.81rc1 with the attached makefile will hang if "-j 2" is
specified, but will run properly if "-j 1" is selected instead.  To
duplicate, put the attached makefile into a blank directory.  Running with
"touch test.0 && make -j 2" runs properly the first time and produces:

touch test.1
touch test.2
touch test.3
touch test.int
touch test.4
rm test.int

Running "touch test.0 && make -j 2" again hangs repeatably part-way through:

touch test.1
touch test.2

Running instead with "touch test.0 && make -j 1" repeatably produces the same
output as the first run.  Note that if "test.int" is touched externally, so
that's it's pre-existing, then "-j 2" works properly.  Deleting "test.int"
and retrying will hang.

I have reproduced this under both Windows and Unix, and on single and
dual-processor systems.






___

File Attachments:


---
Date: Mon 02/27/06 at 18:38  Name: makefile  Size: 176B   By: None
Test case makefile


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

[Paul D. Smith]

Follow-up Comment #2, bug #15919 (project make):

Not offhand.  I haven't looked at it carefully enough.  I did spend about 10
mins: just enough to verify that I can reproduce it.  I also enabled
debugging and I can see that it's looping forever, not just hanging.  Make
seems to think that it's already started the rules to build the
prerequisites, but they never complete so it continues to loop trying to
build them.  It was a few days ago so I don't remember the details.  I'm
super-swamped with "real work" right now but my plan was to set a breakpoint
at the start of the _first_ entry to build "test", then follow along and see
how it gets into this state.  Since you've discovered that removing
.SECONDARY will fix the problem, debugging the two alongside one another (one
debug session with a makefile with .SECONDARY and one without) will also be
helpful, I expect.  If I had to guess I'd say it's a bizarre interaction
between .SECONDARY and order-only prerequisites... I guess that much is
obvious given what you've discovered.  The bug does still happen if you use
"-rR" options to make, which will significantly cut down on the amount of
irrelevant work make will have to do (and the number of loops you'll have to
walk through).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15719] Make jobserver feature not supported on WINDOWS32 platforms

[greg keranen]

Follow-up Comment #4, bug #15719 (project make):

I don't know if my experience of failure under Cygwin should be considered a
separate bug, since it seems that you all seem to be saying that parallelism
works under Cygwin but not under cmd.exe

It does NOT work reliably under Cygwin, in my experience.

I have so far reproduced the success of all 6 tests about 4 times and the
failure twice:
features/parallelism  FAILED (5/6
passed)

It is only TEST #5 which fails, but with somewhat different output; my guess
is that creating load conditions, running other applications like video,
while the test is running, helps reproduce the failure. 

I don't pretend to understand the deeper issues here but my guess is that
there is nothing you can do about it since Cygwin depends ultimately on
windows threading which is probably somewhat uncontrollable, at this level. 

Comments from the test script concerning this case:
# Michael Matz <[EMAIL PROTECTED]> reported a bug where if make is running 
in
# parallel without -k and two jobs die in a row, but not too close to
each
# other, then make will quit without waiting for the rest of the jobs to
die.

--- BEGIN FILE:  work/features/parallelism.diff.4
*** work/features/parallelism.base.4Wed Mar  1 13:03:39 2006
--- work/features/parallelism.log.4 Wed Mar  1 13:03:39 2006
***
*** 4,8 
  Fail
  make: *** [fail.2] Error 1
  Fail
- make: *** [fail.3] Error 1
  Ok done
--- 4,8 
  Fail
  make: *** [fail.2] Error 1
  Fail
  Ok done
+ make: *** [fail.3] Error 1

--- EOF

--- BEGIN FILE:  work/features/parallelism.diff.4
*** work/features/parallelism.base.4Wed Mar  1 13:45:39 2006
--- work/features/parallelism.log.4 Wed Mar  1 13:45:39 2006
***
*** 1,8 
  Fail
  make: *** [fail.1] Error 1
  make: *** Waiting for unfinished jobs
- Fail
  make: *** [fail.2] Error 1
  Fail
- make: *** [fail.3] Error 1
  Ok done
--- 1,8 
  Fail
+ Fail
  make: *** [fail.1] Error 1
  make: *** Waiting for unfinished jobs
  make: *** [fail.2] Error 1
  Fail
  Ok done
+ make: *** [fail.3] Error 1

--- EOF

--- TEST ENVIRONMENT:
GNU Make 3.81rc1 on CYGWIN_NT-5.1 x2 1.5.19(0.150/4/2) i686
NOTE: I compiled make from sources, using gcc under cygwin/bash
--- SYSTEM:
OS: Windows XP (SP2; +all current patches)
CPU: AMD Athlon 64 X2 4400+
Board: ASUS A8N-SLI Premium (nVidia nForce 4 SLI chipset)


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15718] Weird behavior of the SHELL variable on Win32

[Agent Zhang]

Follow-up Comment #12, bug #15718 (project make):

> P.S. In general, I think that setting SHELL to anything but a
> shell, either cmd.exe or some version of Unixy shell, is
> playing with fire

If I'm not misunderstanding you, the Win32 build of GNU make 3.81rc is
supposed to work with cmd.exe, right? But surprisingly it does NOT work at
all on Windows XP!

I'm shocked when I see the following (I'm sure you all will too):

D:\>cmd /C "echo hello"
hello

D:\>cmd /c "echo hello"
hello

D:\>cmd -c "echo hello"
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

D:\>

Apparently WinXP's cmd.exe unfortunately ignores the `-c' option silently. As
Paul pointed out earlier, "(in GNU make) there's no way to change the argument
from '-c' to something else (or nothing)."

I'm still wondering why I didn't figure it out earlier and why Eli hasn't
noticed that yet. Maybe what I was using was Windows 2000 Professional which
kindly regards the `-c' option?

No clue. :(

I have no idea whether make 3.81 has already released or not. Hopefully Eli
and Paul will fix this annoying bug before the BIG release for the last four
years.

Thanks!
Agent

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Problem with make-3.81rc1 building linux kernel

[Art Haas]

Hi.

I'm running an up-to-date Debian unstable system, so I've got the -rc1
make installed. When I build a kernel for the machine, make seems to
believe that everything is always out of date, so the build would be
performed as if I'd done a 'make mrproper' and removed all the object
files. Even if I start a build, then kill it at some point during the
build, the next time I resume a build everything appears out-of-date.

I went and grabbed the beta4 release from alpha, built and installed it,
and that 'make' does not display the unexpected behavior of -rc1. As
the -rc1 release seems to have a different (buggy?) way of dealing with
kernel builds, I'm mailing the list to see if others are seeing this
behavior. I scanned the list today and didn't see this problem
mentioned, but that the official 3.81 release is planned to happen
shortly, so if this is indeed a bug it needs to be squished promptly.

Thanks.

Art Haas
-- 
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.

-Thomas Jefferson to James Smith, 1822


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15719] Make jobserver feature not supported on WINDOWS32 platforms

[Agent Zhang]

Follow-up Comment #5, bug #15719 (project make):

greg~

In my first mail to Paul, I also mentioned the Cygwin erratic failures in
features/parallelism. However, at that time I was using GNU make 3.80. With
GNU make 3.81beta4, it seems to me it's harder to reproduce the random
failures since verstion 3.81beta4 runs a bit faster. :=)

> It is only TEST #5 which fails, but with somewhat different
> output; my guess is that creating load conditions, running
> other applications like video, while the test is running,
> helps reproduce the failure. 

In fact, the tests in features/parallelism is somewhat fragile especially for
very slow machine (or fast machine but with heavy load). They make extensive
use of "sleep 1", "sleep 2", and etc., to do synchronization and assume that
the user's machine runs fast enough. For this reason, it's not a
Cygwin-specific problem IMHO.

> It does NOT work reliably under Cygwin, in my experience.

I'm guessing it's probably not a bug in GNU make, but a "bug" in the test
suit itself. AFAIK, there's no easy way to overcome this problem, hence it's
mostly the user's responsibility not to run the test suit either on very slow
machines or when the system load is pretty high. Yes, it's not an ultimate
solution. :/

Regards,
Agent

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15937] default_names test dies on Cygwin; $port_type = 'UNIX'; should be 'W32'

[greg keranen]

Follow-up Comment #2, bug #15937 (project make):

Agent Zhang wrote:
>>   if ($CASE_SENSITIVE) {
[...]
>The essence is: any platforms which are case-insensitive to file names
should
be taken into account. So there won't be any bug reports when other
Cygwin-like monsters born out in the future. :=)

I agree completely.
I didn't really want to tread into 'deep water', questioning the semantics of
$port_type but it really should be done - at least for the sake of consistency
of the test suite, it should be DOCUMENTED: what is the supposed meaning of
$port_type?

In the case of this test, Agent's idea of a new global $CASE_SENSITIVE is a
better way to go than $port_type.

Would Paul or Eli care to provide any guidance on how to address the more
general question of $port_type semantics? Should we create a bug for separate
discussion of that issue? Or perhaps create a new document as a placeholder
for a definitive statement on coding standards and semantics for the test
suite?

Thanks.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: make 3.81rc1 / MSYS

[Eli Zaretskii]

> From: David Ergo <[EMAIL PROTECTED]>
> Date: Tue, 28 Feb 2006 13:08:10 +0100
> Cc: Xavier Marichal <[EMAIL PROTECTED]>,
>   =?ISO-8859-1?Q?S=E9bastien?= Frippiat <[EMAIL PROTECTED]>
> I managed to compile a working version of make 3.81rc1 for MSYS but I
> had do some modifications.
> 
> first config/config.guess and config/config.sub must be simply patched
> to support MSYS build system (see config_msys.patch in attachment).
> 
> sources must be patched (bugs correction) like specified hereunder (also
> in sources_msys.patch in attachment) :

Thank you for your report.  However:

> file job.c, at line 2525 :
>   && strchr (sh_chars_sh, p[1]) == 0)
> should be :
>   && strchr (sh_chars, p[1]) == 0)
> 
> file implicit.c, at line 355 :
>   if (!check_lastslash)
> should be :
>   if (check_lastslash)
> 
> file make.h, at line 350 : 
>   #if defined(HAVE_DOS_PATHS)
> should be :
>   #if defined(HAVE_DOS_PATHS) && !defined(__MSYS__)

Sorry, it seems I don't understand enough about MSYS-specific issues
to figure out these problems.  sh_chars[] does not exist in the
WINDOWS32 build; are you saying that you are building the Unix parts
of the code?  I always thought that MSYS builds are actually MinGW
builds, i.e. they use the Windows runtime DLL's, not Cygwin-style
Posix runtime libraries.  Am I mistaken?  If so, what is the
difference between a Cygwin build of Make and an MSYS build?

In any case, the first two of the 3 changes you suggest above cannot
be made as you asked for them, since that would break the other ports
of Make for DOS/Windows.  If I understand more about the reasons (see
my questions above), I hope to be able to craft a patch that fixes the
MSYS build without screwing others.

> And after executing 'configure', I had to modify config.h manually
> before executing make (easier for me than correcting the configure
> script) :
> 
> to support dos-style paths, changed :
>   /* #undef HAVE_DOS_PATHS */
> into
>   #define HAVE_DOS_PATHS 1

Again, I don't understand this: if configure says that MSYS doesn't
have DOS drive letters, why do you need to enable its support?

> and to use the internal realpath function as a workaround to the buggy
> msys realpath() function (otherwise the test 'functions/realpath' fails
> at line 19 about realpath of ///), changed :
>   #define HAVE_REALPATH 1
> into
>   /* #undef HAVE_REALPATH */

This should be handled by modifying the configure test for realpath.
Can you explain what is buggy in the MSYS implementation, so the
configure test could be augmented?

TIA


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15719] Make jobserver feature not supported on WINDOWS32 platforms

[greg keranen]

Follow-up Comment #3, bug #15719 (project make):

Just FYI, I have found erratic results under Cygwin: 
features/parallelism sometimes reports succeeds, sometimes fails.

$parallel_jobs = 1;

[EMAIL PROTECTED] tests]$ make -j 2 -f /dev/null
make: *** No targets.  Stop.

--- TEST ENVIRONMENT:
GNU Make 3.81rc1 on CYGWIN_NT-5.1 x2 1.5.19(0.150/4/2) i686

--- SYSTEM:
OS: Windows XP (SP2; +all current patches)
CPU:AMD Athlon 64 X2 4400+
Board:  ASUS A8N-SLI Premium (nVidia nForce 4 SLI chipset)

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15941] features/default_names test creates makefiles in the wrong directory (tests); fails to cleanup

[greg keranen]

URL:
  

 Summary: features/default_names test creates makefiles in
the wrong directory (tests); fails to cleanup
 Project: make
Submitted by: gkeranen
Submitted on: Wed 03/01/06 at 11:14
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
   Component Version: CVS
Platform Version: Any
   Fixed Release: None

___

Details:

--- TEST ENVIRONMENT:
GNU make on CYGWIN_NT-5.1 x2 1.5.19(0.150/4/2) i686
GNU Make 3.81rc1

--- STEPS TO REPRODUCE:
1. Create condition for default_names to fail:
Edit  tests/run_make_tests.pl, as follows - omitting CYGWIN_NT from 'W32'
port_type assignment:

   # This is probably not specific enough.
   #
   if ($osname =~ /Windows/i || $osname =~ /MINGW32/i) {
 $port_type = 'W32';
   }

2. Run test
[EMAIL PROTECTED] tests]$ ./run_make_tests features/default_names
--
Running tests for GNU make on CYGWIN_NT-5.1 x2 1.5.19(0.150/4/2) i686
   GNU Make 3.81rc1
--

Clearing work...
Making work dirs...

features/default_names ..
*** Test died (features/default_names): test_driver.pl: 453: abort at
test_drive
r.pl line 638.

1 Test in 1 Category Failed (See .diff files in work dir for details) :-(

[EMAIL PROTECTED] tests]$ ls
COPYINGREADMErun_make_tests  scripts
ChangeLog  makefile  run_make_tests.pl   test_driver.pl
NEWS   mkshadow  run_make_tests.pl.orig  work
[EMAIL PROTECTED] tests]$ cat makefile
THIRD: ; @echo It chose Makefile

--- ANALYSIS:

makefile is left behind in tests directory when test dies.
toplevel cannot cleanup since test files are not in correct directory (work)

Note that default_names is unusual in its need to create 2 or 3 makefiles,
AND DELETE THEM in order to perform subsequent tests in the suite - must
create its own makefile and cleanup too since it doesn't (cannot?) take
advantage of the preferred top level routines to coordinate all this: for
example, test_driver.pl creates makefiles with &get_tmpfile() and passes
filename to make with explicit -f option. Obviously, default_names cannot use
this technique.

--- PROPOSED FIX:
I have re-written default_names script to handle errors correctly, and
creating makefiles under work directory, using absolute path from global
vars: $pwd . $pathsep . $workpath

New default_names file is attached.

--- BUG REGRESSION OUTPUT:
I have tested this on Cygwin under the original 'abort' conditions (using
3.81rc1 run_make_tests.pl, prior to applying my fix for BUG #15937) and
verified that this version correctly handles the error and leaves no
makefiles behind.

I have also tested under success conditions (#15937 fix applied) and it works
the same as previous version of the script.






___

File Attachments:


---
Date: Wed 03/01/06 at 11:14  Name: default_names  Size: 3.02KB   By: gkeranen
default_names file - fixed to handle errors correctly and cleanup


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15719] Make jobserver feature not supported on WINDOWS32 platforms

[greg keranen]

Follow-up Comment #6, bug #15719 (project make):

Agent Zhang wrote:
>I'm guessing it's probably not a bug in GNU make, but a "bug" in the test
suit itself. AFAIK, there's no easy way to overcome this problem, hence it's
mostly the user's responsibility not to run the test suit either on very slow
machines or when the system load is pretty high. 

It don't think it is a problem with the test suite: it is a problem with make
running on the W32 platform.

It is always a temptation to 'tweak' a test until the software passes - but
this is a very dangerous thing to do! It may give the developers  a sigh of
relief but it misleads the hapless user into trusting that results are
assured when they are, in fact not.

It is better to create tests that TRY TO FAIL, rather than those which try to
succeed.

In the case of this bug, I have a very fast machine (AMD Athlon 64 X2 4400+)
and it is pretty easy for me to make the test fail, at least 20% of the
time.

I think the best solution, if this bug CANNOT be fixed (and I would wager it
cannot) is to reduce the sleep time of the test to INCREASE likelihood of
failure.

If the bug cannot be truly fixed, under any amount of load - the best
solution would be to completely disable the -j feature when running on W32
platform so a user never gets 'surprised' when something fails under load,
etc.

Either a feature should work RELIABLY, or not at all, in my opinion.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15718] Weird behavior of the SHELL variable on Win32

[Eli Zaretskii]

Follow-up Comment #14, bug #15718 (project make):

Paul is right: the Windows port does not invoke cmd.exe with the -c switch. 
So there's no bug here and nothing to fix.

Here are the gory details:

If you look closer at job.c:construct_command_argv_internal, you will see
that, in the `slow' case, if the shell is not a Unixy shell, the code creates
a temporary batch file via the call to create_batch_file.  It then writes to
that batch file the actual command, but without the shell name and the -c
switch (it uses command_ptr which was set past the shell name and -c).  Next,
it creates new_argv[] whose zeroth member is the name of the batch file.  This
new_arg[] array is then passed (under the name argv[]) to process_easy, which
simply calls CreateProcess to run the batch file.  The OS will then invoke
the shell to do that.

So there's no -c switch passed to cmd.exe nowhere in sight.

Btw, when you type "cmd -c echo hello", cmd.exe doesn't _ignore_ that, it
actually invokes another copy of cmd.exe (that's why you see the Windows
banner).  Type "exit" to return to your original shell.

If you still think there's a bug related to working with cmd.exe in a
Makefile, please show a test case where it fails.  AFAIK, the current release
candidate code supports cmd.exe with no problems.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: svn 14407 broke the repository.

[Paul D. Smith]

%% Bernhard Fischer <[EMAIL PROTECTED]> writes:

  >> What I need to know at least is: what is the correct, complete path for
  >> the blkid_getsize.c file?  What is the correct, complete path for the
  >> blkid_getsize.o file?

  bf> Correct paths are:
  bf> /scratch/src/busybox/e2fsprogs/blkid/blkid_getsize.c
  bf> /scratch/obj/busybox/e2fsprogs/blkid/blkid_getsize.o

In that case, this one is correct:

  $(patsubst %,$(objdir)/%,$(BLKID_OBJS)): $(objdir)/blkid/%.o: 
$(srcdir)/blkid/%.c|$(objdir)/blkid

Assuming that BLKID_OBJS contains values like: blkid/blkid_getsize.o etc.

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15947] tests/features/escape - 'path=p\:' test fails on Cygwin - cannot stat illegal filename

[greg keranen]

Follow-up Comment #1, bug #15947 (project make):

In rethinking my proposed solution, I don't like the idea of 
simply skipping the test. Instead, I thought a better solution would be to
try it with .PHONY : $(path)foo

But, unfortunately, this gives the same error as original: 
make: stat: p:foo: No medium found

Should make really be trying to stat $(path)foo when it has been declared as
.PHONY?

Here is the relevant section of my revised tests/features/escape, complete
file also attached:
[...]
print MAKEFILE <<'EOF';
$(path)foo : ; @echo cp $^ $@

foo\ bar: ; @echo 'touch "$@"'

sharp: foo\#bar.ext
foo\#bar.ext: ; @echo foo\#bar.ext = '$@'
# for bug #15947:
ifdef port_type
.PHONY : $(path)foo
endif
#$(warning path=$(path))
#$(warning port_type=$(port_type))
EOF
[...]
# TEST 3: This one should work, since we escape the ":".

if (false){
#  2006.03.01 [EMAIL PROTECTED] - avoid test entirely? - poor 'fix' for bug
#15947:
# CAVEAT: this may also fail on other systems. May need to filter out 
other
$port_type values
if ($port_type != 'W32' && $port_type != 'DOS')
{
# TEST 3: This one should work, since we escape the ":".
&run_make_with_options($makefile, "'path=p\\:'", &get_logfile, 
0);
$answer = "cp p:foo\n";
&compare_output($answer,&get_logfile(1));
}
} else {
# 2006.03.01 [EMAIL PROTECTED] - shouldn't this should work using .PHONY ?
# - fails to fix error of 'make: stat: p:foo: No medium found' in Cygwin
$escape_options = "'path=p\\:'";

if ($port_type == 'W32' || $port_type == 'DOS')
{
# for bug #15947:
$escape_options .= " 'port_type=$port_type'";
} 
&run_make_with_options($makefile, $escape_options, &get_logfile, 0);
$answer = "cp p:foo\n";
&compare_output($answer,&get_logfile(1));

}

--- RESULT:
[EMAIL PROTECTED] tests]$ ./run_make_tests features/escape
[...]
features/escape . FAILED (5/6
passed)

1 Test in 1 Category Failed (See .diff files in work dir for details) :-(

--- FILE: escape.diff.2:

*** work/features/escape.base.2 Wed Mar  1 12:13:52 2006
--- work/features/escape.log.2  Wed Mar  1 12:13:52 2006
***
*** 1 
--- 1,3 
+ make: stat: p:foo: No medium found
  cp p:foo
+ make: stat: p:foo: No medium found

___

Additional Item Attachment:

File name: escape Size:2 KB
attempt to run test using .PHONY : $(path)foo


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15947] tests/features/escape - 'path=p\:' test fails on Cygwin - cannot stat illegal filename

[greg keranen]

Follow-up Comment #3, bug #15947 (project make):

Thanks Agent,
You spurred me to think again and to better understand the problem.

This bug is wrongly titled and I cannot edit the title now.

I originally thought that make was trying to stat a local file named 'p:foo'
and having a problem with ':' being an illegal character but now I realize
this is not the case.

The reason I am having the problem and you are not has nothing to do with
Cygwin, or with illegal filenames - it is because I have a P: drive mapping
on my system (a VirtualCD, in fact, with no disc inserted) and you don't.

Now I understand the message makes perfect sense:
> make: stat: p:foo: No medium found

I now realize that there is any reason to bother with special-case $port_type
clauses - what is needed, however, is a .PHONY rule.

This this should apply for ALL systems :

.PHONY : $(path)foo foo\ bar sharp foo\#bar.ext

Complete file is attached.

Unfortunately, make is still trying to stat $(path)foo and I have found no
way to fix or workaround this problem so it is still failing on Cygwin - but
there is no easy way to reproduce the failure unless your particular system
has a P: drive mapped as a removable drive.

I don't understand why make tries to stat a .PHONY : p:foo so I am creating a
separate bug.

___

Additional Item Attachment:

File name: escape Size:1 KB
modified escape script with .PHONY rule


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15718] Weird behavior of the SHELL variable on Win32

[Paul D. Smith]

Follow-up Comment #13, bug #15718 (project make):

Well, you can't assume that just because _on UNIX_ make forcibly adds a -c to
every $(SHELL) invocation, that it also does the same thing in the other
ports.  There's a lot of special code to handle different types of "shell" on
Windows; Eli etc. would have to say for sure because it's tricky to track the
code with all the ifdefs, but it's quite possible the Windows cmd.exe ports
do something different.

As you say, it'd be surprising if this failed so completely.  Can you show a
misbehavior related to this using real make commands?  If not I'm inclined to
think the cmd.exe -c is not an issue.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Make-3.81 rc1 hangs with -j 2 (multiplatform)

[J. David Bryan]

On 27 Feb 2006 at 13:09, Paul D. Smith wrote:

> %% Boris Kolpackov <[EMAIL PROTECTED]> writes:
> 
>   bk> 3. If I replace the "%.3 : | %.2" rule with the equivalent normal
>   bk> rule, make does not hang.

What would the "equivalent normal rule" be?  Perhaps I can use that as a 
workaround in my original makefile.

(I'm trying to express that if %.3 doesn't exist, it must be built only 
after %.2 is built, but it is not to be rebuilt if %.2 is subsequently 
changed.)

  -- Dave



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

[anonymous]

Follow-up Comment #5, bug #15919 (project make):

(comment by J. David Bryan, original submitter)

One additional characteristic: aborting make after it's hung, e.g., with
CTRL+C, and then re-running "make -j 2" will complete the expected set of
actions.  That is:

$ touch test.0 && make -j 2
touch test.1
touch test.2
[ make hangs here ]
[ now kill it with CTRL+C ]

$ make -j 2
touch test.int
touch test.4
rm test.int

$

So whatever conditions pertain that cause the hang do not recur when make is
restarted.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

[Boris Kolpackov]

Follow-up Comment #3, bug #15919 (project make):

After some more testing, it appears that removing test.3 from .SECONDARY
prevents make from hanging, not test.2.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: svn 14407 broke the repository.

[Rob Landley]

On Thursday 02 March 2006 3:51 pm, Bernhard Fischer wrote:
> On Thu, Mar 02, 2006 at 02:32:53PM -0500, Rob Landley wrote:
> >On Thursday 02 March 2006 1:18 pm, Bernhard Fischer wrote:
> >> >Not happy...
> >>
> >> Missing dependency of applets/applets.o vs. .config.
> >> Fixed in r14431.
> >
> >Yup, that's fixed.  Thanks. :)
> >
> >It now builds for me if I disable everything in the e2fsprogs directory,
> > which is cool.  Unfortunately, if I switch on e2fsprogs:
> >
> >make: *** No rule to make target
> >`/home/landley/busybox/busybox/e2fsprogs/blkid_getsize.c', needed by
> >`/home/landley/busybox/busybox/e2fsprogs/blkid/blkid_getsize.o'.  Stop.
> >
> >This is under ubuntu.
>
> my incarnation of debian (also a dedicated ubuntu box) has make-3.81b4.
> I'm curiuos as to what make version is driving at your end?

The fall 2005 release has make 3.80 (same as Red Hat 9).

> I *think* that i'm tripping a bug in "my" make-3.81b4 version.
> Please reread the bug with-make-and-e2fsprogs mail ¹) or just apply
> *and* *checkin* the attached alleged proper fix which will make
> make-3.81b4 (from debian) go up in flames but will work four your
> make-3.80...
>
> ¹) http://busybox.net/lists/busybox/2006-March/018910.html

Huh.  For some reason I don't seem to have gotten a copy of that message.  
Weird.

This patch does indeed fix it for me on ubuntu.

Red Hat 9 still barfs on the line 247 of Makefile:
$(foreach d,$(DIRS_UPPER),$(eval $(notdir $(d))-y:=))

The error messages are things like:
Makefile:247: /root/coreutils/libcoreutils/Makefile.in: No such file or 
directory

When the path the file is actually at would 
be /root/busybox/coreutils/libcoreutils/Makefile.in

Rob

(Oh, and make distclean isn't zapping libbusybox.*)
-- 
Never bet against the cheap plastic solution.


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: svn 14407 broke the repository.

[Bernhard Fischer]

On Thu, Mar 02, 2006 at 02:32:53PM -0500, Rob Landley wrote:
>On Thursday 02 March 2006 1:18 pm, Bernhard Fischer wrote:
>> >Not happy...
>>
>> Missing dependency of applets/applets.o vs. .config.
>> Fixed in r14431.
>
>Yup, that's fixed.  Thanks. :)
>
>It now builds for me if I disable everything in the e2fsprogs directory, which 
>is cool.  Unfortunately, if I switch on e2fsprogs:
>
>make: *** No rule to make target 
>`/home/landley/busybox/busybox/e2fsprogs/blkid_getsize.c', needed by 
>`/home/landley/busybox/busybox/e2fsprogs/blkid/blkid_getsize.o'.  Stop.
>
>This is under ubuntu.

my incarnation of debian (also a dedicated ubuntu box) has make-3.81b4.
I'm curiuos as to what make version is driving at your end?

I *think* that i'm tripping a bug in "my" make-3.81b4 version.
Please reread the bug with-make-and-e2fsprogs mail ¹) or just apply
*and* *checkin* the attached alleged proper fix which will make
make-3.81b4 (from debian) go up in flames but will work four your
make-3.80...

¹) http://busybox.net/lists/busybox/2006-March/018910.html

Index: e2fsprogs/Makefile.in
===
--- e2fsprogs/Makefile.in   (revision 14432)
+++ e2fsprogs/Makefile.in   (working copy)
@@ -45,11 +45,11 @@
 # may have object files created after the timestamp of the directory was
 # updated which would lead to spurious rebuilds (as some of the dentries
 # may be older than the dir itself).
-$(patsubst %,$(objdir)/%,$(BLKID_OBJS)): $(objdir)/blkid/%.o: 
$(srcdir)/%.c|$(objdir)/blkid
-$(patsubst 
%,$(objdir)/%,$(E2FSCK_OBJS)):$(objdir)/e2fsck/%.o:$(srcdir)/%.c|$(objdir)/e2fsck
-$(patsubst %,$(objdir)/%,$(E2P_OBJS)):   $(objdir)/e2p/%.o:   
$(srcdir)/%.c|$(objdir)/e2p
-$(patsubst 
%,$(objdir)/%,$(EXT2FS_OBJS)):$(objdir)/ext2fs/%.o:$(srcdir)/%.c|$(objdir)/ext2fs
-$(patsubst %,$(objdir)/%,$(UUID_OBJS)):  $(objdir)/uuid/%.o:  
$(srcdir)/%.c|$(objdir)/uuid
+$(patsubst %,$(objdir)/%,$(BLKID_OBJS)): $(objdir)/blkid/%.o: 
$(srcdir)/blkid/%.c|$(objdir)/blkid
+$(patsubst 
%,$(objdir)/%,$(E2FSCK_OBJS)):$(objdir)/e2fsck/%.o:$(srcdir)/e2fsck/%.c|$(objdir)/e2fsck
+$(patsubst %,$(objdir)/%,$(E2P_OBJS)):   $(objdir)/e2p/%.o:   
$(srcdir)/e2p/%.c|$(objdir)/e2p
+$(patsubst 
%,$(objdir)/%,$(EXT2FS_OBJS)):$(objdir)/ext2fs/%.o:$(srcdir)/ext2fs/%.c|$(objdir)/ext2fs
+$(patsubst %,$(objdir)/%,$(UUID_OBJS)):  $(objdir)/uuid/%.o:  
$(srcdir)/uuid/%.c|$(objdir)/uuid
 
 
 E2FSPROGS-$(CONFIG_CHATTR) += chattr.o $(E2P_OBJS)
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: virtual memory exhausted

[Paul D. Smith]

%% "jagabandhu panda" <[EMAIL PROTECTED]> writes:

  jp> While compiling an atmospheric model it says

  jp> Entering the directory /directory path
  jp> make[3] *** virtual memory exhausted. Stop
  jp> Leaving the directory /directory path

  jp> I came to know that this is a bug. I am using gnu-make. Please
  jp> help me out to solve this problem.

There's very little we can say with the information you provide.  When
asking for help please always include, at a bare minimum, the version of
GNU make you're using (make --version) and the type and version of
operating system you're running it on.  It's also helpful to provide a
small example that shows the problem.


However, in this case I believe this problem has been fixed already.  I
recommend you try the latest release candidate for the next version of
GNU make, which you can download here (you'll have to configure and
compile it after you download and unpack it):

ftp://alpha.gnu.org/gnu/make/make-3.81rc1.tar.gz

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

(no subject)

[naveen fidder]

  




___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: svn 14407 broke the repository.

[Bernhard Fischer]

On Fri, Mar 03, 2006 at 04:36:07PM -0500, Paul D. Smith wrote:
>%% Bernhard Fischer <[EMAIL PROTECTED]> writes:
>
>  bf> I *think* that i'm tripping a bug in "my" make-3.81b4 version.
>  bf> Please reread the bug with-make-and-e2fsprogs mail ¹) or just
>  bf> apply *and* *checkin* the attached alleged proper fix which will
>  bf> make make-3.81b4 (from debian) go up in flames but will work four
>  bf> your make-3.80...
>
>  bf> ¹) http://busybox.net/lists/busybox/2006-March/018910.html
>
>I'd like to determine whether this is a bug or not and fix it before GNU
>make 3.81 is released if so, but before I can do that I need to know
>what the right behavior is and I can't tell that based on the info in
>either of these emails.
>
>
>What I need to know at least is: what is the correct, complete path for
>the blkid_getsize.c file?  What is the correct, complete path for the
>blkid_getsize.o file?

Correct paths are:
/scratch/src/busybox/e2fsprogs/blkid/blkid_getsize.c
/scratch/obj/busybox/e2fsprogs/blkid/blkid_getsize.o


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

kbuild: Problem with latest GNU make rc

[psmith]

Hi all.  I've set Reply-To: to the bug-make@gnu.org list; I'm hoping we
can keep the discussion there since I don't subscribe to kbuild-devel.


I'm working on getting the next release of GNU make, 3.81, out the door
(amazing!)  The weekend before last I released 3.81rc1 for people to
test.  A day or two ago, Art Haas <[EMAIL PROTECTED]> emailed me that he
was having problems using kbuild with this version.  The previous
version, 3.81beta4, works fine.

The symptoms are that much of the kernel was rebuilding over gain
every time he ran make, even after he'd just done a top-down build.

I pulled the 2.6.15 kernel and sure enough, I see the same behavior.  I
delved into the kbuild infrastructure and I found the problem.


The kbuild system uses a trick to force rebuilds if the command line
changes for a given target (normally make only rebuilds if the target is
out of date--some versions of make, like Solaris make, have a
.KEEP_STATE feature but GNU make does not support this).  Here's a
stripped-down example of what kbuild does:

.PHONY: FORCE

%.o : %.c FORCE
$(if_changed_rule ...)

if_changed_rule = $(if $(strip $? $(call arg-check, $(cmd_$(1)), $(cmd_$@)) ),\
@set -e; \
$(rule_$(1)))

The FORCE prerequisite causes ALL .o targets that match this rule to be
considered by make to be out of date (because FORCE is always
out-of-date and it's a prerequisite of the .o).

The trick is in the if_changed_rule macro: it tests whether any
prerequisites have changed ($? is the changed prerequisites; it'll be
empty if none have changed) and whether the command lines have changed
(the call to arg-check).  If those values are true (non-empty) it
expands to the rule.  Otherwise it expands to nothing.

GNU make takes several shortcuts to provide efficiency in places where
it doesn't matter, and so if it sees an empty command it doesn't try to
run a shell.  In this way, kbuild gets the benefit of checking the
command line for every target without paying a price for useless shells
being invoked during the build.


However, this trick as implemented is accidentally relying on what may
be a misbehavior on GNU make's part: one that was changed in the latest
rc release.  This is causing rebuilds to happen.

In previous versions of GNU make, prerequisites that didn't exist were
not included in the $? variable.  In the new version that's been changed
(fixed?) so that all out-of-date prerequisites are included in the $?
variable, even if they don't exist.


The old behavior allowed this rule to work, because even though FORCE
was out-of-date and would normally always appear in $?, it didn't exist
as a file and this exception caused it to be left out.  So, the value of
$? was empty in the old version if the only prerequisite that was
considered out-of-date was the non-existent file FORCE.

In the new version of GNU make, the value of $? is FORCE in that
situation, so the test in if_changed_rule is always true and it always
evaluates to the compile line, and rebuilds.


Neither the GNU make manual nor the POSIX definition of make gives us
clear direction as to the correct behavior in this particular situation.
SuS says:

  $?
  The $? macro shall evaluate to the list of prerequisites that are
  newer than the current target. It shall be evaluated for both target
  and inference rules.

The GNU make manual says:

  $?
  The names of all the prerequisites that are newer than the target,
  with spaces between them.

So... is a non-existent file "newer than the target"?  This specific
situation is not addressed.  However, other versions of make (SysV make
for example) interpret a non-existent file as out-of-date and DO include
it in $?.  Given the meaning of "newer than the current target" to make
(that it causes the target to be rebuilt) and the implied meaning of $?
(a list of the prerequisites that cause the target to be rebuilt), I
feel that the new behavior is correct and the old behavior is incorrect.


So.  If the change is correct, how should we proceed?  Obviously it's
not hard to change kbuild to fix the majority of the problem; replace
the above macro with something like:

  if_changed_rule = $(if $(strip $(filter-out FORCE,$?) $(call arg-check, 
$(cmd_$(1)), $(cmd_$@)) ),\
@set -e; \
$(rule_$(1)))

and all will be well.  There are other, similar macros that need this
change as well.  And, there are other places where this $(filter-out
FORCE,...) is already done, so it's apparently come up before.  I attach
a patch here which makes this fix in kbuild.

The above solution is backward-compatible (will work with older versions
of GNU make), so that's nice.  But of course, current releases will still
be broken unless patched.  Is it OK to say, if you upgrade GNU make you
have to patch kbuild, unless you want to rebuild everything every time?

Ouch.


There is another slight problem: some targets have extra PHONY
prerequisites as well.  For example, here:

Re: svn 14407 broke the repository.

[Paul D. Smith]

%% Rob Landley <[EMAIL PROTECTED]> writes:

  rl> The line numbering is off.  Although it _says_ it's complaining
  rl> about line 247, it's actually complaining about line 249, which
  rl> is:

There were a few line numbering issues resolved since 3.80 was released.

  rl> P.S.  Either way it still tries to run the "h;y/[a-z]/[A-Z]/"
  rl> thing through /bin/sh instead of sed.  This doesn't appear to be a
  rl> sed problem, but a make problem.

I'll need more info about this before I can give an opinion.

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15718] Weird behavior of the SHELL variable on Win32

[Agent Zhang]

Follow-up Comment #15, bug #15718 (project make):

Hmm...here is the screen-shot:

D:\Agent2002\AISystem1.0\SVK\de\UniSimu\Methodology>win32-make SHELL=cmd
test
dmd -quiet binary_tree_set3.d
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

D:\Agent2002\AISystem1.0\SVK\de\UniSimu\Methodology>type Makefile
RM_F = perl -MExtUtils::Command -e rm_f

all: binary_tree_set3.exe palindrome.exe char_stat.exe

%.exe: %.d
dmd -quiet $<

.PHONY: test clean

test: all
prove *.t

clean:
$(RM_F) *.exe *.obj *.map

D:\Agent2002\AISystem1.0\SVK\de\UniSimu\Methodology>win32-make -v
GNU Make 3.81rc1
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for Windows32

--- END ---

I must admit that this problem doesn't appear very time. I don't know what's
going on here.

FYI, I always have Cygwin-shell visible in my PATH environment.

Agent

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Make-3.81 rc1 hangs with -j 2 (multiplatform)

[Paul D. Smith]

%% Boris Kolpackov <[EMAIL PROTECTED]> writes:

  bk> "J. David Bryan" <[EMAIL PROTECTED]> writes:

  >> I originally reported a make-3.81rc1 hang against the Windows port here:
  >> 
  >> http://lists.gnu.org/archive/html/make-w32/2006-02/msg00058.html


  bk> I did some digging and here is what I uncovered:

  bk> 1. If I remove test.2 from .SECONDARY, make does not hang.
  bk> 2. If I change "%.3 : | %.2" to "%.3 : %.2", make does not hang.
  bk> 3. If I replace the "%.3 : | %.2" rule with the equivalent normal rule,
  bk>make does not hang.
  bk> 4. Adding .SECONDEXPANSION: does not change anything.

  bk> I did some inspecting in the implicit rules area and it seems that
  bk> everything is working properly there, i.e., in the instantiation of
  bk> the "%.3 : | %.2" rule, test.2 has the intermediate, secondary and
  bk> ignore_mtime flags set, as expected.

Thanks for checking into this Boris.  This one looks like it's going to
be a big PITA to fix.

Dave, can you please file a bug for this on the Savannah site so we
don't misplace it?  Please add the makefile to reproduce it as an
attachment so we don't lose the formatting.

Cheers!

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

[Boris Kolpackov]

Follow-up Comment #4, bug #15919 (project make):

I tried to minimize the makefile but couldn't get any rules out without
removing buggy behavior. I could get .SECONDARY out of the way, however. The
first line in the makefile:

.SECONDARY: test.1 test.2 test.3

Can be replaced with

.INTERMEDIATE: test.3
.PRECIOUS: test.3

If I comment .INTERMEDIATE out, the behavior goes away.
___

Additional Item Attachment:

File name: makefile   Size:0 KB



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make