Problem with overriding def. SHELL-sh.exe on W2000

[kluszkiewicz]

Hello,

I'm using gnumake 3.78 (also tried 3.8) buided with VC on W2000.
I've a problem with overriding default SHELL value from sh.exe to cmd.exe.
1. When I'm doing it from env. it has completly no effect.
2. When I'm doing it from makefile I receive error:
"process_begin: CreateProcess((null), pause, ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden.
gmake-378: *** [multiplef2] Error 2"
3.When I'm passing SHELL=cmd.exe to makefile from commandline overrides take 
effect, but when sh.exe is in PATH  after making makefile  just next session of 
cmd.exe goes to live.
If not I have errros related to to long path (I'm using long path to point 
compiler) - if I have no sh.exe in PATH and don't try to override SHELL-sh.exe 
- I;ve no errors with to long paths.

Generally getting SHELL value from env. doesn't work (MAKESHELL also).
Please take care about it.

Best regards,
Krystian


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

RE: bug in 3.8.0

[PATTON, BILLY \(SBCSI\)]

Thanks for the reply
Yes we have committed to 3.8.1.  For now I'm using my compiled version
for development.  The server version will be installed in late July or
August.

-Original Message-
From: Martin Dorey [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 20, 2006 11:29 AM
To: PATTON, BILLY (SBCSI); bug-make@gnu.org
Subject: RE: bug in 3.8.0


> I'm between a rock and a hard place.

I know - I'm in a similar position.  Having code which reliably
generates rules (with $eval) is a powerful feature and, once you've
tasted it, it's hard to give it up.  However, I've been using the 3.81
beta builds very successfully on a number of platforms for many months.
Debian's "testing" distribution has had 3.81 beta builds for a couple of
months now.  It's good to go, or very nearly so.

> 3.8.1 isn't released yet.

Not for long.  Paul's making a serious effort to get 3.81 released - the
hope is it will be this very week.

make-3.81rc2 is now available from ftp://alpha.gnu.org/gnu/make (in case
you're still using a beta build).  The previous (3.80) release of make
was about three and a half years ago.  Hopefully 3.82 won't take as long
but, if 3.81rc2 exhibits any problems in your production environment,
now would be a really, really good time to report them.
-
Martin's Outlook, BlueArc Engineering

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
PATTON, BILLY (SBCSI)
Sent: Friday, March 17, 2006 4:53
To: bug-make@gnu.org
Subject: bug in 3.8.0

define build_proj_template
$(1):  $(foreach bb,$(BB_$(patsubst build+%,%,$(1))),$(addsuffix
+$(bb),$(addprefix build+,$(patsubst build+%,%,$(1)
@echo "build_proj_template $(1)"
endef

$(foreach proj,$(PROJECTS),$(eval $(call build_proj_template,$(addprefix
build+,$(proj)

If I change the eval to warning

3.79ok
3.79.1  ok
3.8.0   ok
3.8.1   ok

change warning back to eval

3.79nothing
3.79.1  nothing
3.8.0   segmentation fault core dump
3.8.1   ok

Since 3.8.1 is beta.  It cannot put it to a production environment.
I'm between a rock and a hard place. 3.79 is installed but doesn't work.
The impact is taking a hard look at upgrading some of the servers to
3.8.0.
but it failes.  3.8.1 isn't released yet.




Segmentation fault (core dumped)




(gdb) bt
#0  0xc0199cbc in _sigfillset+0x26fc () from /usr/lib/libc.2
#1  0xc0197e18 in _sigfillset+0x858 () from /usr/lib/libc.2
#2  0xc0198cfc in _sigfillset+0x173c () from /usr/lib/libc.2
#3  0xc0195bec in _sscanf+0x8fc () from /usr/lib/libc.2
#4  0xc019b510 in realloc+0x1a0 () from /usr/lib/libc.2
#5  0x1f738 in xrealloc (
ptr=0x40018f78 "build+ldb :  build+ldb+inftp build+ldb+opi
build+ldb+schapi build+ldb+tuxapi build+ldb+ldngn 
build+ldb+in fgn build+ldb+ldgn build+ldb+ld" , size=4294965501) at misc.c:384
#6  0xb5ec in variable_buffer_output (ptr=0x40018810
"@[EMAIL PROTECTED]", string=0x40018498 "", length=1)
at expand.c:67
#7  0xba08 in variable_expand_string (line=0x40018810
"@[EMAIL PROTECTED]",
string=0x40018459 "$(eval $(call build_proj_template,$(addprefix
build+,$(proj", length=-1)
at expand.c:207
#8  0xc0e4 in variable_expand (line=0x40018459 "$(eval $(call
build_proj_template,$(addprefix build+,$(proj")
at expand.c:415
#9  0xc224 in variable_expand_for_file (
line=0x40018459 "$(eval $(call build_proj_template,$(addprefix
build+,$(proj", file=0x0) at expand.c:457
#10 0xc510 in allocated_variable_expand_for_file (
line=0x40018459 "$(eval $(call build_proj_template,$(addprefix
build+,$(proj", file=0x0) at expand.c:555
#11 0x11478 in func_foreach (o=0x40017bf8 "build_proj_template",
argv=0x68ff1870, funcname=0x36a98 "foreach")
at function.c:874
#12 0x12c80 in expand_builtin_function (o=0x40017bf8
"build_proj_template", argc=3, argv=0x68ff1870,
entry_p=0x40003604) at function.c:1864
#13 0x12fd8 in handle_function (op=0x68ff17a4, stringp=0x68ff17a8) at
function.c:1964
#14 0xbac8 in variable_expand_string (line=0x40017bf8
"build_proj_template",
string=0x40017390 "$(foreach proj,$(PROJECTS),$(eval $(call
build_proj_template,$(addprefix build+,$(proj)",
length= 91) at expand.c:235
#15 0x21c38 in eval (ebuf=0x68ff1574, set_default=1) at read.c:913
#16 0x20828 in eval_makefile (filename=0x40015148 "XXX", flags=0) at
read.c:379
#17 0x201a8 in read_all_makefiles (makefiles=0x4000fe70) at read.c:205
#18 0x1b390 in main (argc=3, argv=0x68ff0694, envp=0x68ff06a4) at
main.c:1444
(gdb)


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

[bug #16132] Quoting problem in 3.81rc1

[Eli Zaretskii]

Follow-up Comment #21, bug #16132 (project make):

Thanks, Pieter.  This means there's no bug at all: the comments inside
config.h.W32 clearly say to define HAVE_CYGWIN_SHELL if you are using such a
shell.  (Paul, do you think we should emphasize this in README.W32?)

I don't know why "echo" is defined as a built-in only for batch-mode sh.exe
(note that it is always defined for cmd.exe).  Perhaps it's because of some
quoting issue, since basically, invoking Cygwin programs from a VC-compiled
Make is playing with fire.  As Paul points out, this code is there for a long
time, so let's not change it now, before the release.  You can always use
echo.exe from Coreutils if you need `echo', right?


___

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 #16132] Quoting problem in 3.81rc1

[Paul D. Smith]

Follow-up Comment #20, bug #16132 (project make):

Pieter: thanks for debugging this, it's very helpful!  I'd like to do
something with this bug before the release (which is imminent) if possible;
is it not a bug after all?

I notice that the change to include echo in the BATCH_MODE_ONLY_SHELL was
made in job.c version 1.106, back in 1998 (!) just as GNU make 3.77 was
released, so that's not a new change itself.  I don't know why it's there
though.

___

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

Contradicting license informations in make.texi

[Sven Joachim]

There are two different license texts given at the beginning of
doc/make.texi:

a)

,
| Permission is granted to copy, distribute and/or modify this document
| under the terms of the GNU Free Documentation License, Version 1.1 or
| any later version published by the Free Software Foundation; with no
| Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
| Texts.  A copy of the license is included in the section entitled
| ``GNU Free Documentation License''.
`

b)

,
| Permission is granted to copy, distribute and/or modify this document
| under the terms of the GNU Free Documentation License, Version 1.1 or
| any later version published by the Free Software Foundation; with the
| Invariant Sections being ``GNU General Public License'', the Front-Cover
| Texts being ``A GNU Manual'', and with the Back-Cover Texts being as in
| (a) below.  A copy of the license is included in the section entitled
| ``GNU Free Documentation License''.
|
| (a) The FSF's Back-Cover Text is:
|
| @quotation
|   You have freedom to copy and modify this GNU Manual, like GNU
|   software.  Copies published by the Free Software Foundation raise
|   funds for GNU development.
`

Version a) appears in online versions of the manual (Info, HTML etc.),
version b) in the printed version (DVI).  I see three problems here.

1) Version b) lists the ``GNU General Public License'' as an Invariant
   Section, but does not actually include it.  This is a very serious
   error -- it turns redistribution of printed manuals into a
   violation of the GFDL.  Remedy: Include the GPL text or state that
   there are no Invariant Sections.

2) Obviously, version a) and b) differ.  This may be a mistake, and
   you may just bring them in sync.  Otherwise, it is unclear how to
   interpret it.

3) GFDL version 1.1 is listed as license for the manual, but later
   included is the text for GFDL version 1.2.  You probably want to
   upgrade to version 1.2 consistently.




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

[bug #16166] make 3.81rc2: make distclean does not remove build.sh

[Alexander Frink]

URL:
  

 Summary: make 3.81rc2: make distclean does not remove
build.sh
 Project: make
Submitted by: afrink
Submitted on: Do 23.03.2006 um 08:58
Severity: 3 - Normal
  Item Group: Build/Install
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
   Component Version: CVS
Platform Version: Any
   Fixed Release: None

___

Details:

Running a 'make distclean' does not remove build.sh. At least this is what I
would expect 'make distclean' to do. I have tested this on Linux and AIX.







___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



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

All dependencies not processed

[Hiebert, Darren \(MS\)]

Title: All dependencies not processed






I have a psuedo target defined:


eiffel: bet converter data_workbench db_config transporter analyzer mission_executor process_monitor performance_viewer progress_meter sstb scenario_ingestor seqmonitor sequencer

However, when I run "make -dp eiffel", the output shows only the prerequisites "bet" and "converter" being considered. . The target shown above is as it appears in the (-p) output, yet the other prerequisites are not even mentioned in the (-d) output as having been considered.

Can you suggest how I might track down whether the cause is some bug in make or some other cause? The "makefile" used is really a complicated hierarchy of included makefiles for a large system, so it is not reasonable to attach it.

Thank you,

Darren


--

Darren Hiebert

Northrop Grumman

XonTech Systems Engineering

Phone: 256-705-0123



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

[bug #16145] .SECONDARY: prevents non-existent dependency from forcing rebuild

[Jay Berkenbilt]

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

Okay, I've studied this and agree with your analysis that it is working as
intended. Unfortunately, this seems to leave me without any ability to tell
make not to delete intermediate targets without also telling it not to try to
rebuild things that have dependencies that don't exist.  Am I missing
something?  Thanks for the pointer to the other bug, which I missed in my
search for other bugs relating to this problem.


___

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 #16132] Quoting problem in 3.81rc1

[anonymous]

Follow-up Comment #9, bug #16132 (project make):

I have an old MKS sh.exe lying around; behavior is somehwat different: (\n
gets converted to newline...)


D:\GNUMake\test>PATH
PATH=C:\FromOldPc\isimip\sniff\mks\mks-6.1\mksnt;C:\WINDOWS;C:\WINDOWS\system32

D:\GNUMake\test>gmake381rc2.exe
echo -aap="noot"
-aap=noot
echo '-aap="noot"'
-aap=
oot"
echo -aap=\"noot\"
-aap=
oot"
echo -aap="noot" -mies="wim"
-aap=noot -mies=wim
echo '-aap="noot" -mies="wim"'
-aap="noot" -mies="wim"
echo -aap=\"noot\" -mies=\"wim\"
-aap=
oot" -mies="wim"


___

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 #16166] make 3.81rc2: make distclean does not remove build.sh

[Paul D. Smith]

Update of bug #16166 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #1:

This wasn't caught dur to a more subtle bug: if you built outside of the
source directory build.sh wasn't being created at all.  Because of this, the
normal checks that distclean works properly weren't catching the fact that
build.sh was left behind.

If fixed both of these 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

[bug #16132] Quoting problem in 3.81rc1

[Eli Zaretskii]

Follow-up Comment #16, bug #16132 (project make):

Yes, I'm the same Eli Z.

Paul is correct asking you for the details of the old versions: how they were
built and with what compier.


___

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 #16132] Quoting problem in 3.81rc1

[Paul D. Smith]

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

I almost agree with you Eli.  The fact that make prints the right string
before it invokes the shell would normally show that make is doing the right
thing and the shell is broken.  However, as we know Windows is much more
complex: the string make prints is not necessarily the same one sent to the
shell.  And, the way make modifies the command line is different depending on
whether it thinks it's invoking a command.com or a UNIX-y shell.  So, it's
still possible that make is not managing the handling of quotes and
backslashes properly when it invokes a shell.

The fact that it works for you with a zsh port is telling, but on the other
hand the fact that it works for the OP with older versions of GNU make and
not the current release candidates is ALSO telling, especially when you
consider that we did modify the handling of backslashes (insofar as they
escape newlines).

Given this, I'm not entirely convinced that this is not a problem with make. 
Is there some way we could reproduce the problem?  Do you (or anyone on the
Windows team) have access to a Cygwin or MKS shell?  Failing that we'll need
the poster to do a bit of debugging on his own I'm afraid.

___

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 #16132] Quoting problem in 3.81rc1

[anonymous]

Follow-up Comment #19, bug #16132 (project make):

Hi Eli,

I looked deeper into the issue this weekend.
I discovered that from 3.81b3 to 3.81b4, the default config.h settings for
W32 builds changed.
Up to 3.81b3, BATCH_MODE_ONLY_SHELL was defined in config.h.W32.  
Starting with 3.81b4, BATCH_MODE_ONLY_SHELL is undefined in config.h.W32.  
So it turned out I was doing batch mode only builds up to now, even when
using cygwin sh.exe.

After some experimentation, the following worked for me (W32 native make +
cygwin sh.exe) in 3.81rc2:
(1) I left BATCH_MODE_ONLY_SHELL undefined
(2) I defined HAVE_CYGWIN_SHELL.
(3) In line 2294/2296 in job.c, I commented out the ifdef:
//#ifdef BATCH_MODE_ONLY_SHELL
 "echo",
//#endif

Do you know why the "echo" is guarded ?

Regards,
Pieter.



___

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