Re: Make v3.79, for Windows32
From: "Andre Srinivasan" [EMAIL PROTECTED] Date: Thu, 15 Jun 2000 10:05:18 -0700 (GMT-8:00) I just checked that indeed bash is being invoked: $ cat Makefile all: echo $$SHELL $ make echo $SHELL d:/cygnus/cygwin-b20/usr/local/bin/sh.exe $ It would be more convincing to have a proof that Bash is called to run the command where the problem happens. Perhaps the quote style changes Make's decision about this. If Bash is indeed called, I'd guess this is some bug between Make and Bash.
Make, suffix rules and pattern rules. (fwd)
I've verified on my system that suffix rules with prerequisites do
seem to work, as in this example:
.c.o: foo.h
@echo $
Assuming you have foo.c and foo.h in your directory, type "make foo.o",
and see Make echo the name "foo.c".
Is something wrong with the assertion in the docs that "suffix rules
cannot have any prerequisites"?
The part with pattern rules, reported below as not working, does work
for me, so I'm guessing that the original Makefile included something
else which caused the pattern rules not to work.
-- Forwarded message --
Date: Wed, 01 Nov 2000 04:25:53 +0100
From: Jerzy Klejnowski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Newgroups: comp.os.msdos.djgpp
Subject: Make, suffix rules and pattern rules.
Hi!
Maybe I don't understand 'make' documentation, but some things
I've tried seems to behave opposite to what I've read in it.
The documentation says:
"Suffix rules cannot have any prerequisites of their own. If they
have any, they are treated as normal files with funny names, not as
suffix rules."
And below that doc shows an example for '%.o: %.c foo.h' pattern rule
"which tells how to make `.o' files from `.c' files, and makes all `.o'
files using this pattern rule also depend on `foo.h'."
But pattern rule does not work for me, while suffix rule does...
Here's part of my makefile:
--begin--
SHELL = bash
CFLAGS = -many -many -options
.SUFFIXES :
.SUFFIXES : .o .c .h
{various rules}
@echo $
@$(CC) -c $(CFLAGS) $ -o $@
--end--
The results are:
{various rules} what 'make' does
-- -
1 %.o : %.cuses my rule
2 %.o : %.c header.h uses predefined rule
3 .c.o : uses my rule
4 .c.o : header.h uses my rule
Can anybody explain it? Did I misunderstand the docs?
Thanks in advance.
HARY
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
Re: make for windows use the incorrect date for update check
On Fri, 12 Jan 2001, Paul D. Smith wrote: Make use the creation time instead the modification time for update check. ??? Is that a question? Can we possibly have more info, including some motivation? ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make signal text descriptions
Date: Wed, 29 Oct 2003 21:07:39 + From: J. Grant [EMAIL PROTECTED] ok, I've cc [EMAIL PROTECTED], so maybe someone can tell me if signal numbers are decoded. Would you include this internally? or use a lib etc? The signal names are decoded if the underlying library supports them. What port of Make, specifically, do you use? ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make signal text descriptions
Date: Thu, 30 Oct 2003 00:02:55 + From: J. Grant [EMAIL PROTECTED] I noticed on this list list they talk about it being a failed exec: http://www.cygwin.com/ml/cygwin/2003-06/msg00674.html I doubt if this is a signal. It's more probably an error code from a library function that tries to launch a subsidiary process and fails. In other words, if I'm right, some Windows-specific code fails to distinguish between a subprocess being terminated due to a signal and a failure to run the subprocess. A bug that needs to be fixed. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: [patch] README.W32.template
Date: Sat, 22 Nov 2003 21:00:42 -0500 From: Paul D. Smith [EMAIL PROTECTED] Note that this can't be done on Windows, only on UNIX. Well, anyway, I've never done it on Windows and I've never heard of anyone who has. The tools required to build from the CVS archive (GNU m4, Perl, GNU autoconf, GNU automake, and GNU gettext, at least) are easy to install on UNIX systems but I don't know if they'll install properly on Windows. There should be no particular problem to install all those tools on a Windows machine, but in general, there's a need to install a ported Bash as well. There should be no problem running these commands, assuming (I cannot check that where I'm typing this) that they don't use something that Windows disallows, like file names with forbidden character. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Schedule for GNU make 3.81
Date: Wed, 16 Feb 2005 01:45:41 -0500
From: [EMAIL PROTECTED]
Today I am announcing the second beta release of GNU make 3.81. It's
available from my web site, here:
http://make.paulandlesley.org/make-3.81beta2.tar.bz2
http://make.paulandlesley.org/make-3.81beta2.tar.gz
Thanks. I downloaded that and built the DJGPP (a.k.a. MS-DOS) port of
this version of Make, and here are my findings.
1. glob.c needs a patch to not redefine realloc, since (a) the DJGPP
version of realloc does handle NULL pointers, and (b) latest
versions of GCC whine about incompatible arguments being passed to
my_realloc (its arg is char *, but what gets passed to it is some
other kind of pointer).
2. hash.c needs a small patch to stop compiler from complaining about
too large signed int value.
3. Makefile.DOS needs patching due to file-name changes in the doc
subdirectory.
4. Somebody changed job.c so that it tried to include the function
child_execute_job in the MS-DOS build: that neither works nor is
necessary, since the DOS port doesn't use that function.
5. On variable.c, the function define_automatic_variables used to
always export SHELL (there was a line v-export = v_export; right
after SHELL was assigned the default value), but now it doesn't.
There's no ChangeLog entry corresponding to that change, so I
couldn't grasp the reasons for it. In any case, the DOS port needs
SHELL to be exported, because otherwise the library function
`system' doesn't see the value of SHELL modified by the Makefile,
and doesn't DTRT for Makefile's whose commands require a Unixy
shell.
6. The new functions $(abspath) and $(realpath) are Unix-centric:
they used literal '/' for directory separators and don't account
for possible drive letters under HAVE_DOS_PATHS.
7. dosbuild.bat needs hash.c compilation commands to be added to it.
8. The following file names cause trouble on 8+3 filesystems because
they clash with other file names:
tests/scripts/variables/MAKEFILE_LIST
config/inttypes_h.m4
config/inttypes-pri.m4
The patches for problems 1 - 7 are attached below. As for the last
problem, could the offending file names be modified somehow to avoid
the clashes?
Also, the modified code for the abspath function replaces any
backslashes in the DOS/Windows file names with forward slashes;
perhaps this side effect (which I think is a feature) should be
mentioned in make.texi.
Finally, please make sure dosbuild.bat has DOS line endings after you
apply the diffs below. (Otherwise, some DOS/Windows shells will
refuse to run it.)
TIA
ChangeLog entries:
2005-02-19 Eli Zaretskii [EMAIL PROTECTED]
* job.c (child_execute_job): Don't define on MS-DOS.
* variable.c (define_automatic_variables) [__MSDOS__]: Always
export SHELL.
* function.c (abspath): Use IS_PATHSEP instead of a literal '/'.
If HAVE_DOS_PATHS is defined, support d:foo style absolute file
names.
* Makefile.DOS (INFO_DEPS, DVIS, TEXINFOS, doc/make.info)
(doc/make.dvi, .texinfo.info, .texinfo, install-info-am)
(uninstall-info): Use doc/*, since docs is now in a subdirectory,
but remove the `doc/' part when installing or uninstalling.
(.texinfo.info, .texinfo): Rename to .texi.info and .texi.
* hash.c (round_up_2): Use 4294967295U to avoid compiler
warnings.
* dosbuild.bat: Add compilation of hash.c.
--- hash.c.orig 2002-10-14 23:54:04.0 +0200
+++ hash.c 2005-02-19 15:40:16.0 +0200
@@ -324,7 +324,7 @@
n |= (n 8);
n |= (n 16);
-#if !defined(HAVE_LIMITS_H) || ULONG_MAX 4294967295
+#if !defined(HAVE_LIMITS_H) || ULONG_MAX 4294967295U
/* We only need this on systems where unsigned long is 32 bits. */
n |= (n 32);
#endif
--- Makefile.D~02005-02-16 07:40:42.0 +0200
+++ Makefile.DOS2005-02-19 15:55:10.0 +0200
@@ -71,7 +71,7 @@
libglob_a_SOURCES =glob/fnmatch.c glob/glob.c glob/fnmatch.h glob/glob.h
make_LDADD = glob/libglob.a
-info_TEXINFOS =make.texinfo
+info_TEXINFOS =make.texi
man_MANS = make.1
INCLUDES = -I$(srcdir)/glob -DLIBDIR=\c:/djgpp/lib\
-DINCLUDEDIR=\c:/djgpp/include\ -DLOCALEDIR=\$(localedir)\
@@ -104,9 +104,9 @@
LINK = $(CC) $(CFLAGS) $(LDFLAGS) -o $@
TEXI2DVI = texi2dvi
TEXINFO_TEX = $(srcdir)/config/texinfo.tex
-INFO_DEPS = make.info
-DVIS = make.dvi
-TEXINFOS = make.texinfo
+INFO_DEPS = doc/make.info
+DVIS = doc/make.dvi
+TEXINFOS = doc/make.texi doc/fdl.texi doc/make-stds.texi
man1dir = $(mandir)/man1
MANS = $(man_MANS)
@@ -174,23 +174,23 @@
@command.com /c if exist make.exe del make.exe
$(LINK) $(make_LDFLAGS) $(make_OBJECTS) $(make_LDADD) $(LIBS)
-make.info: make.texinfo
-make.dvi: make.texinfo
+doc/make.info: ${TEXINFOS}
+doc/make.dvi: ${TEXINFOS}
DVIPS = dvips
-.texinfo.info:
- @command.com /c if exist make.info* del
Re: Schedule for GNU make 3.81
Date: Sat, 19 Feb 2005 17:42:42 -0500 Cc: bug-make@gnu.org From: Paul D. Smith [EMAIL PROTECTED] ez 5. On variable.c, the function define_automatic_variables used to ezalways export SHELL (there was a line v-export = v_export; right ezafter SHELL was assigned the default value), but now it doesn't. ezThere's no ChangeLog entry corresponding to that change, so I ezcouldn't grasp the reasons for it. In any case, the DOS port needs ezSHELL to be exported, because otherwise the library function ez`system' doesn't see the value of SHELL modified by the Makefile, ezand doesn't DTRT for Makefile's whose commands require a Unixy ezshell. The info on the new handling of SHELL is here (from the ChangeLog): 2004-11-28 Paul D. Smith [EMAIL PROTECTED] Perhaps you should mention the change to define_automatic_variables in this entry. We can special-case this for DOS, if necessary. It should probably be documented that way as well. Yes. If I had more time, I might be able to find a way to handle the problem without breaking Posix compatibility, but I don't have that kind of free time anymore. Also, the DJGPP port of Make was used many years with auto-exported SHELL, and I presume by now that behavior is relied upon. ez tests/scripts/variables/MAKEFILE_LIST ez config/inttypes_h.m4 ez config/inttypes-pri.m4 Hm. Ouch. Well, we can rename the MAKEFILE_LIST test without too much hassle. That'd be good. Unfortunately, the other two are automatically installed by gettext, and are standard files that are part of the gettext package. Is there any way to rename them in a way that doesn't break the NLS build? Perhaps Bruno could help come up with some ideas? Does the DOS port support gettext? Yes. Although I didn't look there to see what that port does with these 2 files. What happens when you unpack with those filenames? The unpacking utility asks for new names for those files whose names clash. Which isn't a catastrophe, but I'd like to avoid that if possible, since it could confuse users. BTW, there's another problem I didn't mention: the variables/SHELL test fails. Given the comments inside the test script, I'm not surprised ;-) I might find some time to look closer, but could you perhaps tell whether that test is at all supposed to work if SHELL is always exported if set by a Makefile? If it is not supposed to work, it should probably be disabled for the DOS port. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Schedule for GNU make 3.81
Date: Wed, 16 Feb 2005 01:45:41 -0500
From: [EMAIL PROTECTED]
http://make.paulandlesley.org/make-3.81beta2.tar.bz2
http://make.paulandlesley.org/make-3.81beta2.tar.gz
Here's an annoyance with this beta version when I build it with DJGPP
and GCC 3.3.3 or 3.4.3:
gcc -I. -I. -I. -I./glob -DLIBDIR=\c:/djgpp/lib\
-DINCLUDEDIR=\c:/djgpp/include\ -DLOCALEDIR=\/share/locale\ -DHAVE_CONFIG_H
-O2 -g -c file.c
file.c: In function `file_timestamp_cons':
file.c:554: warning: comparison is always true due to limited range of data
type
The macro-expanded version of the function file_timestamp_cons is
below. The expression that triggers the warning seems to be the first
line of the `if' clause, viz.:
if (! (s = (~ (unsigned long long) 0 - (! ((unsigned long long) -1
0) ? (unsigned long long) 0 : ~ (unsigned long long) 0 (sizeof (unsigned
long long) * 8 - 1 - (2 + 1)) (0 ? 30 : 0)) (0 ? 30 : 0)) + (2 + 1) +
(0 ? 10 : 1) - 1)) - (2 + 1)) (0 ? 30 : 0))
I might be wrong, but I think that the offending comparison is this:
(unsigned long long) -1 0
which comes from this line in make.h:
#define INTEGER_TYPE_SIGNED(t) ((t) -1 0)
I tried a few tricks to avoid the warning, but was unable to shut it
up. Can someone see what's wrong and how to fix that?
--
unsigned long long
file_timestamp_cons (const char *fname, time_t s, int ns)
{
int offset = (2 + 1) + (0 ? ns : 0);
unsigned long long product = (unsigned long long) s (0 ? 30 : 0);
unsigned long long ts = product + offset;
if (! (s = (~ (unsigned long long) 0 - (! ((unsigned long long) -1
0) ? (unsigned long long) 0 : ~ (unsigned long long) 0 (sizeof (unsigned
long long) * 8 - 1 - (2 + 1)) (0 ? 30 : 0)) (0 ? 30 : 0)) + (2 + 1) +
(0 ? 10 : 1) - 1)) - (2 + 1)) (0 ? 30 : 0))
product = ts ts = ((~ (unsigned long long) 0 - (!
((unsigned long long) -1 0) ? (unsigned long long) 0 : ~ (unsigned long long)
0 (sizeof (unsigned long long) * 8 - 1 - (2 + 1)) (0 ? 30 : 0)) (0
? 30 : 0)) + (2 + 1) + (0 ? 10 : 1) - 1)))
{
char buf[(((sizeof (unsigned long long) * 8 - 1 - 24) * 302 / 1000) + 1 +
1 + 4 + 25) + 1];
ts = s = 2 ? (2 + 1) : ((~ (unsigned long long) 0 - (! ((unsigned
long long) -1 0) ? (unsigned long long) 0 : ~ (unsigned long long) 0
(sizeof (unsigned long long) * 8 - 1 - (2 + 1)) (0 ? 30 : 0)) (0 ? 30
: 0)) + (2 + 1) + (0 ? 10 : 1) - 1);
file_timestamp_sprintf (buf, ts);
error (((struct floc *)0), ((const char *) (%s: Timestamp out of range;
substituting %s)),
fname ? fname : ((const char *) (Current time)), buf);
}
return ts;
}
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: Schedule for GNU make 3.81
Date: Mon, 21 Feb 2005 08:37:38 -0500 Cc: bug-make@gnu.org, make-w32@gnu.org From: Paul D. Smith [EMAIL PROTECTED] ez file.c: In function `file_timestamp_cons': ez file.c:554: warning: comparison is always true due to limited range of data type Unfortunately there's not much that can be done about this: I've asked Paul Eggert (who wrote these macros) about this. The problem is that the test is explicitly trying to determine whether the type is signed or unsigned: there's no reliable way to do this at configure time that doesn't involve running a program... which we can't do if we want to allow GNU make to be cross-compiled (which we definitely do). Do I understand correctly that you see similar warnings on GNU/Linux systems? If so, perhaps some README should tell that this warning is unavoidable and expected, and should be disregarded. Anyway, on platforms that use pre-cooked config.h files, like configh.DOS, perhaps we could define a macro there that would avoid the warning (since the precise types of the relevant data types is known in advance), and then the other *.h files could use #ifndef? ___ 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
Follow-up Comment #6, bug #15718 (project make): Please try the pretest version of Make 3.81 (beta4). This problem should be fixed in that version. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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
Follow-up Comment #7, bug #15718 (project make): Let me clarify: Comment #6 is for Doug Konrad. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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
Follow-up Comment #8, bug #15718 (project make): Here's a response to Comments #2 and #5: It's not true that ``SHELL variable assignment within Makefile doesn't work for Win32 port of GNU make''. It's just that it's a bit tricky, and also your test Makefile was too simple to force Make to invoke the shell. Try this Makefile instead: SHELL = perl.exe all: ; echo 'hello Note: the unmatched single quote is intentional (it forces Make to invoke the shell)! Also note that the .exe extension is currently required, since Make looks for the shell's file name without appending executable extensions (I think this is a misfeature, so I will try to fix it soon). With these changes in the Makefile, I see with the latest beta of Make 3.81 the same behavior as you see in the Cygwin build. 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, and not only on Windows: GNU Make assumes too much about the shell (it knows about characters that need special treatment and commands that are built into the shell, for starters). Using a program such as Perl that violates these assumptions will generally cause things to fall apart. Children, don't try that at home! ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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
Follow-up Comment #10, bug #15718 (project make): I'm not sure it's a bug in the Windows port that an arbitrary value of SHELL does not immediately goto slow; after all, it's hard to imagine radically different quoting rules for the relatively simple-minded shells we have on WIndows. But I will think about this some more when I find time to work on this issue. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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
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 #15718] Weird behavior of the SHELL variable on Win32
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: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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: [bug #15718] Weird behavior of the SHELL variable on Win32
Date: Sat, 4 Mar 2006 20:17:20 +0200
From: Eli Zaretskii [EMAIL PROTECTED]
The fact that it doesn't work with setting SHELL from the command line might
mean there's another place in the code where the special treatment of cmd
should be added. Hmmm...
Fixed thusly:
2006-03-04 Eli Zaretskii [EMAIL PROTECTED]
* variable.c (do_variable_definition) [WINDOWS32]: Call the shell
locator function find_and_set_default_shell if SHELL came from the
command line.
--- variable.c~ 2006-02-17 17:29:52.0 +0200
+++ variable.c 2006-03-04 20:46:50.24850 +0200
@@ -1167,7 +1167,8 @@ do_variable_definition (const struct flo
else
#endif /* __MSDOS__ */
#ifdef WINDOWS32
- if ((origin == o_file || origin == o_override) streq (varname, SHELL))
+ if ((origin == o_file || origin == o_override || origin == o_command)
+ streq (varname, SHELL))
{
extern char *default_shell;
___
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
Follow-up Comment #19, bug #15718 (project make): The real bugs wrt SHELL that still need to be worked on are: 1. When the Windows port searches along PATH for a shell whose name is not cmd, it does not try to append the executable extensions, so SHELL=foo would not find foo.exe 2. If the value of SHELL is not a simple file name, Make does the wrong thing: it decides that the shell cannot be found and uses the default value instead. 3. There's also a mess regarding the unixy_shell flag: it is not set/reset correctly, in some situations, if the Makefile or command line specify a non-default shell. The correct place to set that flag is in job.c, where the shell is actually used. The first one is relatively easy to fix, provided that the release won't happen before next weekend. The second and the third I suggest to postpone until after the release. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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
From: David Ergo [EMAIL PROTECTED]
Cc: bug-make@gnu.org, Xavier Marichal [EMAIL PROTECTED],
=?ISO-8859-1?Q?S=E9bastien?= Frippiat [EMAIL PROTECTED]
Sorry, but as a understand the code, sh_chars_sh is an intermediate
variable as sh_chars_dos is, and sh_chars is the real variable to use.
That's true.
I thinks the code is buggy, it should not assume that sh_chars is
sh_chars_sh.
It doesn't. It specifically uses sh_chars_sh to refer to characters
special to a Unixy shell, _even_when_ the shell in use is not a Unixy
shell. That is because many Makefiles are written assuming a Unixy
shell, so they quote special characters with a backslash. These
backslashes need to be removed even if the shell is cmd.exe.
If you have a specific situation where this specific code causes
trouble, please post the sample Makefile and show how it fails.
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?
yes, for MSYS we use Unix code
cygwin build use cygwin dll which is a posix emulation layer
msys build use msys dll which is a posix native layer
What is a ``posix native layer''? A runtime can be either native
(i.e. MS-Windows style) or Posix, but not both.
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
If didn't misunderstood the code, these changes are NOT specific to MSYS
!
First one : as explained above, sh_chars is sh_chars_sh or sh_chars_dos
Well, I hope I now explained why I think it is right. I need to see a
real failure to become convinced otherwise and start thinking about a
solution. If you have such a test case, please show it.
Second one: the code is buggy even for other builds :
Line 352 : check_lastslash = strchr (target, '/') == 0;
So, check_lastslash is true if '/' is not found in target
Line 354 : /* Didn't find it yet : check for DOS-type directories. */
So we must check for DOS-type dirs if not found, so line 355 MUST be
if (check_lastslash)
i.e. if ('/' not found)
Yes, you are right, sorry. I was looking at the wrong line when I
answered your original message.
(Paul, this is the code you changed between beta4 and rc1.)
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?
MSYS has DOS and UNIX paths :
c:\msys\bin, c:/msys/bin and /usr/local/bin are all valid paths under
MSYS.
Then why does the configure scripts says that DOS paths are not
supported on MSYS? Can you say what test there does the wrong thing
for MSYS?
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?
I'm not sure about what is buggy, all I can tell is that if make is
compiled with MSYS realpath then the test 'functions/realpath' in the
tests/ subdir fails at line 19 where the test is :
ifneq ($(realpath ///),/)
$(error)
endif
I assume this means that realpath(///) should return /, but it does
not.
Can you verify this with a simple test program? We need to know for
sure to modify the configure script.
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: make 3.81rc1 / MSYS
From: David Ergo [EMAIL PROTECTED] Cc: bug-make@gnu.org, Xavier Marichal [EMAIL PROTECTED], =?ISO-8859-1?Q?S=E9bastien?= Frippiat [EMAIL PROTECTED] Date: Tue, 07 Mar 2006 09:28:46 +0100 Ok, now I understand. But for MSYS, as it uses unix code, sh_chars_sh is not defined and the code doesn't compile, so maybe another solution is to define it at line 2310 (in the unix case) by something like this : ifdef __MSYS__ char* sh_chars_sh = sh_chars; endif or still another solution, closer to other platforms: at line 2304 define sh_chars_sh instead of sh_chars, and at line 2310, define char* sh_chars = sh_chars_sh; Okay, will do one of these, thanks. 'configure' just check for specific platforms to know if DOS paths are supported. file 'configure', just change line 8105 : #if !defined _WIN32 !defined __WIN32__ !defined __MSDOS__ !defined __EMX__ into : #if !defined _WIN32 !defined __WIN32__ !defined __MSDOS__ !defined __EMX__ !defined __MSYS__ Okay. I assume this means that realpath(///) should return /, but it does not. Can you verify this with a simple test program? We need to know for sure to modify the configure script. see simple test file in attachment : returns 0 if ok 1 if buggy And I assume it returns 1 on MSYS, yes? ___ 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
Follow-up Comment #16, bug #15718 (project make): Thanks. Does it work if you put SHELL=cmd inside the Makefile? That does work for me. The fact that it doesn't work with setting SHELL from the command line might mean there's another place in the code where the special treatment of cmd should be added. Hmmm... ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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
Follow-up Comment #17, bug #15718 (project make): Okay, I've found the culprit: setting SHELL from the command-line arguments wasn't handled as setting it from the Makefile. I think that's a bug (the Unix version doesn't handle SHELL in any special way when it comes from the command line), so I think it should be fixed by the attached patch . ___ Additional Item Attachment: File name: shell.dif Size:0 KB Patch for setting SHELL= on Windows from the command line http://savannah.gnu.org/bugs/download.php?item_id=15718item_file_id=3471 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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
Follow-up Comment #2, bug #16132 (project make): I cannot reproduce this, either, on Windows XP. I tried with and without a Unixy sh.exe on my PATH, and both behave as expected, identically to v3.80 and v3.80b4. (The behavior with and without sh.exe is not identical, but that's because the `echo' built-in behaves differently in each case, as far as removing single and double quotes is concerned.) What kind of sh.exe are you using, and how (with what compiler and development environment) did you build Make 3.81rc1? ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16132 ___ 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
Follow-up Comment #11, bug #16132 (project make): The result without sh.exe is the expected one. So Make is working correctly, and the problem is is (in)compatibility with the Cygwin shell. When I need a Unixy shell, I use the old port of zsh. You should be able to find it on the net (sorry, I don't have a URL handy). It isn't ideal, since it has bugs that prevent it from running a typical configure script, but it works very well for Makefiles that expect a Unixy shell. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16132 ___ 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
Follow-up Comment #13, bug #16132 (project make): Did the OP build the previous versions of Make with the same compiler as the release candidate? If not, perhaps therein lies the reason for the difference, especially if the other versions are Cygwin ports (as opposed to to rc1 that was built with Microsoft Visual C). We did change the backslash handling, but only before the newline, and there are no such combinations in the Makefile presented here. I don't have the Cygwin shell installed on any of my machines, so I cannot test this myself. If the OP can debug this, I'm willing to provide guidance. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16132 ___ 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
Follow-up Comment #18, bug #16132 (project make): Then I suggest that you try replacing the shell as well. As I already wrote, I cannot reproduce this with my version of sh.exe. Alternatively, you could try to debug this and see where exactly the problem lies. If you can afford spending some time with the Visual Studio stepping through the code that invokes the shell, you will find here several people ready to give advice and suggest ideas. As yet another possibility: can your build work without a Unix shell? If so, rename sh.exe (or remove it from PATH), and see if things work for you. Finally, you could try building Make with either HAVE_CYGWIN_SHELL or BATCH_MODE_ONLY_SHELL (but not both!) defined in config.h. Or if you already have one of these defined, try undefining them. Maybe one of these will solve your problems. (If it does, please tell the details, so that we could update the installation instructions.) FWIW, my Make binary is built with both of these undefined. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16132 ___ 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
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: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16132 ___ 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
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: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16132 ___ 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: Contradicting license informations in make.texi
Date: Sun, 26 Mar 2006 13:14:49 +0200 From: Sven Joachim [EMAIL PROTECTED] 1) Version b) lists the ``GNU General Public License'' as an Invariant Section, but does not actually include it. It should mention the GFDL section (which _is_ included) instead. I'm guessing that when the manual was converted to GFDL, the stale reference to GPL was left behind by mistake. 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. I don't think this is a mistake: the printed version mentions cover text because only that version actually has cover text. But IANAL. 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. It says ``version 1.1 or later'', so there's no contradiction, at least not legally. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Problem with overriding def. SHELL-sh.exe on W2000
Date: Mon, 27 Mar 2006 23:05:41 +0200 From: [EMAIL PROTECTED] 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. Yes, this is a known problem with Make on Windows. I believe it has been corrected in the current development code, which will be soon released as Make 3.81. You can try fetching the latest release candidate from this URL: ftp://alpha.gnu.org/gnu/make/make-3.81rc2.tar.gz The file README.W32 includes instructions for building Make on Windows. If this problem doesn't go away with the new version of Make, please report that. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Probable Spam: make 3.81 cannot build gcc 4.x.y
Date: Mon, 03 Apr 2006 14:25:12 +0400 From: =?KOI8-R?Q?=E4=C5=CA=D4=C5=D2_=E1=CC=C5=CB=D3=C1=CE=C4=D2_=F7=C1?= =?KOI8-R?Q?=CC=C5=D2=C9=C5=D7=C9=DE?= [EMAIL PROTECTED] After update GNU make from 3.80 up to 3.81 i cannot build gcc 4.0.2, 4.0.3 and 4.1.0 whith same error: rm -f ./libgcov.a ar rc ./libgcov.a libgcc/./_gcov.o libgcc/./_gcov_merge_add.o libgcc/./_gcov_me rge_single.o libgcc/./_gcov_merge_delta.o libgcc/./_gcov_fork.o libgcc/./_gcov_e xecl.o libgcc/./_gcov_execlp.o libgcc/./_gcov_execle.o libgcc/./_gcov_execv.o li bgcc/./_gcov_execvp.o libgcc/./_gcov_execve.o ranlib ./libgcov.a make[2]: Leaving directory `/export/home/devel/build/gcc-4.0.3/objdir/gcc' echo timestamp stmp-multilib make[1]: Leaving directory `/export/home/devel/build/gcc-4.0.3/objdir/gcc' /bin/bash: -c: line 5: syntax error: unexpected end of file make: *** [multilib.out] Error 2 + exit Please at least show the line about which Bash complains. It's hard to know what's wrong without seing that much, and downloading the humongous GCC distro just to find out what that lines says is not my idea of fun... TIA ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #16286] VPATH and directory cache
Date: Thu, 6 Apr 2006 16:33:04 -0400 From: Paul D. Smith [EMAIL PROTECTED] Cc: All of the behavior you're seeing is explained in my webpages referenced earlier. Given the number of times this comes up in various forums and in the bug tracker, would it be a good idea to include in the manual some of the stuff from your Web pages? Something like a section VPATH Pitfalls, perhaps? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #16362] Regression: make -n causes $(shell) failure on Windows
Follow-up Comment #1, bug #16362 (project make): Sounds like I should stop trying to maintain the Windows port, as I cause more trouble than help. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16362 ___ 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 #16476] Inconsistent function macros - again
Follow-up Comment #3, bug #16476 (project make): AFAIK, WINDOWS32 is used because the GNU Project doesn't like to be part of those who say that MS-Windows is ``a win''. Therefore, we cannot remove WINDOWS32 and use _WIN32 instead. As for its usage policy, WINDOWS32 should be used for OS- and runtime-dependent code, not for compiler-dependent code (so your assumption that it is for the MS compiler is incorrect). The latter should use symbols specific to the offending compiler, such as __MINGW32__, __MSC_VER, etc. That is the theory. The practice could be different, so if you want to clean up the sources wrt this, I'm sure patches will be gladly accepted (although it's perhaps prudent to wait until the reorganization of the code is done). As for Interix, I don't know how to handle that. Ideally, it should not compile any of the WINDOWS32 code, since it is a Posix environment. I think it's a bad design decision for it to define __MSC_VER, since that's the only universal symbol that can be used to distinguish the MS compiler from other Windows compilers. (Such distinction is needed because the MS compiler has its own incompatible extensions and lacks some functionality, which makes it different from other Windows compilers.) In the long run, the fact that __MSC_VER is defined in Interix will be a terrible nuisance for building portable software, because the absolute majority of packages out there assume that __MSC_VER is a Windows compiler. But I'm not holding my breath for MS to stop defining __MSC_VER in Interix. Finally, I'm not too happy to support your suggestion to replace WINDOWS32 by HAVE_ANSI_COMPILER in fnmatch, glob, and elsewhere. The problems with __STDC__ are specific to the Microsoft Visual C, which defines __STDC__ to zero unless a special compiler switch is used to enforce strict ANSI build. As long as WINDOWS32 stays in those #ifdef's, we will remember what is the offending compiler, but if we replace it with a much more anonymous HAVE_ANSI_COMPILER, we will forget the reason very soon, and will some day wonder why the condition is there at all (since any sane ANSI compiler always defines __STDC__ to a non-zero value). ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16476 ___ 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 #16505] Line-continuation backslashes are not stripped
Follow-up Comment #1, bug #16505 (project make): This is not a regression, but a deliberate change whose purpose is to follow the Posix specifications. From NEWS: - quotation -- * WARNING: Backward-incompatibility! In order to comply with POSIX, the way in which GNU make processes backslash-newline sequences in command strings has changed. If your makefiles use backslash-newline sequences inside of single-quoted strings in command scripts you will be impacted by this change. See the GNU make manual subsection Splitting Command Lines (node Splitting Lines), in section Command Syntax, chapter Writing the Commands in Rules, for details. - end quotation --- So your Makefile is in violation of Posix. The simplest change to get it to work is to use double quotes instead of single quotes (and escape the inner double quotes as appropriate). ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16505 ___ 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 #16505] Line-continuation backslashes are not stripped
Follow-up Comment #6, bug #16505 (project make): The Posix behavior has its merits: without it, how does one pass a command line with embedded newlines from a Makefile? The Posix handling of newlines in single quotes permits this. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16505 ___ 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 #16505] Line-continuation backslashes are not stripped
Follow-up Comment #11, bug #16505 (project make): I can understand everything you are saying -- the backward incompatibility, the suggestion to add an explicit warning, the works. The only thing I do NOT understand is why do you insist on telling about the EOF error etc., when you have at least two ways of working around the problem: either use double quotes instead of single quotes, or put the entire multi-line script into a Make variable (in which case you can keep the single quotes)? It should not be too hard to modify your Makefile to work with the new release of Make, without breaking the old releases as well. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16505 ___ 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: Windows XP and make 3.80
Date: Fri, 05 May 2006 10:14:38 -0400 From: =?ISO-8859-1?Q?Pablo_Alarc=F3n_Pavez?= [EMAIL PROTECTED] Command: make clean OS: Windows XP version 2002, service pack 2 make version: 3.80 It interprets rmdir /q /s lib as rmdir /q, rmdir /s and rmdir lib with errors. Do you have an rmdir.exe program somewhere on your PATH? Or perhaps you have a Unixy shell sh.exe somewhere? If so, Make will invoke those Unix-style rmdir commands in preference to the cmd.exe built-in. If you want to be sure the cmd's rmdir is invoked, I suggest to modify your Makefile as follows: clean: @echo make version 3.80 and Windows XP 2002 SP2 cmd.exe /c rmdir /q /s lib ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #16362] Regression: make -n causes $(shell) failure on Windows
Follow-up Comment #3, bug #16362 (project make):
The following patch fixes this bug:
--- function.c~02006-04-01 12:36:40.0 +0300
+++ function.c 2006-05-27 15:58:26.984375000 +0300
@@ -1589,12 +1589,25 @@ func_shell (char *o, char **argv, const
int pid;
#ifndef __MSDOS__
+#ifdef WINDOWS32
+ /* Reset just_print_flag. This is needed on Windows when batch files
+ are used to run the commands, because we normally refrain from
+ creating batch files under -n. */
+ int j_p_f = just_print_flag;
+
+ just_print_flag = 0;
+#endif
/* Construct the argument list. */
command_argv = construct_command_argv (argv[0],
(char **) NULL, (struct file *) 0,
batch_filename);
if (command_argv == 0)
-return o;
+{
+#ifdef WINDOWS32
+ just_print_flag = j_p_f;
+#endif
+ return o;
+}
#endif
/* Using a target environment for `shell' loses in cases like:
@@ -1622,12 +1635,14 @@ func_shell (char *o, char **argv, const
#ifdef WINDOWS32
windows32_openpipe (pipedes, pid, command_argv, envp);
+ /* Restore the value of just_print_flag. */
+ just_print_flag = j_p_f;
if (pipedes[0] 0) {
/* open of the pipe failed, mark as failed execution */
shell_function_completed = -1;
- return o;
+return o;
} else
#elif defined(__MSDOS__)
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=16362
___
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: Bug in builtin function abspath (again)
Date: Tue, 30 May 2006 10:49:17 -0400 Cc: bug-make@gnu.org From: Paul D. Smith [EMAIL PROTECTED] The realpath function will resolve both absolute and relative paths and return the absolute pathname corresponding to pathname. All but the last component of pathname must exist when realpath is called. It's not immediately clear to me what all but the last component of pathname means; presumably it means that the directory containing the last filename in pathname must exist, but that the filename itself does not have to exist. Yes, that seems to be the meaning. But on platforms where there's no realpath, we currently use abspath that doesn't care whether that directory exists. Since Joe Random Hacker might not know whether her Make was built with or without realpath (and the docs don't even tell that realpath falls back on abspath), we should try to emulate realpath as close as we can, I think. I also thought about writing an emulation for realpath by using readlink. Unless I'm missing something, that shouldn't be too hard. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug in builtin function abspath (again)
From: Boris Kolpackov [EMAIL PROTECTED] Date: Wed, 31 May 2006 07:48:12 + (UTC) I just checked the page for realpath in SUS and I don't see anything that implies this. My understanding that all components of the path must exist. So it's probably system-dependent. Yes, that seems to be the meaning. But on platforms where there's no realpath, we currently use abspath that doesn't care whether that directory exists. Since Joe Random Hacker might not know whether her Make was built with or without realpath (and the docs don't even tell that realpath falls back on abspath), we should try to emulate realpath as close as we can, I think. I also thought about writing an emulation for realpath by using readlink. Unless I'm missing something, that shouldn't be too hard. Here is the documentation for realpath and abspath from GNU make manual: Well, granted, I've read this before I wrote the above. Note that this documentation doesn't say what happens on systems where there's no realpath, and most users won't know whether their binary has or doesn't have it. I guess for platforms without realpath, we can emulate it as func_wildcard (func_abspath (...)) rather than just func_abspath (...). Yes, that'd be nice, I think. But using readlink is better (albeit more complicated) because it will then resolve symlinks on systems that have them. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug when redirecting mingw32-make output (w32/sub_proc/sub_proc.c)
From: Roland Puntaier [EMAIL PROTECTED] Date: Fri, 2 Jun 2006 17:36:00 +0200 process_easy: DuplicateHandle(In) failed is issued, when redirecting the mingw32-make output from a parent process. GetStdHandle returns 0, which is not an error, but also no handle to be duplicated. Thanks for the report and the patch, but could you please post a minimal recipe to reproduce the bug? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #17105] problem colon after drive letter in prerequisite
Follow-up Comment #1, bug #17105 (project make): This problem doesn't happen with the native Windows build of Make 3.81. If you rewally need to use the Cygwin build, I suggest to take this up with the Cygwin maintainers: I don't know whether the Cygwin version is supposed to support file names with drive letters. Otherwise, build a native binary, or find a precompiled one somewhere. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=17105 ___ 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: syntax error vpath.c line 348
Date: Mon, 31 Jul 2006 16:16:53 +0200 (MEST) From: Stefan Renz[EMAIL PROTECTED] I just tried to build gnu make for win32 and got an error message like this: syntax error vpath.c line 348 There are too many actual parameters etc. I changed it from n = rindex(*file,, '\\'); to n = rindex(*file, '\\'); What version of Make is that? There's no such line in vpath.c that comes with the latest version 3.81 of GNU Make. Thank you for your report, anyway. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #17381] Compile errors under DJGPP
Follow-up Comment #1, bug #17381 (project make): The following patch should take care of this: 2006-08-12 Eli Zaretskii [EMAIL PROTECTED] * job.h [__MSDOS__]: Use the same prototype for child_execute_job as __EMX__ does. --- job.h~0 2006-02-12 02:16:04.0 +0200 +++ job.h 2006-08-12 15:44:06.87500 +0300 @@ -73,7 +73,7 @@ extern char **construct_command_argv PARAMS ((char *line, char **restp, struct file *file, char** batch_file)); #ifdef VMS extern int child_execute_job PARAMS ((char *argv, struct child *child)); -#elif defined(__EMX__) +#elif defined(__MSDOS__) || defined(__EMX__) extern int child_execute_job PARAMS ((int stdin_fd, int stdout_fd, char **argv, char **envp)); #else extern void child_execute_job PARAMS ((int stdin_fd, int stdout_fd, char **argv, char **envp)); ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=17381 ___ 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: [bug #17381] Compile errors under DJGPP
Date: Tue, 8 Aug 2006 23:03:15 + From: anonymous [EMAIL PROTECTED] Cc: job.c:1898: error: conflicting types for 'child_execute_job' job.h:79: error: previous declaration of 'child_execute_job' was here job.c: In function 'child_execute_job': job.c:1931: error: void value not ignored as it ought to be Thanks. Here's a patch to fix this: 2006-08-12 Eli Zaretskii [EMAIL PROTECTED] * job.h [__MSDOS__]: Use the same prototype for child_execute_job as __EMX__ does. --- job.h~0 2006-02-12 02:16:04.0 +0200 +++ job.h 2006-08-12 15:44:06.87500 +0300 @@ -73,7 +73,7 @@ extern char **construct_command_argv PARAMS ((char *line, char **restp, struct file *file, char** batch_file)); #ifdef VMS extern int child_execute_job PARAMS ((char *argv, struct child *child)); -#elif defined(__EMX__) +#elif defined(__MSDOS__) || defined(__EMX__) extern int child_execute_job PARAMS ((int stdin_fd, int stdout_fd, char **argv, char **envp)); #else extern void child_execute_job PARAMS ((int stdin_fd, int stdout_fd, char **argv, char **envp)); ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #17521] target-specific variables inluding semicolon
Follow-up Comment #1, bug #17521 (project make): This is not a bug, but a documented change in behavior, intended to bring GNU Make in line with Posix specification for Make. From the NEWS file: * WARNING: Backward-incompatibility! In order to comply with POSIX, the way in which GNU make processes backslash-newline sequences in command strings has changed. If your makefiles use backslash-newline sequences inside of single-quoted strings in command scripts you will be impacted by this change. See the GNU make manual subsection Splitting Command Lines (node Splitting Lines), in section Command Syntax, chapter Writing the Commands in Rules, for details. In other words, your Makefile violates Posix rules for Make; in order to fix your Makefile, either use double quotes instead of single quotes, or put the single-quoted string into a Make variable and use that variable in rule's commands. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17521 ___ 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: filenames with colons in them
From: Dan Jacobson [EMAIL PROTECTED] Date: Tue, 05 Sep 2006 03:15:52 +0800 In the make concept index, I hit RET upon * :: rules (double-colon): Double-Colon.(line 6) and I get byte-code: No such node or anchor: : rules (double-colon): Double-Colon here in Debian's emacs-snapshot. In the standalone info reader, on instead jumps to the top node of make. The current CVS Emacs also jumps to the top node of the Make manual. I see no error message. Anyway, that index entry is invalid: the Texinfo manual forbids index entries that have 2 colons in a row. I suggest to report this to the Make maintainer. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make cannot handle prerequisites that contain a colon
From: Bas Holleman [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 10:01:16 + (UTC) Hi Sebastien, About the problem: gmake begin_process CreateProcess failed. I cannot find the beginning of this thread in the archives. This is my experience: The Windows PATH variable is to long. gmake runs in something like a DOS environment. It can not handle more than 256 characters. This is not true: On Windows, PATH can have much more than 256 characters. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: SHELL -c hardwired
From: Dan Jacobson [EMAIL PROTECTED] Date: Sun, 29 Oct 2006 08:02:17 +0800 One can set SHELL, but there's no way to get rid of the -c in case one wants too. E.g., one wants to make SHELL=mysql as an experiment etc. mysql would need a -e, etc. Doesn't it work to customize shell-file-name and shell-command-switch? If not, please report which Emacs function(s) don't honor these variables. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: SHELL -c hardwired
From: Dan Jacobson [EMAIL PROTECTED] Date: Mon, 06 Nov 2006 05:58:15 +0800 One can set SHELL, but there's no way to get rid of the -c in case one wants too. E.g., one wants to make SHELL=mysql as an experiment etc. mysql would need a -e, etc. EZ Doesn't it work to customize shell-file-name and shell-command-switch? EZ If not, please report which Emacs function(s) don't honor these EZ variables. I recall I was talking about a pure make(1) problem, not emacs. Sorry, I guess I was confused. As far as Make is concerned, I think you can say SHELL=mysql -e and have it your way, no? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Tiny project to play with gmake ?
Date: Wed, 15 Nov 2006 13:23:31 +0200 From: Maxim Vexler [EMAIL PROTECTED] To make a good starting point I'm looking for a small (tiny) open source project, one with a few cpp files, some small .h files. A bonus would be if this project uses a small but stable (compile wise) 3rd party library. How about GNU hello? It's available from ftp://ftp.gnu.org/gnu/hello/. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: File path bug on windows platform
Date: Fri, 24 Nov 2006 00:44:42 +0800
From: goodmen [EMAIL PROTECTED]
I'm using gnu make version 3.81. I compile the soucre using msvc7.
Please run this script on ms windows of any version.
===
__this_file := $(lastword $(MAKEFILE_LIST))
__this_file := $(abspath $(__this_file))
__sub_dir_path := $(realpath $(dir $(__this_file))/sub_dir)
$(warning $(__this_file))
$(warning $(__sub_dir_path))
all :
@ echo Please run this gnumake script on M$-windows
===
the realpath do not work as the doc described.
I'm tried to fix this bug, but I trust the skills of the authors than mine.
Here is some info:
in the file function.c , abspath() ,line 1892 says : if (name[0] != '/')
but on windows system, this condition is not an indicator of whether a
string is absolute path.
Thank you for your report.
As of Make 3.81, the functions abspath and realpath are not yet
supported on MS-Windows. They currently only work on Posix platforms.
I hope to have that fixed in the next release.
In fact, I have a preliminary patch to fix that, so if you need this
ASAP, and can rebuild Make from sources on your machine, please try
the patch below and tell me if it works for you.
2006-05-27 Eli Zaretskii [EMAIL PROTECTED]
* function.c (IS_ABSOLUTE, ROOT_LEN): New macros.
(abspath): Support systems that define HAVE_DOS_PATHS (have
drive letters in their file names). Use IS_PATHSEP instead of a
literal '/' comparison. Use IS_ABSOLUTE and ROOT_LEN.
--- function.c~12006-05-27 15:58:26.984375000 +0300
+++ function.c 2006-05-27 17:37:47.453125000 +0300
@@ -1890,6 +1890,14 @@ func_not (char *o, char **argv, char *fu
#endif
+#ifdef HAVE_DOS_PATHS
+#define IS_ABSOLUTE(n) (n[0] n[1] == ':')
+#define ROOT_LEN 3
+#else
+#define IS_ABSOLUTE(n) (n[0] == '/')
+#define ROOT_LEN 1
+#endif
+
/* Return the absolute name of file NAME which does not contain any `.',
`..' components nor any repeated path separators ('/'). */
@@ -1898,13 +1906,14 @@ abspath (const char *name, char *apath)
{
char *dest;
const char *start, *end, *apath_limit;
+ unsigned long root_len = ROOT_LEN;
if (name[0] == '\0' || apath == NULL)
return NULL;
apath_limit = apath + GET_PATH_MAX;
- if (name[0] != '/')
+ if (!IS_ABSOLUTE(name))
{
/* It is unlikely we would make it until here but just to make sure. */
if (!starting_directory)
@@ -1912,12 +1921,40 @@ abspath (const char *name, char *apath)
strcpy (apath, starting_directory);
+#ifdef HAVE_DOS_PATHS
+ if (IS_PATHSEP(name[0]))
+ {
+ /* We have /foo, an absolute file name except for the drive
+letter. Assume the missing drive letter is the current
+drive, which we can get if we remove from starting_directory
+everything past the root directory. */
+ apath[root_len] = '\0';
+ }
+#endif
+
dest = strchr (apath, '\0');
}
else
{
- apath[0] = '/';
- dest = apath + 1;
+ strncpy (apath, name, root_len);
+ apath[root_len] = '\0';
+ dest = apath + root_len;
+ /* Get past the root, since we already copied it. */
+ name += root_len;
+#ifdef HAVE_DOS_PATHS
+ if (!IS_PATHSEP(apath[2]))
+ {
+ /* Convert d:foo into d:./foo and increase root_len. */
+ apath[2] = '.';
+ apath[3] = '/';
+ dest++;
+ root_len++;
+ /* strncpy above copied one character too many. */
+ name--;
+ }
+ else
+ apath[2] = '/'; /* make sure it's a forward slash */
+#endif
}
for (start = end = name; *start != '\0'; start = end)
@@ -1925,11 +1962,11 @@ abspath (const char *name, char *apath)
unsigned long len;
/* Skip sequence of multiple path-separators. */
- while (*start == '/')
+ while (IS_PATHSEP(*start))
++start;
/* Find end of path component. */
- for (end = start; *end != '\0' *end != '/'; ++end)
+ for (end = start; *end != '\0' !IS_PATHSEP(*end); ++end)
;
len = end - start;
@@ -1941,12 +1978,12 @@ abspath (const char *name, char *apath)
else if (len == 2 start[0] == '.' start[1] == '.')
{
/* Back up to previous component, ignore if at root already. */
- if (dest apath + 1)
- while ((--dest)[-1] != '/');
+ if (dest apath + root_len)
+ for (--dest; !IS_PATHSEP(dest[-1]); --dest);
}
else
{
- if (dest[-1] != '/')
+ if (!IS_PATHSEP(dest[-1]))
*dest++ = '/';
if (dest + len = apath_limit)
@@ -1959,7 +1996,7 @@ abspath (const char *name, char *apath)
}
/* Unless it is root strip trailing separator. */
- if (dest apath + 1 dest[-1] == '/')
+ if (dest
Re: Problem with CURDIR variable
From: Paul Smith [EMAIL PROTECTED] Date: Mon, 11 Dec 2006 19:42:51 -0500 Cc: bug-make@gnu.org This test is kind of strange. Unless there's some specific reason the makefile REQUIRES the CURDIR variable to be set by make, it should be rewritten: ifndef CURDIR $(error Please define the CURDIR variable (or use a newer version of GNU make)) endif But this test could be defeated if CURDIR was defined in the environment, right? If so, the test should make sure CURDIR doesn't come from the environment. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug: make igores options, switches and targets
Date: Thu, 18 Jan 2007 22:28:12 +0100 From: Georg-Johann Lay [EMAIL PROTECTED] I have some trouble with GNU make. The make comes from WinAVR, a distribution of avr-gcc for Win32, i.e. mingw. It is the most recent build from 2006-04-21 But the output you show from make --version, viz. make --version GNU Make 3.80 clearly says that this is not the latest version of Make. The latest version is 3.81, and it is available from MinGW. make clean echo clean clean sh -c 'make clean' echo all all sh -c 'echo clean' clean So there is no way to use make recursively or to run it from within a shell script or a Makefile, because it does not recognize any option, switch or target. I cannot reproduce this, neither with a MinGW build of Make 3.80 nor with Make 3.81, but then I don't use the MSYS port of Bash as the shell. Is there anything I can do? It is obviously a problem of make and not of sh. ``Obvioulsy''? I wouldn't say that, since make clean from the shell prompt works just fine. I'd rather think that it's some incompatibility between Make and the shell you are using. Perhaps asking on the MSYS mailing list would help. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Inconsistent behaviour when building in parallel
From: Dirk Heinrichs [EMAIL PROTECTED] Date: Sat, 20 Jan 2007 22:22:04 +0100 So the left hand doesn't know what the right hand does? ??? Would you care to explain where do you see two hands that don't know each what the other one does? As far as I see from Paul's clear description is that Make does the same thing in both situations. What would you expect Make to do in each case? In the parallel case you can't tell exactly what will happen: it depends on your system; how busy it is, what order the various jobs are scheduled by the OS, how long the command takes to execute, etc. It could work perfectly, or it could be run twice, or more times (if there are more than two targets). That's even worse. Really? why? I'm sure you are familiar with the notion of multi-tasking or multi-threading, and know that independent parallel execution threads are much less deterministic than sequential single-threaded ones. While that is a fact of life, this is the first time I hear someone say that it is such a bad thing. Anyway, you can always use -j1 if you don't want parallelism. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18872] problem colon after drive letter in prerequisite
Follow-up Comment #1, bug #18872 (project make): You are using the Cygwin build of Make 3.81, which does not support drive letters in file names (I believe the announcement on the Cygwin mailing list at the time they released Make 3.81 explains why they discontinued support for drive letters.) I suggest to try the patched version of Cygwin Make 3.81, from the URL you cited: http://cygwin.com/ml/cygwin/2006-09/msg00153.html That version should support drive letters in file names. FWIW, the native (non-Cygwin) Windows build of Make 3.81 behaves as you expect: make: *** No rule to make target `c:/myfile.txt', needed by `all'. Stop. The above-mentioned patched Cygwin build uses the same code for drive letter support as the native build, so I have good reasons to believe your problems will be solved once you use the patched version. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18872 ___ 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: BUG while running the make file
Date: Wed, 7 Feb 2007 11:51:56 -0500 From: Raheja, Himanshu [EMAIL PROTECTED] gcc -I.. -I. -I./include -I./common -D_FILE_OFFSET_BITS=64 -I/usr/include -g -W -Wall -Werror -Wno-unused -g -O2 -D_FILE_OFFSET_BITS=64 -g -W -Wall -Werror -Wno-unused -DHAVE_CONFIG_H -c ./common/linksupport.c -o linksupport.o /tmp/ccsjrIuh.s: Assembler messages: /tmp/ccsjrIuh.s:1368: Error: Incorrect register `%rax' used with `l' suffix /tmp/ccsjrIuh.s:1617: Error: Incorrect register `%rax' used with `l' suffix make[1]: *** [linksupport.lo] Error 1 This has nothing to do with Make: the error message comes from the assembler invoked by the compiler (GCC). So either your compiler is misconfigured, or maybe linksupport.c has some invalid inline assembly in it. In any case, you should take it up with whoever maintains LPRng. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: automake-1.10 can't work with make-3.81 in Mingw in Windows XP
Date: Sat, 24 Feb 2007 18:04:28 +0800 (CST) From: haibin zhang [EMAIL PROTECTED] Cc: Hi all: automake-1.10 can't work with make-3.81 in Mingw in Windows XP, but automake-1.9.6 can work with make-3.81. I tested that automake-1.10 can work with make-3.79.1 in Mingw in Windows XP. The result : automake-1.9.6 and make-3.81- fine automake-1.10 and make-3.79.1 - fine automake-1.10 and make-3.81 - bad(X) if I use make-3.81 with automake-1.10, it occur error: make[2]: Leaving directory `e:/zhb_svn/mingw/build/hbstock_build/src' Making all in test make[2]: Entering directory `e:/zhb_svn/mingw/build/hbstock_build/test' g++ -DHAVE_CONFIG_H -I. -I.. -I../../../hbstock/test -Wall -D_MINGW32_ -D_WIN32_ -I/opt/ace/include -I/opt/cppunit/include -I../../../hbstock/include -O2 -MT unitTest.o -MD -MP -MF .deps/unitTest.Tpo -c -o unitTest.o ../../../hbstock/test/unitTest.cpp ../../../hbstock/test/unitTest.cpp:2:52: cppunit/extensions/TestFactoryRegistry.h: No such file or directory ../../../hbstock/test/unitTest.cpp:3:40: cppunit/ui/text/TestRunner.h: No such file or directory I don't know what's happen ? could you help me ? Do the files it complains about actually exist? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: timestamp resolution
Date: Thu, 3 May 2007 23:20:31 +0100 From: James Youngman [EMAIL PROTECTED] Cc: bug-make@gnu.org, [EMAIL PROTECTED] [EMAIL PROTECTED] [ CC += bug-make@gnu.org ] On 5/3/07, Ulrich Drepper [EMAIL PROTECTED] wrote: On today's call we agreed on the following proposal (names are negotiable): 1. add _PC_TIMESTAMP_RESOLUTION [ for those recently joining, this would be a pathconf() configuration option which returns the filesystem timestamp resolution for a given file. ] Is the assumption then that all filesystems record timestamps as values of the form (Epoch + N * pathconf(_PC_TIMESTAMP_RESOLUTION)), where Epoch is the Unix epoch? I can't think offhand of an exception. The difference between the MS-DOS epoch and the Unix epoch is evenly divisible by 2 seconds (I think; though there were 9 leap seconds in the 1970s, hmm...). But might there be an exception I can't immediately recall? Quite probably. Could you please explain why did you CC the bug-make list, and why you mention MS-DOS? The above addition to `pathconf', when introduced, will be only supported on systems that use glibc, is that right? So MS-DOS is not relevant, even if GNU Make uses _PC_TIMESTAMP_RESOLUTION. Btw, the Windows epoch (on NTFS volumes) is 1601. But that probably doesn't matter, either, as glibc is not used. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Build warnings in CVS make 3.81.90
From: Paul Smith [EMAIL PROTECTED] Date: Fri, 11 May 2007 15:15:34 -0400 Cc: GNU Make bug-make@gnu.org function.c: In function 'func_shell': function.c:1597: warning: variable 'error_prefix' might be clobbered by 'longjmp' or 'vfork' function.c:1589: warning: argument 'o' might be clobbered by 'longjmp' or 'vfork' These have been around forever and I don't know how to fix them. If you do, please let me know. I think adding the `volatile' qualifier to the declarations of these variables will make the warning go away. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #20550] Crash with setting SHELL from the commandline
Follow-up Comment #1, bug #20550 (project make): Thanks. I believe this was already reported, and the attached patch (already sent to the maintainer) should fix it. (file #13412) ___ Additional Item Attachment: ___ Reply to this item at: http://savannah.gnu.org/bugs/?20550 ___ 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 #20549] make -n doesn't work recursively
Follow-up Comment #1, bug #20549 (project make): Thanks. I believe the attached patch should take care of this bug. Does it? (file #13414) ___ Additional Item Attachment: ___ Reply to this item at: http://savannah.gnu.org/bugs/?20549 ___ 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 #20550] Crash with setting SHELL from the commandline
Follow-up Comment #3, bug #20550 (project make): Did you try to patch the current CVS? Because I'm not even sure it compiles on Windows (never tried it myself), and the place GCC complains doesn't seem to have anything in common with the patch I sent. Anyway, can we take this to the mailing list? The bug tracker is not a good medium for this kind of discussion, and makes it a pain to attach files and view them. [EMAIL PROTECTED] or [EMAIL PROTECTED] is a much better place. [EMAIL PROTECTED] is specific to the Windows port, and might be even a better place. ___ Reply to this item at: http://savannah.gnu.org/bugs/?20550 ___ 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 #20549] make -n doesn't work recursively
Follow-up Comment #3, bug #20549 (project make): Your report was relative to Make 3.81, and the diffs are relative to that version. I don't track the CVS, and am not even sure it compiles on Windows. Please, let's continue discussing this on one of the Make mailing lists ([EMAIL PROTECTED], [EMAIL PROTECTED], bug-make@gnu.org). ___ Reply to this item at: http://savannah.gnu.org/bugs/?20549 ___ 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 #20550] Crash with setting SHELL from the commandline
Follow-up Comment #4, bug #20550 (project make): Sorry, I meant bug-make, not bug-gnu-emacs, of course. ___ Reply to this item at: http://savannah.gnu.org/bugs/?20550 ___ 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: problem with GNU make configure
Date: Fri, 3 Aug 2007 14:52:53 -0700 (PDT) From: [EMAIL PROTECTED] I am trying to configure GNU make from cygwin and ./configure doesn't run. I have attached the cygwin console capture with the error. I see no attachments. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: problem with GNU make configure
Date: Fri, 3 Aug 2007 14:55:15 -0700 (PDT) From: [EMAIL PROTECTED] oops, here is the attached console capture It's much better to send this as plain text (you can capture it with `tee' or even by copying and pasting the contents into your mailer). My crystal ball says that somehow the configure script god DOS-style CR-LF line endings, which make Cygwin Bash barf. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Switching from CVS to GIT
Date: Sat, 13 Oct 2007 13:59:43 -0400 From: Christopher Faylor [EMAIL PROTECTED] Cc: Isn't there a pure MinGW (not msys) version too? If someone knows where to get it, please tell. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Switching from CVS to GIT
From: Paul Smith [EMAIL PROTECTED] Date: Sat, 13 Oct 2007 12:37:46 -0400 Cc: I'm considering switching from CVS to another form of SCM. Can you tell why? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Switching from CVS to GIT
From: Benoit SIGOURE [EMAIL PROTECTED] Date: Sat, 13 Oct 2007 19:18:42 +0200 Cc: Make Windows [EMAIL PROTECTED], bug-make bug-make@gnu.org I frequently read Git's ML and it seems rather stable on Cygwin. Which for me is a turn-off, because I don't want to install Cygwin. The MSYS version should work too, even though I haven't tried it personally. MSYS is just a fork of Cygwin, so it doesn't solve my problem above. Is there a good native Windows port of GIT? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Switching from CVS to GIT
From: Benoit SIGOURE [EMAIL PROTECTED] Date: Sat, 13 Oct 2007 20:52:58 +0200 Cc: bug-make bug-make@gnu.org On Oct 13, 2007, at 7:59 PM, Christopher Faylor wrote: Isn't there a pure MinGW (not msys) version too? This sounds unlikely because many commands in git-core are shell scripts (or sometimes Perl scripts) written on top of plumbing commands. Another turn-off. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Switching from CVS to GIT
Cc: Make Windows [EMAIL PROTECTED], bug-make bug-make@gnu.org From: Benoit SIGOURE [EMAIL PROTECTED] Date: Sat, 13 Oct 2007 22:09:56 +0200 Is there a good native Windows port of GIT? http://git.or.cz/gitwiki/WindowsInstall Thanks, I already found that page. However, it sounds like it only points to the source (is that right?), and I'm not sure what do I do to download the sources, even if I wanted it. There's no Download link that leads me to some tarball or installer. I'd prefer binaries, as building from sources is notoriously problematic for MinGW ports of complex packages (they usually need many tools to be installed and configured before the build will run to completion, and the setup of those tools is not well documented). But I don't see a pointer to a binary distribution. Git was designed the way we're used to design traditional UNIX programs: lots of small programs, each performing a simple task. Most of the low level commands (called plumbing) are wrapped up in nicer, higher level interfaces (porcelain), and they happen to be written in Shell script (for many of them at least). So I don't think you can seriously use Git without having at least a minimal POSIX environment. Yes, and therein is my gripe: lots of shell scripts means I need a good port of a Unixy shell and other associated utilities that are routinely invoked by shell scripts. I do have these installed, but I really don't want to stress-test their compatibility each time I need to commit a change or update my sandbox. On the other hand, Git has lots of GUIs, one of which (qgit) is written with Qt. Therefore, if it was written properly, it ought to work on Windows too (thanks Qt!). Gitk should also probably work (Tcl/Tk works on Windows AFAIK). I don't know about git-gui. I don't think I need to worry about a GUI front end, since Emacs already supports GIT. But again, having commands that need a Unixy shell will make things harder, even with Emacs, because it by default invokes the stock Windows shell. That is why I asked Paul why he wanted to switch: Make is not a large package, and its group of developers is quite small to expose the problems with CVS. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Switching from CVS to GIT
From: Paul Smith [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], bug-make@gnu.org Date: Sun, 14 Oct 2007 12:57:20 -0400 On Sat, 2007-10-13 at 21:10 +0200, Eli Zaretskii wrote: Can you tell why? The main reasons are lack of functionality in CVS re renaming, removing, and reorganizing files. However, it's not a critical issue; I've lived with it for this long. The other problems CVS has (poor branch/merge, no atomicity, server-only repositories, etc.) are not as big a problem for a project the size of GNU make. Then perhaps you don't need to switch at all. Doing so will require a non-trivial effort; I don't know how your free time, but mine is hardly enough to try debugging an occasional w32-related bug report. Is it really worth wasting what few resources we have on switching to another VCS? Another reason others have mentioned is making it simple for downstream folks to work on make. Ideally I'd be happy to hand over maintenance of the non-POSIX ports (for example) to others more completely, and just pull from their changed trees. Why not give those who do work on non-POSIX ports write access to the CVS tree? It looks like (as someone else mentioned) SVN may be supported on Savannah soonish. So another option is to wait for that. I certainly don't want to switch more than once, if I do decide to switch. SVN certainly sounds as easier for use on Windows than GIT. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: possible memory leak in make 3.81
Date: Mon, 15 Oct 2007 20:12:37 +0100 From: Jon Grant [EMAIL PROTECTED] Cc: bug-make@gnu.org Paul Smith wrote on 14/10/07 22:17: On Sun, 2007-10-14 at 18:33 +0100, Jon Grant wrote: Do they get free'd up when make exits? No. It's quite difficult to do this since the variables are static and so are only visible within that function. In order to free them we'd have to add them to some kind of global free list that could be walked when make was exiting. This will take time when all we want to do is exit... and anyway, the operating system will take care of cleaning that up when we exits. the OS should cover that, but in some case I wonder if there may be a leak left. Would the DOS version for instance result in lost memory the OS cannot reallocate? No. Even DOS releases all the memory of a process that exited or was otherwise terminated. You can only lose memory on DOS if you happen to corrupt the system memory chain (by writing to bad addresses), but in that case you will have a system crash almost instantly anyway. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Switching from CVS to GIT
Date: Mon, 15 Oct 2007 13:36:53 -0700 From: Howard Chu [EMAIL PROTECTED] Cc: bug-make@gnu.org, [EMAIL PROTECTED] IMO the objections to requiring MSYS/Cygwin on Windows made no sense in this discussion. Believe me, it does make sense to some. In a nutshell, if you use Cygwin or MSYS, you are forced to use them, and them alone, as there are subtle incompatibilities with other kinds of programs that can drive you up the wall sometimes. Make is inherently a POSIX command line tool. It's no more POSIX that `ls'. I hope you won't try to claim that `ls' doesn't make sense outside of a POSIX environment. Anybody using it on Windows needs a POSIX environment already anyway. Not really. Make is just a program to invoke other programs given a set of rules. It only (loosely) assumes that those programs produce files, and doesn't care much about anything else. Since not only POSIX tools can produce files, Make does not require a POSIX environment. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Config.h and pid redefinition...
Date: Sat, 8 Dec 2007 21:18:55 +0100 From: Alberto Santini [EMAIL PROTECTED] I compiled make 3.81 on Windows box Vista using MingW - gcc (GCC) 4.2.1-sjlj (mingw32-2). I modified config.h.W32 commenting the line 412: #define pid_t int So it would be better to add a conditional definition because there is a difference between gcc 3.4.x and gcc 4.2.1. Could you please explain what is that difference? Does GCC 4.2.1 somehow define pid_t internally? Thanks. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Invalid opton --B
Date: Mon, 10 Dec 2007 17:07:36 -0800 From: Anand, CJ [EMAIL PROTECTED] The command we use is make OS=nto CPULIST=x86 -B install LDFLAGS=-M The error we get is make: invalid option - B What does make --version say? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Config.h and pid redefinition...
Date: Sat, 15 Dec 2007 18:23:55 +0100 From: Alberto Santini [EMAIL PROTECTED] Cc: bug-make@gnu.org Thanks. Could you please try the patch below, and see if it fixes your original problem? No, it doesn't work, because config.h (see make.h, for instance) is loaded before sys/types.h Yes, that was silly of me. How about the patch below, then? I think the solution is using GCC_VERSION. :( I don't want to use GCC_VERSION, because then I'd need to know exactly which version started defining pid_t. 2007-12-15 Eli Zaretskii [EMAIL PROTECTED] * config.h.W32: Include sys/types.h. [!_PID_T_] (pid_t): Define only if not already defined. --- config.h.W32~0 2006-04-01 12:42:38.0 +0300 +++ config.h.W322007-12-16 06:13:06.03550 +0200 @@ -405,11 +405,16 @@ /* Define to empty if `const' does not conform to ANSI C. */ /* #undef const */ +#include sys/types.h + /* Define to `int' if sys/types.h doesn't define. */ #define gid_t int /* Define to `int' if sys/types.h does not define. */ +/* GCC 4.x reportedly defines pid_t. */ +#ifndef _PID_T_ #define pid_t int +#endif /* Define to `int' if sys/types.h doesn't define. */ #define uid_t int ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Config.h and pid redefinition...
Date: Sun, 9 Dec 2007 09:49:55 +0100 From: Alberto Santini [EMAIL PROTECTED] I modified config.h.W32 commenting the line 412: #define pid_t int So it would be better to add a conditional definition because there is a difference between gcc 3.4.x and gcc 4.2.1. Could you please explain what is that difference? Does GCC 4.2.1 somehow define pid_t internally? In sys/types.h (line 75 - 4.2.1) we have #ifndef _PID_T_ #define _PID_T_ typedef int _pid_t; #ifndef _NO_OLDNAMES typedef _pid_tpid_t; #endif #endif/* Not _PID_T_ */ Thanks. Could you please try the patch below, and see if it fixes your original problem? 2007-12-15 Eli Zaretskii [EMAIL PROTECTED] * config.h.W32 [!_PID_T_] (pid_t): Define only if not already defined. --- config.h.W32~0 2006-04-01 12:42:38.0 +0300 +++ config.h.W322007-12-15 15:54:35.598803300 +0200 @@ -409,7 +409,10 @@ #define gid_t int /* Define to `int' if sys/types.h does not define. */ +/* GCC 4.x reportedly defines pid_t. */ +#ifndef _PID_T_ #define pid_t int +#endif /* Define to `int' if sys/types.h doesn't define. */ #define uid_t int ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Config.h and pid redefinition...
Date: Sun, 16 Dec 2007 11:08:41 +0100 From: Alberto Santini [EMAIL PROTECTED] Cc: bug-make@gnu.org I confirm you the patch works fine. 2007-12-15 Eli Zaretskii [EMAIL PROTECTED] * config.h.W32: Include sys/types.h. [!_PID_T_] (pid_t): Define only if not already defined. Thanks for testing. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Fixing broken djgpp support in make 3.81
From: Juan Manuel Guerrero [EMAIL PROTECTED] Date: Thu, 15 Nov 2007 05:39:46 +0100 Cc: I have appended a small patch that shows the things I had to change to get a working make binary. That patch is not intended to be used. It shall only show the code lines that may need to be adjusted to solve the problems. There may be better ways to solve the issue, but I am not familiar enough with the make sources to provide a better patch. There may be also much more MSDOS or DJGPp specific things that may be fixed. The patch only fixes things that I am aware. Things that may cause trouble are drive letters, checks for absolute patch, etc, etc etc. The usual DOS/WINDOWS things. Thanks, Juan. Your warnings notwithstanding, I did install your patches. I no longer have time to do any significant work on the DJGPP port of Make, so installing your changes will at least give DJGPP users a binary that works better than with the original sources. I have not waiste my time trying to fix the Makefile.DOS, but now that make.texi has been moved into /doc it needs to be adjusted accordingly. It would be nice if rules for dvi, ps, pdf and html could be added. It would also be usefull not to split the MSDOS version of make.info anymore. The extensions .info-[0-9] are changed to .i[0-9] to acomplish with the 8.3 file name rule but it is always forgotten to adjust the file name strings in make.info accordingly. All this difficulties can be avoided by no spliting the info formated docs anymore. Please note that dvi and ps are already supported, and pdf is not supported on any platform. I made all the other changes you suggested; please see the patches below. Thanks again for your efforts supporting DJGPP ports in general, and Make in particular. 2007-12-22 Eli Zaretskii [EMAIL PROTECTED] Suggested by Juan Manuel Guerrero [EMAIL PROTECTED]: * Makefile.DOS.template (info_TEXINFOS): Remove unused variable. (TEXINFOS): Value changed to `doc/make.texi'. (.SUFFIXES): Use .texi instead of .texinfo. (make.info, make.dvi): Depend on doc/make.texi. (.texi.info): New target, instead of .texinfo.info. Change -I switch to $(MAKEINFO) to look in doc/. Use --no-split. (.texi): New target, instead of .texinfo. Change -I switch to $(MAKEINFO) to look in doc/. Use --no-split. (.texi.dvi): New target, instead of .texinfo.dvi. Change -I switch to $(MAKEINFO) to look in doc/. (install-info-am, uninstall-info): Don't look for *.i[0-9] and *.i[0-9][0-9] (due to --no-split above). (noinst_TEXINFOS, TEXI2HTML, TEXI2HTML_FLAGS): New variables. (html, make_1.html): New targets. (.PHONY): Add html. (.SUFFIXES): Add .html. Index: Makefile.DOS.template === RCS file: /sources/make/make/Makefile.DOS.template,v retrieving revision 2.15 diff -u -r2.15 Makefile.DOS.template --- Makefile.DOS.template 4 Jul 2007 19:35:16 - 2.15 +++ Makefile.DOS.template 22 Dec 2007 12:04:40 - @@ -83,7 +83,6 @@ libglob_a_SOURCES =%GLOB_SOURCES% make_LDADD = glob/libglob.a -info_TEXINFOS =make.texinfo man_MANS = make.1 INCLUDES = -I$(srcdir)/glob -DLIBDIR=\c:/djgpp/lib\ -DINCLUDEDIR=\c:/djgpp/include\ -DLOCALEDIR=\$(localedir)\ @@ -118,10 +117,14 @@ TEXINFO_TEX = $(srcdir)/config/texinfo.tex INFO_DEPS = make.info DVIS = make.dvi -TEXINFOS = make.texinfo +TEXINFOS = doc/make.texi +noinst_TEXINFOS = doc/fdl.texi doc/make-stds.texi man1dir = $(mandir)/man1 MANS = $(man_MANS) +TEXI2HTML = texi2html +TEXI2HTML_FLAGS = -split_chapter + NROFF = nroff DIST_COMMON = README ABOUT-NLS AUTHORS COPYING ChangeLog INSTALL Makefile.am Makefile.in NEWS acconfig.h aclocal.m4 alloca.c build.sh-in config.h-in configure configure.in getloadavg.c @@ -136,7 +139,7 @@ default: all .SUFFIXES: -.SUFFIXES: .c .dvi .info .o .obj .ps .texinfo .tex +.SUFFIXES: .c .dvi .info .o .obj .ps .texi .tex .html mostlyclean-hdr: @@ -186,33 +189,41 @@ @command.com /c if exist make.exe del make.exe $(LINK) $(make_LDFLAGS) $(make_OBJECTS) $(make_LDADD) $(LIBS) -make.info: make.texinfo -make.dvi: make.texinfo +# Documentation + +make.info: doc/make.texi +make.dvi: doc/make.texi DVIPS = dvips -.texinfo.info: +.texi.info: @command.com /c if exist make.info* del make.info* @command.com /c if exist make.i* del make.i* - $(MAKEINFO) -I$(srcdir) $ -o ./$@ + $(MAKEINFO) -I$(srcdir)/doc --no-split $ -o ./$@ -.texinfo: +.texi: @command.com /c if exist make.info* del make.info* @command.com /c if exist make.i* del make.i* - $(MAKEINFO) -I$(srcdir) $ -o ./$@ - -.texinfo.dvi: - TEXINPUTS=$(srcdir);$$TEXINPUTSMAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) $ + $(MAKEINFO) -I$(srcdir)/doc --no-split $ -o
Re: GNU make to consider files checksum
From: Giuseppe Scrivano [EMAIL PROTECTED]
Date: Fri, 11 Apr 2008 23:45:02 +0200
Other systems like scons already support this feature and it would be
great to have it for GNU Make too.
I attached a patch against the current CVS to add --use-checksum to
GNU Make, it is just a proof-of-concept but it shows that adding this
feature can really boost a remake.
Thanks. (I'm not the head maintainer, so please wait for Paul and
others to respond.)
+int
+compute_checksum(struct file *new)
+{
+ int checksum = 0;
+ FILE *f;
+ char buffer [4096];
+
+ f = fopen (new-name, r);
This needs to use rb, not r.
Also, what about directories? they cannot be fopen'ed and fread, at
least not on all supported systems.
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: make version
Date: Thu, 17 Apr 2008 16:51:47 +0100 From: ying [EMAIL PROTECTED] Sorry to bother you. When I installed the mingw and msys the current make version is 3.79.1. I tried to install the make 3.80 and cover the previous min-make file. Unfortunately no matter what I did the version is always 3.79. So could you give me any help? Try uninstalling the old version before installing a newer one. Run the Settings-Control Panel-Add or Remove Programs applet, and follow the prompts. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make-3.81: bug-report: function abspath works incorrectly on widows
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 an explicit drive letter to file names such as /foo/bar, and generally treats such names incorrectly. . It doesn't produce fully qualified file names from drive-relative names such as d:foo/bar. . It assumes Windows file names use only `/' as directory separator character, while in reality there could be `\' as well. Apologies if I misread your patch (I didn't really try to apply and use it). Thanks again for working on this. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make-3.81: bug-report: function abspath works incorrectly on widows
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 to keep original GNU Make behavior intact for this case. E.g. /foo/bar must be treated as full qualified path even on MS Windows. No, I think it should prefix the drive letter of the current disk. . 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 Yes, but d:foo/bar and d:/foo/bar are not the same thing. The former refers to the current directory on drive d:, which could be different from the root. . It assumes Windows file names use only `/' as directory separator character, while in reality there could be `\' as well. Yes, it does, but before my patch it assumes the same. And as i can understand it is a common behavior for GNU Make. No, GNU Make supports both types of slashes. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Reimplementing DJGPP support for make.
From: Juan Manuel Guerrero [EMAIL PROTECTED] Date: Mon, 30 Jun 2008 10:12:24 +0200 A couple of months ago I presented a patch to implement DJGPP/MSDOS support in make again. Now that the legal paperwork has been signed and submitted I resent an improved patch again. The patch is based on today's CVS head. Thanks, I will take good care of this when I have time (which might take a while). Thanks for your relentless and long-time support of DJGPP. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: BATCH_MODE_ONLY_SHELL configuration fails with unixy shells
From: Russo, David [EMAIL PROTECTED] Date: Mon, 29 Sep 2008 14:21:59 -0500 There seems to be a bug in make 3.81 when make is configured with BATCH_MODE_ONLY_SHELL enabled. The problem only occurs when BATCH_MODE_ONLY_SHELL is enabled, make determines the shell is unixy, and a recipe has a continuation line. If make determines that the shell is unixy, the generated shell script used to run a rule containing a continuation character will have one too many '\'s. For example, the following makefile fails: all: echo this is\ a test because the generated batch file used to run the echo command above is: echo this is\\ a test This results in two commands being executed (by unixy shells); echo and a. Clearly not what was intended. If I'm not mistaken, the fix is quite simple and I've attached a patch to a description of the problem here: http://savannah.gnu.org/bugs/?24405. I'd appreciate any review/comments of the bug and the patch. Thanks, I installed your changes in the Make CVS. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Fw: error 127
Date: Sat, 11 Oct 2008 02:03:27 -0700 (PDT) From: Uygar UZUNHASAN [EMAIL PROTECTED] g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_SQL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/qt/4/mkspecs/linux-g++ -I. -I/usr/qt/4/include/QtCore -I/usr/qt/4/include/QtCore -I/usr/qt/4/include/QtNetwork -I/usr/qt/4/include/QtNetwork -I/usr/qt/4/include/QtGui -I/usr/qt/4/include/QtGui -I/usr/qt/4/include/QtSql -I/usr/qt/4/include/QtSql -I/usr/qt/4/include -I. -I. -I. -o _tools.o _tools.cpp make: g++: Command not found make: *** [_tools.o] Error 127 You don't have the g++ program, the GNU C++ compiler. Error 127 means the g++ command was not found. You need to install the GNU C++ compiler. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug
Date: Tue, 14 Oct 2008 11:45:43 +0800 From: =?gb2312?B?Q2Fzc2llIFh1KNDsytjIQSkoQkop?= [EMAIL PROTECTED] This program built for i686-pc-mingw32 Report bugs to bug-make@gnu.org make[1]: *** [stfdma.lib] Error 2 make[1]: Leaving directory `D:/SW/5105_5107SingFTABETA3_rc_test/src/objs/ST20' This means Make did not find some file that was needed to build stfdma.lib. But without seeing the corresponding Makefile fragment and the commands that were run, it is impossible to guess what was the cause of this failure. 原来的电脑编译是正确的，为什么现在一编译就有错误呢？请指教~ Sorry, I don't understand this. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #20495] debug version crashes on windows on close(-1)
Additional Item Attachment, bug #20495 (project make): File name: w32clospipe.difSize:0 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?20495 ___ 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 #17277] Pathes longer than 128 Chars fail with make under windows
Follow-up Comment #2, bug #17277 (project make): Fixed with the attached patch (which also fixes bug #25662). (file #17686) ___ Additional Item Attachment: File name: w32searchpath.dif Size:5 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?17277 ___ 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 #17277] Pathes longer than 128 Chars fail with make under windows
Update of bug #17277 (project make): Status:None = Fixed ___ Reply to this item at: http://savannah.gnu.org/bugs/?17277 ___ 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 #25662] PATH (sometimes) not set when set from target-variable
Follow-up Comment #1, bug #25662 (project make): Fixed with the attached patch (which also fixes bug #17277). ___ Reply to this item at: http://savannah.gnu.org/bugs/?25662 ___ 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 #25662] PATH (sometimes) not set when set from target-variable
Update of bug #25662 (project make): Status:None = Fixed Open/Closed:Open = Closed Fixed Release:None = CVS ___ Reply to this item at: http://savannah.gnu.org/bugs/?25662 ___ 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 #25662] PATH (sometimes) not set when set from target-variable
Update of bug #25662 (project make): Open/Closed: Closed = Open ___ Reply to this item at: http://savannah.gnu.org/bugs/?25662 ___ 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 #25662] PATH (sometimes) not set when set from target-variable
Additional Item Attachment, bug #25662 (project make): File name: w32searchpath.dif Size:5 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?25662 ___ 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 #25412] mingw32-make crashes when double quotes at end of PATH
Follow-up Comment #1, bug #25412 (project make): Fixed with the attached patch. ___ Reply to this item at: http://savannah.gnu.org/bugs/?25412 ___ 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 #25412] mingw32-make crashes when double quotes at end of PATH
Update of bug #25412 (project make): Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.gnu.org/bugs/?25412 ___ 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: [bug #26075] $(wildcard) function holds parent directories open preventing deletes
From: Peter Halliday invalid.nore...@gnu.org Date: Fri, 03 Apr 2009 13:28:36 + Cc: I think I have a fix for this issue (at least it's working for me with my makefiles). I have edited dir.c to limit the maximum number of open directories under windows to just 1 (normally it is 10) this results in directories being closed straight away after caching contents. Thanks, but I hope there is a less Draconian solution to this bug. I will have a look when I have time. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
