Issue with 'src/variable.c'

[Gisle Vanem]

Since the commit:
  
https://git.savannah.gnu.org/cgit/make.git/commit/src/variable.c?id=ec348f51d0240ebc64d11c77c461e89c4a8dfed7

src/variable.c doesn't compile:
  variable.c(1642): error C2065: 'specificity': undeclared identifier
  variable.c(1658): error C2065: 'specificity': undeclared identifier

Should it be:

--- a/variable.c 2024-02-07 13:09:06
+++ b/variable.c 2024-02-07 13:30:05
@@ -1638,7 +1638,7 @@
 {
   v = define_variable_in_set (varname, strlen (varname), default_shell,
   origin, flavor == f_recursive,
-  (specificity
+  (scope == s_global
? current_variable_set_list->set
: NULL),
   flocp);
@@ -1654,7 +1654,7 @@
 {
   v = define_variable_in_set (varname, strlen (varname), newval,
   origin, flavor == f_recursive,
-  (specificity
+  (scope == s_global
? current_variable_set_list->set
: NULL),
   flocp);

--
--gv

Re: Ability to print the make database as json - experimental

[Gisle Vanem]

Tim Murphy wrote:


HOW TO GET IT:
===
in the feature/jprint branch on this fork:
https://github.com/tnmurphy/gmake-experimental


Got it and tried to build it. With clang-cl there is
this warning:
  jprint.c(483,40): warning: omitting the parameter name in a function 
definition is a
  C2x extension   [-Wc2x-extensions]
483 | void jstrcache_print_stats(const char *)
|^

With 'cl' it's an error! Simple enough to fix.
But a 'gnumake -P' on a Makefile with a multi-line macro:

define MK_TEST_C
  /*
   * A simple test for loadable .DLLs in GNU-Make.
   */
  #include 
  #include 
  #include 
  ...
endef

generates illegal JSON:

"MK_TEST_C" : {
  "origin": "makefile",
  "private": false,
  "source": "../../Common.Windows",
  "line": 396,
  "define": "  /*
   * A simple test for loadable .DLLs in GNU-Make.
   */
  #include 
-

jsondump says ' unexpected char'. And 'jq' says:
parse error: Invalid string: control characters from
U+ through U+001F must be escaped at line 147, column 12

Re: Warnings on '$\\'

[Gisle Vanem]

Dmitry Goncharov wrote:


There are various techniques.

example 1, define the variable
\:=


This was simple and elegant. Worked w/o any warnings.

Thanks!

Re: Warnings on '$\\'

[Gisle Vanem]

Martin Dorey wrote:


This seems to work:

martind@sirius:~/tmp/vanem-2023-04-14$ cat Makefile
g_trace.h: Makefile; $(file > $@,$(trace_h))

\ = \

define trace_h
   #define G_TRACE(level, fmt, ...)                  $\\
           do {                                      $\\
             if (_g_trace_level() >= level) {        $\\
                _g_trace_color (TRACE_COLOUR_START); $\\
   # 
endef
martind@sirius:~/tmp/vanem-2023-04-14$ make --warn-undefined-variables; cat 
g_trace.h; rm g_trace.h
make: 'g_trace.h' is up to date.
   #define G_TRACE(level, fmt, ...)                  \
           do {                                      \
             if (_g_trace_level() >= level) {        \
                _g_trace_color (TRACE_COLOUR_START); \
   # 


Thanks!

But isn't make overzealous on this warning?
Shouldn't the '$\' be treated as an ESCape character?

Warnings on '$\\'

[Gisle Vanem]

In a makefile I have the need to generate a
multi-line C-macro (for use in Glib):

g_trace.h: Makefile
  $(file > $@,$(trace_h))

define trace_h
  #define G_TRACE(level, fmt, ...)  $\\
  do {  $\\
if (_g_trace_level() >= level) {$\\
   _g_trace_color (TRACE_COLOUR_START); $\\
  # 
endef

Without the '$\\' syntax, I get everything on one line
which I'd rather not want. With the '$\\' endings, g_trace.h
is perfect.

But with 'MAKEFLAGS += --warn-undefined-variables', I get a
bunch of warnings:
  'reference to undefined variable '\''

How can I avoid that?
I read upon '.WARNINGS', but fail to see how to use that in this case.

--
--gv

Re: subst: Mention how to deal with a FROM that has commas in it

[Gisle Vanem]

Dan Jacobson wrote:


(info "(make) Text Functions") says

'$(subst FROM,TO,TEXT)'
  Performs a textual replacement on the text TEXT: each occurrence of
  FROM is replaced by TO.  The result is substituted for the function
  call.  For example,

   $(subst ee,EE,feet on the street)

  produces the value 'fEEt on the strEEt'.

OK, but also do mention how to deal with a FROM that has commas in it.


It's mentioned somewhere else. And this works for me:

  comma := ,
  default:
 @echo '$(subst ee$(comma),EE$(comma),fee$(comma)t on the stree$(comma)t)'

producing 'fEE,t on the strEE,t'

--
--gv

Re: VPATH question

[Gisle Vanem]

Paul Smith wrote:


If you use "-d" you'll get the info you want:

No implicit rule found for 'default'.
Considering target file 'lib'.
Finished prerequisites of target file 'lib'.
No need to remake target 'lib'; using VPATH name 'apps/lib'.
   Finished prerequisites of target file 'default'.


Only adding 'MAKEFLAGS += --warn-undefined-variables' is somewhat
helpful.


You should feel free to do that, if your makefiles are written such
that it doesn't give spurious warnings.  Make has silently expanded
empty variables to the empty string for 40 years and changing that as
the default behavior is not an option.


Ok thanks for the explanation. But I tend to use 'vpath %.c dir'
more and more. It seems a lot faster too.

--
--gv

VPATH question

[Gisle Vanem]

Hello list.

I sometimes have issues when a 'VPATH' doesn't
do what I'd like. E.g. in this 'vpath-test.mak'
file:
  #
  # there is a 'apps/lib' directory here:
  #
  VPATH = apps
  GEN_DIRS = ./lib

  default all: $(GEN_DIRS)
  $(GEN_DIRS):
 mkdir --verbose $@

---

So I want to create a './lib' directory in
'Current Directory', but gnumake won't do it
since there is a 'lib' under 'apps'. Output:
  gnumake: Nothing to be done for 'default'.

Why doesn't it understand the meaning of '.'?
It also drops the '.' in the --debug' output.

Only with a 'vpath %.c apps' it works as expected
off-course.

Besides I feel it's not very helpful explaining why
it won't do "Nothing..". E.g. if I make a typo:
  default all: $(GEN_DIRS2)

it's the same bleeding message. Adding a '--debug=w',
would be nice with a 'why not' message. Only adding
'MAKEFLAGS += --warn-undefined-variables' is somewhat
helpful.

I'm using GNUmake 4.4.0.90 on Win-10.

--
--gv

Crash in hash_free_items()

[Gisle Vanem]

Hello list.

I'm using the very latest GNU-make built on Win-10 by myself.
Except I've disabled the call to 'SetUnhandledExceptionFilter()'.

In one particular Wine Makefile I get a crash in 'hash_free_items()':
  gnumake!hash_free_items+0x22
  gnumake!hash_free+0x30
  gnumake!clear_directory_contents+0x34
  gnumake!find_directory+0xed
  gnumake!dir_file_exists_p+0xd
  gnumake!selective_vpath_search+0x239
  gnumake!vpath_search+0x9d
  gnumake!pattern_search+0x1212
...


This is when creating an .res-file from a .rc-file.
And I use this 'vpath %.rc obj' construct.

I've a hard time creating a minimal example, but running
with max debug (make --debug=verbose), I see this:

Considering target file 'objects/oleview.res'.
 File 'objects/oleview.res' does not exist.
Directory objects cache invalidated (count 1 != command 42)
Directory . cache invalidated (count 40 != command 42)
  Considering target file 'oleview.rc'.
Directory RCS cache invalidated (count 40 != command 42)
Directory ./objects cache invalidated (count 0 != command 42)

--

What does 'count 0' means?

So just sensing 'ctr == 0' is important, I did this:

--- a/dir.c 2022-11-27 02:43:12
+++ b/dir.c 2022-12-30 11:18:00
@@ -493,7 +493,7 @@
   DB (DB_VERBOSE, ("Directory %s cache invalidated (count %lu != command 
%lu)\n",
name, ctr, command_count));

-  if (dir->contents)
+  if (dir->contents && ctr > 0)
 clear_directory_contents (dir->contents);
 }
   else

---


and no more crash in that special Makefile.

--
--gv

Re: Old timestamps in the future?

[Gisle Vanem]

Edward Welbourne wrote:


Indeed, on Unix, time_t is signed and modern GLibc / Linux functions
using it are perfectly happy with values across the whole range of the
type (which extends to well before the big bang).


Thanks for the detailed explanation. Yes, it's rather confusing
with such timestamps on Windows. E.g. in some 'tcpdump' tests
there are NTP timestamp from 1934 which 'strftime()' on Glibc
handles fine. But not on Windows.

--
--gv

Re: Old timestamps in the future?

[Gisle Vanem]

Paul Smith wrote:


... facilities that you don't specify (Cygwin?  MinGW?  WSL?)


I'm using Cygwin as my POSIX toolbox.


But, note that touch writes timestamps in the current timezone by
default.  It could be that your timezone (which you also didn't
specify) makes a difference, when you are talking about timestamps
right at the edge of the epoch.

If you force UTC, for example:

   $ TZ=UTC make

does it make a difference in behavior?


That was it; i.e. no 'has modification time'.

--
--gv

Old timestamps in the future?

[Gisle Vanem]

I have an issue with things like
 touch --date="1970-01-01"

(or 'touch -t time') that I sometime use in makefiles.
E.g. in this makefile:

-
all: test-file-1 test-file-2

test-file-1:
echo 'whatever' > $@
touch -t 197001010100 $@  # Jan 1. 1970, 01:00

test-file-2:
echo 'whatever' > $@
touch -t 197001010020 $@  # Jan 1. 1970, 00:20

clean:
rm -f test-file-1 test-file-2

-

Invoking it a 2nd time, GNU-make warns:
  gnumake: Warning: File 'test-file-2' has modification time 1,8e+19 s in the 
future
  gnumake: Nothing to be done for 'all'.
  gnumake: warning:  Clock skew detected.  Your build may be incomplete.

A file dated '1. Jan. 1970, 00:20' is wrongly claimed to be in the future.
Some wrap going on here or something wrong with the logic in
'remake.c'? But a file dated '1. Jan. 1970, 01:00' is
accepted fine.

Looking at e.g.'is_ordinary_mtime()' it seems a 'st_mtime' must
be larger than some X-value to qualify as a valid timestamp.
So the above 20 min on Windows is not enough to be accepted
as "ordinary" (?)

And what does "Clock skew detected" really mean?
Not in the manual AFAICS.

--
--gv

Macro arguments

[Gisle Vanem]

Hello folks.

I have a question regarding parenthesis
in GNU-make macros. Like in:

  msg = @echo "$(1)"

  ptest_1:
$(call msg, foo (arg1, arg2, arg3))

  ptest_2:
$(call msg, foo, arg1, arg2, arg3)



A 'make ptest_1' shows:
  foo (arg1, arg2, arg3)

and 'make ptest_2' shows:
  foo

as I'd expect since the macro takes only one arg.

So does a "foo (arg1, arg2, arg3)" becomes one
argument due to the parenthesis or something?

I find this parsing a bit strange and inconsistent;
like a comma has no meaning in 'ptest_1'. I did not
find this "issue" in the manual.

GNU Make 4.3.90
Built for Windows32

--
--gv

[bug #62575] Garbled ANSI color codes in Cygwin mintty

[Gisle Vanem]

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

> sh -c 'clang -fansi-escape-codes -fcolor-diagnostics'

Why this when `clang` is giving nice colours w/o any problems
on Windows anyway? 

Please do not add this patch without checking that the
`ENABLE_VIRTUAL_TERMINAL_PROCESSING` works. And it does not work
when "Use legacy console" is in effect. Ref:
https://techcult.com/enable-or-disable-legacy-console-for-command-prompt-and-powershell-in-windows-10/


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: Crash in 'find_and_set_default_shell()'

[Gisle Vanem]

Paul Smith wrote:


... else (b) make has to parse this string
and break it up into words that it can use to call exec() without going
through a shell


The crash and wild call-stack seems to be caused
by an overflow to 'sprintf(sh_path, ..)'. But replacing
with 'snprintf()' works w/o any crash:

--- a/src/main.c 2022-05-10 13:37:02
+++ b/src/main.c 2022-05-11 07:47:07
@@ -956,7 +956,7 @@
 {
   batch_mode_shell = 1;
   unixy_shell = 0;
-  sprintf (sh_path, "%s", search_token);
+  snprintf (sh_path, GET_PATH_MAX, "%s", search_token);
   default_shell = xstrdup (w32ify (sh_path, 0));
   DB (DB_VERBOSE, (_("find_and_set_shell() setting default_shell = %s\n"),
default_shell));
@@ -971,7 +971,7 @@
   else if (_access (search_token, 0) == 0)
 {
   /* search token path was found */
-  sprintf (sh_path, "%s", search_token);
+  snprintf (sh_path, GET_PATH_MAX, "%s", search_token);
   default_shell = xstrdup (w32ify (sh_path, 0));
   DB (DB_VERBOSE, (_("find_and_set_shell() setting default_shell = %s\n"),
default_shell));
@@ -994,7 +994,7 @@
 {
   *ep = '\0';

-  sprintf (sh_path, "%s/%s", p, search_token);
+  snprintf (sh_path, GET_PATH_MAX, "%s/%s", p, search_token);
   if (_access (sh_path, 0) == 0)
 {
   default_shell = xstrdup (w32ify (sh_path, 0));
@@ -1016,7 +1016,7 @@
   /* be sure to check last element of Path */
   if (p && *p)
 {
-  sprintf (sh_path, "%s/%s", p, search_token);
+  snprintf (sh_path, GET_PATH_MAX, "%s/%s", p, search_token);
   if (_access (sh_path, 0) == 0)
 {
   default_shell = xstrdup (w32ify (sh_path, 0));

--

And testing it with:
  set GNUMAKEFLAGS=--debug=verbose,jobs
  gnumake -f Minimal.make

seems to work okay:
  ..
  find_and_set_shell() path search set default_shell = f:/CygWin32/bin/sh.exe
  ..
  CreateProcess(f:\CygWin32\bin\sh.exe,f:/CygWin32/bin/sh.exe -c "echo 
\"Hello\"",...)
  Putting child 012E9F10 (all) PID 20053024 on the chain.
  Live child 012E9F10 (all) PID 20053024
  Main thread handle = 0118
  Hello

--
--gv

Crash in 'find_and_set_default_shell()'

[Gisle Vanem]

Hello list.

Some resent (?) change has caused a crash in
'find_and_set_default_shell()' with this minimal
Makefile:

export PATH := $(PATH):node_modules/.bin
SHELL := env "PATH=$(PATH)" /bin/bash

all:
   @echo "Hello"

---

Without the 'SHELL ..' line, all is good.
Or even a 'SHELL=/bin/bash' works; no ':='.
Not sure what Gnumake is trying to do here.

The MSVC-2022 built version exits with a
"Security check failure or stack buffer overrun
- code c409" at 'gnumake!__report_gsfailure(void)+0x18'

followed by a bogus call-stack; 185 lines of
junk.

I discovered this while trying to build this
project:
  https://github.com/Financial-Times/n-fetch

But I'm not sure if the above shell syntax should
work on Windows or not. And I use 32-bit Cygwin
as my POSIX toolbox.

--
--gv

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

[Gisle Vanem]

Paul Smith wrote:


I'm OK with adding some short text about this into the man page.  As
David mentions it may be important enough to do that since command
being run by make even when the user gives "-n" could give unexpected
or even unpleasant consequences.


The most unpleasant consequences of using 'make -n' and
pressing Ctrl-C, is for me that 'make' hangs real good.
Seemingly waiting for nothing (?); a "dead-lock".
It's this 5 year old bug I believe:
  https://savannah.gnu.org/bugs/?51237

Using his version:
  https://github.com/mbuilov/gnumake-windows/blob/master/gnumake-4.3.exe

as 'make -n ...' on a large complex Makefile, I've seldom seen a
complete hang. But could take some time to stop.

Just my 0.02 €.

--
--gv

Re: Expansion of $(eval..)

[Gisle Vanem]

Paul Smith wrote:


You probably want to escape the non-argument references, so that call
will not run them and instead they will be passed to eval:

define add_c_src
  VPATH += $(1)
  C_SRC += $$(addprefix $(1)/, $(2))
  $$(info Number of 'C_SRC': $$(words $$(C_SRC)))
endef


That's much better. And many thanks for the explanation.


--
--gv

Expansion of $(eval..)

[Gisle Vanem]

Hello list!

I have this really large makefile and
discovered the '$(eval..)' function was handy
to use for this. Like:

  define add_c_src
VPATH += $(1)
C_SRC += $(addprefix $(1)/, $(2))
$(info Number of 'C_SRC': $(words $(C_SRC)))
  endef

  $(eval $(call add_c_src, frmts/ceos, ceosopen.c))
  $(eval $(call add_c_src, frmts/ceos2, ceos.c ceosrecipe.c ceossar.c))
  # ... plus a lot more

  my-target.dll: $(C_SRC:.c=.obj)
 link whatever $^


But I'm curious about how this gets expanded
since the '$(info ..)' tells the length of 'C_SRC'
*before* it's used:
  Number of 'C_SRC': 0
  Number of 'C_SRC': 1

How does this gets expanded an executed?
The chapter "8.1 The eval function" did not make
it clear to me. But adding a:
  count_C_SRC:
$(info Number of 'C_SRC': $(words $(C_SRC)))

tells me the correct number.

Another thing is that if I change to '# $(info ..',
the 'Number of ..' gets printed after all (!)
So a comment gets ignored here AFAICS.

--
--gv

Re: .SECONDEXPANSION problems

[Gisle Vanem]

Dmitry Goncharov wrote:


On Sun, Dec 12, 2021 at 2:15 PM Paul Smith  wrote:

Did something happen when it stopped working, like you updated to a
different version of GNU make?


i bet this make is built from the current git.


Correct.


Thanks for your report.
If you need make from git you should apply
https://savannah.gnu.org/bugs/download.php?file_id=52483
and
https://savannah.gnu.org/bugs/download.php?file_id=52489


After applying those 2 patches and rebuilding, my
makefile with '.SECONDEXPANDSION' now seems to work
fine! Thanks a lot.



regards, Dmitry



--
--gv

.SECONDEXPANSION problems

[Gisle Vanem]

Hello list.

Since some time the cool '.SECONDEXPANSION' feature has
stopped working for me. In a Makefile, I have many rules
to link module .DLLs:

  mod_airspy_source_OBJ   = $(OBJ_DIR)/airspy_source_main.obj
  mod_airspyhf_source_OBJ = $(OBJ_DIR)/airspyhf_source_main.obj
  mod_bladerf_source_OBJ  = $(OBJ_DIR)/bladerf_source_main.obj
  ...

  .SECONDEXPANSION:
  modules/%.dll: $$(mod_$$*_OBJ)
$(call link_DLL, $@, $^)

  $(mod_airspy_source_OBJ): \
 EXTRA_CFLAGS = -I./source_modules/airspy_source/src
   ...

  $(OBJ_DIR)/%_main.obj: source_modules/%/src/main.cpp
 $(call CPP_compile, $<, $@)

  define CPP_compile
$(CC) @$(CC).args $(EXTRA_CFLAGS) -Fo$(strip $(2)) $(1)
@echo
  endef

---

My problem is that 'EXTRA_CFLAGS' is NOT picked up by
the above pattern compile rule when the .SECONDEXPANSION
rule is used. This used to work for sure.

Now, I have to add a 'link_DLL' macro-call for each .DLL.

BTW. Perhaps my problem is related to:
  https://savannah.gnu.org/bugs/?60799

--
--gv

Re: Compile errors with MSVC

[Gisle Vanem]

I wrote:


   dir.c(528,24): error: use of undeclared identifier 'p'
   memcpy (tem, name, p - name + 1);
  ^
   dir.c(532,24): error: use of undeclared identifier 'p'
   for (tend = tem + (p - name - 1);
  ^


I fixed this by:

--- a/src/dir.c 2021-03-18 12:53:01
+++ b/src/dir.c 2021-03-19 13:59:40
@@ -474,6 +474,7 @@

   struct stat st;
   int r;
+  size_t len;
 #ifdef WINDOWS32
   char *w32_path;
 #endif
@@ -482,6 +483,8 @@
   dir_slot = (struct directory **) hash_find_slot (, _key);
   dir = *dir_slot;

+  len = strlen (name);
+
   if (!HASH_VACANT (dir))
 {
   unsigned long ctr = dir->contents ? dir->contents->counter : 
dir->counter;
@@ -499,7 +502,6 @@
   else
 {
   /* The directory was not found.  Create a new entry for it.  */
-  size_t len = strlen (name);

   dir = xmalloc (sizeof (struct directory));
 #if defined(HAVE_CASE_INSENSITIVE_FS) && defined(VMS)
@@ -525,11 +527,11 @@

 /* Remove any trailing slashes.  Windows32 stat fails even on
valid directories if they end in a slash. */
-memcpy (tem, name, p - name + 1);
+memcpy (tem, name, len + 1);
 tstart = tem;
 if (tstart[1] == ':')
   tstart += 2;
-for (tend = tem + (p - name - 1);
+for (tend = tem + len - 1;
  tend > tstart && (*tend == '/' || *tend == '\\');
  tend--)
   *tend = '\0';

-

Avoiding the use of 'p'.

--
--gv

Compile errors with MSVC

[Gisle Vanem]

Hello list.

The Windows port of Gnu-make has some issues:
  dep.h(60): error C2059: syntax error: ';'
  dep.h(61): error C2059: syntax error: '}'
  dep.h(69): error C2059: syntax error: ';'
  dep.h(70): error C2365: 'error': redefinition; previous definition was 
'function'

MSVC does not handle an extra ';' inside a struct.
And:
  dir.c(528,24): error: use of undeclared identifier 'p'
  memcpy (tem, name, p - name + 1);
 ^
  dir.c(532,24): error: use of undeclared identifier 'p'
  for (tend = tem + (p - name - 1);
 ^

I just checked out a copy and saw this when
building with MSVC and clang-cl.

--
--gv

Re: Using Nmake from GNU-make

[Gisle Vanem]

Eli Zaretskii wrote:


gnss_libf2c.lib:
cd libf2c ; nmake.exe -nologo -f Makefile.VC all
cp libf2c/vcfc2.lib $@

but Nmake errors with:
Microsoft (R) Program Maintenance Utility Version 14.26.28806.0
Copyright (C) Microsoft Corporation.  All rights reserved.

NMAKE : fatal error U1065: invalid option '-'
Stop.


Does this happen even if you remove the "cd libf2c" part?  That is,
are you saying that any invocation of NMake from a MinGW-built GNU
Make causes this problem?


The 'cd' doesn't matter. And BTW the GNU-make is built using
MSVC (by myself).

But I discovered that maybe the 'MAKEFLAGS' picked up by NMake
is to blame. Since:
  make -f GNUmakefile FOO_BAR=whatever

triggers the same previous error. But a:
   make -f GNUmakefile

works fine!?

There are some details on MAKEFLAGS here:
  
https://docs.microsoft.com/en-us/cpp/build/reference/makefile-preprocessing-directives?view=vs-2019


What happens if you use redirection, or in some other way force GNU
Make to invoke NMake via a batch file?


Probably worth a try.

> And one more idea: did you try to use '/' as the NMake option
> character instead of '-' ?

No difference. All (?)/most MS tools handle both '/' and '-'.


--
--gv

Using Nmake from GNU-make

[Gisle Vanem]

Hello list.

Now I have the need to use an already quite large
Makefile written for Microsoft's 'NMake', from within
GNU-make 4.390. Like:

gnss_libf2c.lib:
  cd libf2c ; nmake.exe -nologo -f Makefile.VC all
  cp libf2c/vcfc2.lib $@

but Nmake errors with:
  Microsoft (R) Program Maintenance Utility Version 14.26.28806.0
  Copyright (C) Microsoft Corporation.  All rights reserved.

  NMAKE : fatal error U1065: invalid option '-'
  Stop.

Adding a '--debug' gives no clues either.

Rewriting to:

SHELL = cmd.exe:
gnss_libf2c.lib:
  cd libf2c & nmake.exe -nologo -f Makefile.VC all
  cp libf2c/vcfc2.lib $@

gives the same error. I use Cygwin as my shell normally, but
it doesn't look like a SHELL issue to me. From the cmd-line,
Nmake has no problem; hence I suspect some issue with GNU-make.

And using ProcessMonitor, I see no problem with the cmd-line
in CreateProcessA() either. What could I do?

--
--gv

Re: Next release: signal handling rewrite

[Gisle Vanem]

Paul Smith wrote:


What I'm considering is enhancing the EINTRLOOP etc. macros that I have
added across the code to check all system calls for EINTR and restart them,
so that this macro also checks to see if a signal has been received and if
so, calls a handler function.  For almost all signals this is just die()
although of course for SIGCHLD we need something different.  This seems
like a straightforward way to quickly detect signals without a lot of code
churn.


I hope this will improve the situation on Windows where pressing
^C during make (even a 'make -n') will many times just cause make
to hang. It seems another ^C will cause the 'SetConsoleCtrlHandler()'
to simply create another thread that does nothing.

--
--gv

Re: Compacting link-rules

[Gisle Vanem]

Paul Smith wrote:


All the .obj files are missing!?


Oh.  $@ is "bin/animation.exe" so $(@F) is "animation.exe" and
$($(@F)_OBJ) would be "animation.exe_OBJ" but that's not the name of
your variable, so it expands to the empty string.

Sorry I didn't catch this problem in your original suggestion.

You want:

   bin/%.exe: $$($$*_OBJ) $(LIBS)
   ...

because $* matches the pattern stem, which is "animation" in this case.


That seems to work fine. Thanks a lot!

--
--gv

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

Re: Compacting link-rules

[Gisle Vanem]

Paul Smith wrote:


Or, you can enable secondary expansion which will allow you to write:

   .SECONDEXPANSION:

   bin/%.exe: $$($$(@F)_OBJ) $(LIBS)
 $(call link_EXE, $@, $^)


Very compact and nice. But trying it, it wont work.
For 'bin/animation.exe', it expands to:
 bin/animation.exe: $(LIBS)
   link -nologo -debug -incremental:no -map -subsystem:windows
 -out:bin/controls.exe lib/Qwt.lib ...

All the .obj files are missing!?
Trying a:
  .SECONDEXPANSION: $(animation_OBJ)

does not make a difference.

Also a 'make -p' show:
  bin/animation.exe: lib/Qwt.lib
and nothing else.

Qwt.lib is part of $(LIBS).


--
--gv

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

Compacting link-rules

[Gisle Vanem]

Hello list.

I need help with compacting a series of rules like (from a
Qwt makefile):

  animation_OBJ = examples/animation/main.obj \
  examples/animation/plot.obj

  barchart_OBJ = examples/barchart/barchart.obj \
 examples/barchart/main.obj \
 examples/barchart/moc_barchart.obj

  bin/animation.exe: $(animation_OBJ) $(LIBS)
$(call link_EXE, $@, $^)

  bin/barchart.exe: $(barchart_OBJ) $(LIBS)
$(call link_EXE, $@, $^)

  ...  plus a lot more

into a more compact rule like:
  bin/%.exe: $($(@F)_OBJ) $(LIBS)
$(call link_EXE, $@, $^)

But I fail to get a correct param-2 for my link_EXE macro.
What would be the correct syntax for this? (if at all possible).

This is for MSVC/clang-cl. I'm on Windows-10 using GNU-make v 4.2.90.

--
--gv

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

Re: Case-insensitive targets

[Gisle Vanem]

Paul Smith wrote:


Then there's the question of case-preserving or not.  To be case-
preserving, make would have to be doing all string searches and
comparisons using case-insensitive implementations which would be a lot
of code churn.  And we would have to care a lot more about
internationalization since case comparison is highly locale-specific.


Thanks for the detailed explanation.


Besides, there seems to be a mem-leak in that loop.


I see no mem leak in that function...?


Ops, you're right. But there are tons of them elsewhere.
Won't hurt and maybe intentional. I removed the mentioned
'assert()' and see no aborts anywhere else.

But I made a little  implementation using MSVC's
 and dumped the leaks right before 'exit()' in
main.c's 'die()'. The simple case-insensitive-win.mak in my
1st email shows 4410 leaks!

PS. the makefile and diff used for this _DEBUG-mode test is at:
  https://gist.github.com/gvanem/e8d2db10aa6899c752e5df032fd66785

--
--gv

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

Re: Case-insensitive targets

[Gisle Vanem]

Eli Zaretskii wrote:


I'm not sure Make can distinguish between the two kinds.  E.g., the
rules for generating the "phony" target could be given later.  Paul
will know for sure.

And anyway, wouldn't it be confusing if case-sensitivity changed
depending on whether a file exists or doesn't?


Thanks for answering.  I guess so, yes.


I fail to understand all the details around '-DHAVE_CASE_INSENSITIVE_FS',
but is the above .mak-file working as designed on Windows?


Yes.  AFAIR, We deliberately down-case file names we read from the
filesystem before recording them in the Make's internal memory.


Then are there not a problem with adding default suffix rules
for e.g. '.s' and '.S'. According to you "down-case" argument
they must use the same default command?

Can you take a look at 'default.c' in:

install_default_suffix_rules (void)
{
  ...
  for (s = default_suffix_rules; *s != 0; s += 2, loop++)
{
  struct file *f = enter_file (strcache_add (s[0]));
  /* This function should run before any makefile is parsed.  */
  assert (f->cmds == 0);

I put some trace in this loop and saw that some ".c"/".C",
".f"/".F" etc. rules returned 'f->cmds != NULL' and the
assert() triggers in '-DMAKE_MAINTAINER_MODE'.

From makeint.h:

/* Disable assert() unless we're a maintainer.
   Some asserts are compute-intensive.  */
#ifndef MAKE_MAINTAINER_MODE
# define NDEBUG 1
#endif

That assert() doesn't seems to consider Windows.
Besides, there seems to be a mem-leak in that loop.

I'm not building with 'MAKE_MAINTAINER_MODE' normally,
but this time I needed some more details.

--
--gv

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

Case-insensitive targets

[Gisle Vanem]

Hello list.

In a discussion with the LuaList, I got involved with
how GNU-make on Windows handles all targets in a case-
insensitive manner. Like in this 'case-insensitive-win.mak':

-
default: program_name

PROGRAM_NAME Program_Name program_name:
@echo 'Do something for $@.'

-

c:\> make -f case-insensitive-win.mak
case-insensitive-win.mak:3: target 'program_name' given more than once in the 
same rule
case-insensitive-win.mak:3: target 'program_name' given more than once in the 
same rule
Do something for program_name.

-

I understand that real files should be treated in a case-insensitive
manner, but such "phony" targets (whatever it's called)?
The only hit for "sensitive" in my GNU-make.pdf was this:
  Variable names are case-sensitive. The names ‘foo’, ‘FOO’, and ‘Foo’
  all refer to different variables.

I fail to understand all the details around '-DHAVE_CASE_INSENSITIVE_FS',
but is the above .mak-file working as designed on Windows?

If it is, then gnumake aborts in 'install_default_suffix_rules()'
if '-DMAKE_MAINTAINER_MODE' is defined. In default.c, at
 assert (f->cmds == 0);

since AFAICS the implicit ".c" and ".C" rules is the same on Windows.
I can come back to that later.

--
--gv

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

Macro question

[Gisle Vanem]

I have a question regarding a GNU-make macro like this
(which I use to link a MSVC .dll):

  define do_link_DLL
link $(LDFLAGS) -dll -out:$(1) -implib:$(2) \
 -pdb:$(1:.dll=.pdb) -map:$(1:.dll=.map) $(3) > link.tmp
cat link.tmp >> $(1:.dll=.map)
rm -f $(2:.lib=.exp) link.tmp
  endef

Using this as (in a Wireshark makefile):

  wiretap.dll: $(WIRETAP_OBJ)
 $(call do_link_DLL,wiretap.dll,wiretap_imp.lib, $^ $(EXTRA_LIBS))

AFAICS, if the 'link' stage fails, the rule continues to the 'cat' + 'rm' part
regardless. But from gmake's perspective all the commands succeeds (since
cat+rm returns 0). No?

How can I define my macro for gmake to quit on 'link' error?
Can the macro be written into a Perl-like:
  exec("link $args") || die "link failed";

If so, how?

PS. Since I have '-verbose' in LDFLAGS, it is handy to redirect those
  (error) messages into 'link.tmp' in case of a link-failure.

-- 
--gv

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

Re: Macro question

[Gisle Vanem]

Eli Zaretskii wrote:

> The Windows shell understands || and && between 2 commands.  I think
> you already know that, so I'm quite sure I'm missing something here,
> because that's the first thing I'd try.

There is no Windows shell (cmd nor 4nt) involved here. I don't
have any 'SHELL' in the Makefile (nor environment) and sh is on PATH.
Isn't 'sh' supposed to be used then?

--gv



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

Re: Macro question

[Gisle Vanem]

David Boyce wrote:

> First, I think there’s some missing context as you seem to have an
> unusual environment. You’re mixing Unix (cat, rm) and Windows (link)
> invocations; is it Cygwin, GNUWin32, MKS, ???

Thanks for replying.

I'm on Windows 10 using CygWin32 tools together with MSVC tools. (no
problem even with CygWin's link.exe on my PATH; it's after MSVC's link.exe).
Since I had big tool-problems using MSys1 and Msys2 after upgrading to Win10,
I've so far settled on Cygwin32 for it's sh, binutils etc. (but that is probably
off-topic here).

> Second, I suspect the macro is a red herring and thus this is not
> really a “Macro question”. The macro should just expand to the same
> text you’d get by typing it out. What happens when the macro is
> replaced by the equivalent 3-line recipe?

The same result. I tried changing the command to:

  .ONESHELL: wiretap.dll
  SHELL = cmd.exe

  wiretap.dll: $(WIRETAP_OBJ)
 link $(LDFLAGS) -dll -out:wiretap.dll -implib:wiretap_imp.lib \
 -pdb:wiretap.pdb -map:wiretap.map $^ $(EXTRA_LIBS) > 
link.tmp
 echo ERRORLEVEL: %?
 cat link.tmp >> wiretap.map
 rm -f wiretap_imp.exp

The ERRORLEVEL prints some 11xx code in case of error. So 'link' do pass
an exit-code as it should. But in this .ONESHELL case, I'm not sure gmake
should stop.

> Third, there should be nothing you have to do differently because this
> should work as desired. Since you’re not joining the 3 lines together
> with && and \, the result should be a 3-line recipe in which each line
> should abort the recipe on failure.

But it doesn't. I tried a "set GNUMAKEFLAGS=--debug=jobs". The output
wasn't much help.

> Two other little notes: (1) I don’t understand how you can be
> capturing error messages with > redirection, unless link.exe is dumb
> enough to send errors to stdout.

Many MS tools behaves that way. And that is correct IMHO when I've
specified 'link -verbose'. It's a PITA to capture stderr on cmd.
What would gmake have done if link had printed to 'stderr' instead?
I think this is unrelated and the result would have been the same.

> And (2) the second and third macro
> lines could be a little more robust by using $(basename $1) rather
> than assuming the extensions to be .dll and .lib.

I know. My macro was a bit simplified. The full version of it is:

define do_link_DLL
  link $(LDFLAGS) -dll -subsystem:console,5.02 -out:$(strip $(1)) 
-implib:$(strip $(2)) \
  -pdb:$(basename $(1)).pdb -map:$(basename $(1)).map $(3) > 
link.tmp
  cat link.tmp >> $(1:.dll=.map)
  cat link.tmp >> make.log
  rm -f $(2:.lib=.exp) link.tmp
endef

I use $(strip ..) so I can call it with spaces:
  $(call do_link_DLL, wiretap.dll, wiretap_imp.lib, $^ $(EXTRA_LIBS))


--gv


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

Strangeness in w32/subproc/sub_proc.c

[Gisle Vanem]

Some lines in this file seems a bit strange.
Line 755:

 if (arr2envblk(envp, , _needed) == FALSE) {
pproc->last_err = 0;  << !!
pproc->lerrno = E_NO_MEM;
free( command_line );
if (pproc->last_err == ERROR_INVALID_PARAMETER
   && envsize_needed > 32*1024) {

With the above, the 'if (pproc->last_err ..' test will never
be hit. So the "pproc->last_err = 0" should be put after
the warning. Patch attached.

PS. The test on ERROR_MORE_DATA is important too IMHO.

--
--gv
--- a/w32/subproc/sub_proc.c 2015-09-23 14:26:38
+++ b/w32/subproc/sub_proc.c 2015-09-23 14:36:51
@@ -753,14 +753,14 @@

 if (envp) {
 if (arr2envblk(envp, , _needed) == FALSE) {
-pproc->last_err = 0;
 pproc->lerrno = E_NO_MEM;
 free( command_line );
-if (pproc->last_err == ERROR_INVALID_PARAMETER
+if ((pproc->last_err == ERROR_INVALID_PARAMETER || 
pproc->last_err == ERROR_MORE_DATA)
 && envsize_needed > 32*1024) {
 fprintf (stderr, "CreateProcess failed, 
probably because environment is too large (%d bytes).\n",
  envsize_needed);
 }
+pproc->last_err = 0;
 return(-1);
 }
 }
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #45515] [PATCH] Check ERRORLEVEL in subproc.bat and ignore Windows build artifacts.

[Gisle Vanem]

Eli Zaretskii wrote:


Out of curiosity, which parts of the Make build process produce *.lib and
*.sbr files?  (I don't use MSVC.)


'cl -FR' creates .sbr files (Source Browser File). Which IMHO is completely
useless when using .bat-files to build gnumake.

'link' creates a 'gnumake.lib' because of the 'gmk_*' exports in the
resulting gnumake.exe. Which it should in order for the new load file.dll
feature to work.

--
--gv

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

Re: [Bulk] Re: GNU make 4.0.90 prerelease available

[Gisle Vanem]

Eli Zaretskii e...@gnu.org wrote:


Looks good on MS-Windows (I fixed a few minor issues, most of them
specific to the MS-Windows build).


I have only one issue with OpenWatcom. It builds fine except for
a missing 'ftruncate()':

--- Git-Latest/makeint.h 2014-09-21 16:21:17 +
+++ makeint.h   2014-09-22 11:28:59 +
@@ -350,8 +350,8 @@
# include malloc.h
# define pipe(_p)_pipe((_p), 512, O_BINARY)
# define kill(_pid,_sig) w32_kill((_pid),(_sig))
-/* MSVC doesn't have ftruncate.  */
-# ifdef _MSC_VER
+/* MSVC/Watcom doesn't have ftruncate.  */
+# if defined(_MSC_VER) || defined(__WATCOMC__)
#  define ftruncate(_fd,_len) _chsize(_fd,_len)
# endif

--gv

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

C99 feature in loadapi.c

[Gisle Vanem]

The commit
 
http://git.savannah.gnu.org/cgit/make.git/commit/?id=562344122f3a3327ca4e285f203355857c4a25ff

breaks MSVC v16 build because of the C99 feature of 'declaration after code'.
Can you please apply this diff?

---Git-Latest/loadapi.c 2014-09-21 16:21:17 +
+++ loadapi.c   2014-09-22 11:42:06 +
@@ -42,10 +42,11 @@
  /* Preserve existing variable buffer context.  */
  char *pbuf;
  unsigned int plen;
+  char *s;

  install_variable_buffer (pbuf, plen);

-  char *s = xstrdup (buffer);
+  s = xstrdup (buffer);
  eval_buffer (s, floc);
  free (s);

---

--gv

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

Re: Excessive $(strip)

[Gisle Vanem]

Martin Dorey martin.do...@hds.com wrote:


this also removes the newlines.

...

IMHO make 4.x has a too strict definition of white-space.


http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap07.html sayeth:

In the POSIX locale, at a minimum, the space, form-feed, newline, 
carriage-return, tab, and vertical-tab shall be included.


Then the make manual is a bit sloppy in the use of whitespace.
E.g. from the man-page (3.3 Including Other Makefiles):
Whitespace is required between include and the file names, and between file 
names

(plus section 5.9 etc. etc.)

So a:
 include 
 foo.mak


---

should work if that definition was true everywhere, but it doesn't. 


--gv

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

Excessive $(strip)

[Gisle Vanem]

I'm a happy user of the $(file) function and multiline macros/variables
likes this:
..
define FOO_PACKAGE
 exec_prefix=$(FOO_ROOT)
 libdir=$${exec_prefix}/lib
 includedir=$${exec_prefix}/inc
 Version: $(FOO_VERSION)
 Libs: $${libdir}/$(FOO_LIB)
endef

write_pkg:
 $(file  ./foo.pc, $(strip $(FOO_PACKAGE)))

Since I suspect some older pkgconfig programs doesn't like the leading
spaces in foo.pc, I'm using $(strip). But this also removes the newlines. 

My make-manual documents that white space gets stripped off. IMHO 
make 4.x has a too strict definition of white-space. Or have I misunderstood 
how $(strip) is supposed to work?


But I could always have 'define FOO_PACKAGE'
without the leading spaces and do:

write_pkg:
$(file  ./foo.pc,$(FOO_PACKAGE))

But I prefer the nice indent.

--gv

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

Re: Max env-var size on Win-XP

[Gisle Vanem]

 Would you like to write a modified patch along these lines?

Okay, will do. 


Done. Output in this case is now something like:

 process_begin: CreateProcess(g:\MingW32\msys\bin\echo.exe, echo Generating 
.., ...) failed.
 CreateProcess probably failed due to a too large environment. Env-size is 
33881 bytes.
 make (e=87): Parameteren er feil


According to my references, GetVersionEx is supported on Windows 9X,
so there should be no problem using it.  However, I'd like to avoid
looking at the version.


My revised patch doesn't use GetVersionEx(). Attached.

--gv

env_size_warning.diff
Description: Binary data
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Max env-var size on Win-XP

[Gisle Vanem]

Gisle Vanem gva...@yahoo.no wrote:


My revised patch doesn't use GetVersionEx(). Attached.


I forgot the patch for proc.h:

diff --git a/w32/subproc/proc.h b/w32/subproc/proc.h
index 62ebf65..ed8d3d4 100644
--- a/w32/subproc/proc.h
+++ b/w32/subproc/proc.h
@@ -24,6 +24,6 @@ typedef int bool_t;
#define E_NO_MEM   103
#define E_FORK 104

-extern bool_t arr2envblk(char **arr, char **envblk_out);
+extern bool_t arr2envblk(char **arr, char **envblk_out, int *envsize_needed);

--gv

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

Max env-var size on Win-XP

[Gisle Vanem]

According to:
 http://msdn.microsoft.com/en-us/library/windows/desktop/ms682653(v=vs.85).aspx

the total size of the environment is 32kByte. This has hit me several
times in GNU-make when CreateProcess() triggers the mysterious error
87 (ERROR_INVALID_PARAMETER). Like in a very simple rule that involves
'echo':

process_begin: CreateProcess(g:\MingW32\msys\bin\echo.exe, echo Generating 
..., ...) failed.
make (e=87): Parameteren er feil   Invalid parameter.

I've added a patch to arr2envblk() that checks the Win OS-version and prints a 
warning
if 'size_needed' exceeds 32 kByte. 


Googling for this error, returns approx 50.000 hits. So I think this warning is 
warranted.
On Windows Vista and Windows Server 2008 (or above), MS has luckily removed 
that limit. The command-line length has similar limit on Win-XP and below. But that 
error is probably easier to spot.


I'm not sure if the warning should be printed only when --debug=jobs is in 
effect
or always. But only once. Your choice.

Patch attached.

--gv



misc.diff
Description: Binary data
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Max env-var size on Win-XP

[Gisle Vanem]

Eli Zaretskii e...@gnu.org wrote:


Wouldn't it be better to display the error only if CreateProcess fails
with e=87 _and_ the environment is larger than 32KB?  That would allow
us to avoid calling GetVersionEx, which MS wants to deprecate (see
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx).


To use this new Version Helper API, much more rewrite is needed. 
Allthough GetVersionEx() is deprecated, it will still work for the foreseable future.



Would you like to write a modified patch along these lines?


Okay, will do. 

BTW. Do we support Win-9x/ME? If so, maybe we need to use GetVersionEx() more 
 carefully. I.e. loaded dynamically?


--gv

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

$(file) function bug or not?

[Gisle Vanem]

I'm trying to understand if my use of the $(file..) function is correct or 
not. Based on tests/scripts/function/file, I cooked up this little file.mak:


all: file_test
 cat file.out

.PHONY: file_test
file_test:
 rm file.out
 $(file  file.out, Hello)
 $(file  file.out, world)
 @echo 'abspath file.out: $(abspath file.out).'

-

Running 'make  -f file.mak' gives:
 rm file.out
 abspath file.out: G:/MingW32/src/gnu/GNU-Make/file.out.
 cat file.out
 cat: file.out: No such file or directory
 file.mak:2: recipe for target 'all' failed
 gnumake: *** [all] Error 1

--

(I just used the $(abspath file.out) to verify the file.out gets created).

But without the 'rm file.out', everything works fine:

 #rm file.out
 abspath file.out: G:/MingW32/src/gnu/GNU-Make/file.out.
 cat file.out
  Hello
  world

Seems GNU-make (or something else) breaks causality here; the 
docs on the file function (sec. 8.6) has this passage:

 .. In all cases the file is created if it does not exist.

What is going on here? It doesn't change anything if I do cat ./file.out'. So I
don't think it's a shell issue.

GNU Make 4.0.90
Built for Windows32 (MSVC)

--gv

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

Re: $(file) function bug or not?

[Gisle Vanem]

Paul Smith psm...@gnu.org wrote:


Then make invokes the shell with the results of the expansion, which are
the rm and echo commands (and some empty strings which are ignored).

So, the rm is running AFTER the file is created, and deleting it.


Thanks. That makes sense when I think about it.

--gv

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

MSVC runtime lib issue

[Gisle Vanem]

I've compiled the lastest Git-repo with MSVC using the make_msvc_net2003.vcproj
project. This is a bit outdated (was converted to make_msvc_net2003.vcxproj by
my Visual Studio 2010. I also had to insert guile.c in again).

This project file doesn't specify any runtime lib to link with. Hence the default is to use 
LIBCMT.LIB as if '-MT' was used. I would like to build using '-MD' (or '-MDd') which 
pulls in msvcrt[d].dll (most MSVC software seems to be using this CRT these 
days). But then the linker fails at pulling in 'tmpfile' in 'w32/compat/posixfcn.c':


 MSVCRT.lib(MSVCR100.dll) : error LNK2005: _tmpfile already defined in 
posixfcn.obj

Presumably because 'tmpfile' is needed elsewhere in MSVCRT.lib. So can you 
please
rename 'tmpfile' to 'gmake_tmpfile' like so:

--- Git-latest/makeint.h2013-11-27 22:18:35 +
+++ makeint.h   2013-11-29 12:46:04 +
@@ -350,6 +350,8 @@
# include malloc.h
# define pipe(_p)_pipe((_p), 512, O_BINARY)
# define kill(_pid,_sig) w32_kill((_pid),(_sig))
+# define tmpfile()   gmake_tmpfile()
+
/* MSVC doesn't have ftruncate.  */
# ifdef _MSC_VER
#  define ftruncate(_fd,_len) _chsize(_fd,_len)
@@ -362,6 +364,7 @@
void sync_Path_environment (void);
int w32_kill (pid_t pid, int sig);
int find_and_set_default_shell (const char *token);
+FILE *gmake_tmpfile (void);

/* indicates whether or not we have Bourne shell */
extern int no_default_sh_exe;
@@ -580,7 +583,9 @@
extern const gmk_floc *reading_file;
extern const gmk_floc **expanding_var;

+#ifndef WINDOWS32
extern char **environ;
+#endif

extern unsigned short stopchar_map[];
-

--- Git-latest/w32/compat/posixfcn.c2013-10-07 17:04:09 +
+++ w32/compat/posixfcn.c   2013-11-29 12:46:15 +
@@ -262,7 +262,7 @@
   not be writable by our user.  Most of the code borrowed from
   create_batch_file, see job.c.  */
FILE *
-tmpfile (void)
+gmake_tmpfile (void)
{
  char temp_path[MAXPATHLEN];
  unsigned path_size = GetTempPath (sizeof temp_path, temp_path);

--

Using '-MD' also caused an issue with 'environ'. Hence that had to go too:

 g:\mingw32\src\gnu\gnu-make\makeint.h(587) : warning C4273: '_environ' : 
inconsistent dll linkage
 g:\vc_2010\VC\include\stdlib.h(299) : see previous definition of 
'_environ'

I've tested my patch against MingW too with no problems.

--gv

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

Re: load on Windows

[Gisle Vanem]

Eli Zaretskii e...@gnu.org wrote:


What about setting:
  ent-fptr.func_ptr = func;

too?


They are one and the same, since they are members of a union:

 struct function_table_entry
   {
 union {
char *(*func_ptr) (char *output, char **argv, const char *fname);
char *(*alloc_func_ptr) (const char *fname, int argc, char **argv);
 } fptr;


Okay, you're right. I didn't see the union.


Thanks.  Your problem is here:


  EXPORT int mk_test_gmk_setup (const gmk_floc *flocp)
  {
gmk_add_function (hello_world, hello_world, 0, 255, 0);

^^^

Make functions cannot have the '_' character in their names, so it
seems.  Here's why:


Ayyy!!  1 day wasted on such a triffle. May I suggest more warnings
in define_new_function()? It works fine as $(hello-world Hello world).


Btw, Gisle, I don't understand why you needed to use the EXPORT
thingy, the DLL is compiled just fine without it, and only exports
non-static variables and functions anyway. 


Right again. I was thinking more about making a DLL with MSVC.
(without any .def file).

Thanks again.

--gv

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

load on Windows

[Gisle Vanem]

Hi list.

I just built GNU make 3.99.93 using MingW. I tried long and
hard to get the load feature to give me anything useful. But no
success so far with a very simple mk_test.dll.

In my Makefile, I have this:

VERSION = 3.99.93
ifeq ($(MAKE_VERSION),$(VERSION))
-load ./mk_test.dll
endif

The above was needed since I needed to use mingw-make version 3.82.90
to build this new make.exe. Windows doesn't allow make.exe to be linked
while make.exe is running. Duh! How do you Unix guys solve that?
And:

test_dll: 
 @echo 'Loaded modules: $(.LOADED)'  
 @echo 'Make version: $(MAKE_VERSION)' 
 @echo 'FEATURES: $(.FEATURES)' ; \

 @echo 'Calling mk_test: $(mk_test Hello world)'

The output is:
 Loaded modules: mk_test.dll
 Make version: 3.99.93
 FEATURES: target-specific order-only second-expansion else-if shortest-stem 
 undefine oneshell archives jobserver output-sync load

 Calling mk_test:

See? load is there and mk_test.dll is loaded.



My little mk_test.dll is simply trying to echo back some text, but my
function is never called.  I checked with pedump mk_test.dll that the 
symbols mk_test_gmk_setup and plugin_is_GPL_compatible are exported.


Here is some of mk_test.c:

#define EXPORT __declspec(dllexport)

EXPORT int plugin_is_GPL_compatible;

char *say_hello (const char *name, int argc, char **argv)
{
  char *buf = gmk_alloc(1000), *p = buf;

 *(int*)-1 = 1;
..
}

EXPORT int mk_test_gmk_setup (void)
{
 gmk_add_function (mk_test, say_hello, 1, 255, 0);
 return (1);
}

The *(int*)-1 = 1 is just to prove for myself it's called. But it isn't.
What could be the propblem?

--gv




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