GCC-15 complains about missing parameters, this gets found
out when using non-glibc ( e.g. musl ) C library
Fixes
lib/fnmatch.c:124:14: error: conflicting types for 'getenv'; have 'char *(void)'
| 124 | extern char *getenv ();
| | ^~
src/getopt.c: Define parameters of get
GCC-15 complains about missing parameters, this gets found
out when using non-glibc ( e.g. musl ) C library
Fixes
lib/fnmatch.c:124:14: error: conflicting types for 'getenv'; have 'char *(void)'
| 124 | extern char *getenv ();
| | ^~
src/getopt.c: Define parameters of get
Package: make
Version: 4.4.1-1
Severity: minor
Tags: patch
* What led up to the situation?
Checking for defects with a new version
test-[g|n]roff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z < "man
page"
[Use "groff -e ' $' -e '\\~$&#
On Tue, 2025-01-21 at 22:00 +0100, Michael Olbrich wrote:
> Since c3b39d0654c3 "[SV 62514] Honor command line interface flags",
> make incorrectly filters oute multiple -C arguments with the same
> directoy string:
Oh that's bad. Thanks for the patch!
Since c3b39d0654c3 "[SV 62514] Honor command line interface flags", make
incorrectly filters oute multiple -C arguments with the same directoy
string:
$ cd /test && make -C a -C a
make: Entering directory '/test/a'
$ make -C /test/a -C /test/b -C /test/a
make: Entering directory '/test/b'
Skip -
On Sat, Jan 11, 2025 at 3:40 AM Pete Dietl wrote:
> You need a recursive let if you want to be able to define inner functions,
> like a helper function.
That much I understand, but I cannot come up with many scenarios where
that would make sense in Make. Whenever the definition of the inner
func
Jouke,
You need a recursive let if you want to be able to define inner functions,
like a helper function.
On Mon, Dec 30, 2024, 5:21 AM Jouke Witteveen wrote:
> Hi Pete,
>
> On Thu, Dec 26, 2024 at 7:44 AM Pete Dietl wrote:
> > I propose adding a "letrec" builtin to complement the "let" builti
Hi Pete,
On Thu, Dec 26, 2024 at 7:44 AM Pete Dietl wrote:
> I propose adding a "letrec" builtin to complement the "let" builtin.
> The "let" builtin does not allow one to define inner functions or
> mutually recursive definitions.
Can you maybe help me understand why this functionality would be
On Thu, Dec 26, 2024 at 10:37 AM David A. Wheeler wrote:
>
> > On Dec 23, 2024, at 7:56 PM, Britton Leo Kerin
> > wrote:
> >
> > Another crack at per-target .ONESHELL.
> >
> > The major problem with v3 was that the shared struct commands for
> > implicit rules, .DEFAULT rules suffix rules etc. c
> On Dec 23, 2024, at 7:56 PM, Britton Leo Kerin
> wrote:
>
> Another crack at per-target .ONESHELL.
>
> The major problem with v3 was that the shared struct commands for
> implicit rules, .DEFAULT rules suffix rules etc. caused use of .ONESHELL
> with any target covered by such a rules to "
On Mon, 2024-12-09 at 17:18 -0800, Pete Dietl wrote:
> Here is a bit of test code I came up with. Do you think this is
> necessary and or the right approach for testing with extreme values
> of double and long long?
I think the idea of setting values in config-flags.pm.in is correct,
just to keep
@:
Variable names and their values are provided pairwise. "Letrec" strips
any leading whitespace from the expansion of each variable name
argument.
Here is a patch implementing the functionality:
>From 57727f01bbb88e57b13eaed7d4693f8c18a8aa58 Mon Sep 17 00:00:00 2001
From: Pete Dietl
Da
rent ways wrt oneshell: almost certainly they just have an
incomplete list in their .ONESHELL dependency. There are comments in
the remaining FIXMEs in the last commit ("Many more tests") that explain
my reasoning a bit more.
So what I propose for the next (and hopefully final) version of
---
src/job.c | 22 -
tests/scripts/targets/ONESHELL | 848 +
2 files changed, 848 insertions(+), 22 deletions(-)
diff --git a/src/job.c b/src/job.c
index f0a7f6cb..cd24d290 100644
--- a/src/job.c
+++ b/src/job.c
@@ -1135,28 +1135,6 @@ free_ch
---
src/commands.c | 206 ++---
src/commands.h | 18 -
src/default.c | 3 +
src/file.c | 11 +++
src/filedef.h | 2 +
src/job.c | 111 +-
src/main.c | 9 ++-
src/makeint.h | 2 +-
src/read.c | 8
---
.gitignore | 2 ++
Makefile.am | 54 +---
cflow.rc | 16 +++
src/.cscope_rebuild_commands | 1 +
src/main.c | 5
src/myMakeLog.c | 31 +
src
g with extreme values of
> double and long long?
>
> From 4a6e84061fbf2180cf4efec45a215dd8af6481b1 Mon Sep 17 00:00:00 2001
> From: Pete Dietl
> Date: Mon, 9 Dec 2024 17:06:55 -0800
> Subject: [PATCH] arith_tests
>
> ---
> configure.ac| 34 ++
>From 4a6e84061fbf2180cf4efec45a215dd8af6481b1 Mon Sep 17 00:00:00 2001
From: Pete Dietl
Date: Mon, 9 Dec 2024 17:06:55 -0800
Subject: [PATCH] arith_tests
---
configure.ac| 34 ++
tests/config-flags.pm.in| 24 +++--
tests/scripts/functions
eps the discussion on what functionality is
> > actually desirable.
>
> Yeah I'm totally open to discussing a proposal further. I just felt
> like having some working prototype implemented would be useful.
In my opinion the patch is a proposal. If we decide it's best to
AM Paul Smith wrote:
> > I reviewed the previous (lengthy) email thread before looking at this
> > patch.
>
> I guess you mean the thread that at some point was titled "math
> expressions" [1].
> Was there any conclusion there? At some point it gravitated
On Mon, Dec 9, 2024 at 12:11 AM Paul Smith wrote:
> I reviewed the previous (lengthy) email thread before looking at this
> patch.
I guess you mean the thread that at some point was titled "math
expressions" [1].
Was there any conclusion there? At some point it gravitated to a
s
necessary.
3. I will add unit tests in my next submission in addition to addressing
all of your comments.
On Sun, Dec 8, 2024 at 3:11 PM Paul Smith wrote:
> Thanks for this work Pete!
>
> I reviewed the previous (lengthy) email thread before looking at this
> patch.
>
> This is
Thanks for this work Pete!
I reviewed the previous (lengthy) email thread before looking at this
patch.
This is a good first crack. There are a few confusing bits and we will
need tests added for the various corner cases, and documentation. I
can do the docs if you prefer; I usually edit them
I apologize for my tardiness in reviewing this patch; it's been a busy
few weeks here.
On Fri, 2024-11-29 at 12:31 -0800, Pete Dietl wrote:
> > Not sure about such inline 'structs'.
>
> These are called "compound literals" and have been part of C since
>
version of C that I may rely
on? The use of "_Generic" is a C11 thing. I can remove it if we want
to rely only on C99.
Should I write some unit or integration tests?
On Fri, Nov 29, 2024 at 7:34 AM Gisle Vanem wrote:
>
> Pete Dietl wrote:
>
> > Here I submit to you a pa
Pete Dietl wrote:
Here I submit to you a patch that adds the following builtin functions
to make: `add` (addition), `sub` (subtraction), `mul`
(multiplication), `div` (division), `mod` (modulus), `max` (maximum),
`min` (minimum), and `abs` (absolute value). The implementation I
provide supports
Here I submit to you a patch that adds the following builtin functions
to make: `add` (addition), `sub` (subtraction), `mul`
(multiplication), `div` (division), `mod` (modulus), `max` (maximum),
`min` (minimum), and `abs` (absolute value). The implementation I
provide supports both integers and
> On Mon, 2024-11-18 at 12:06 -0900, Britton Leo Kerin wrote:
>> This is the cleaned up version that has a flag rather than twiddling
>> the global. I think it's all reasonably ready now and if there's any
>> possibility of getting it included I'll add tests and documentation.
I think this is g
on.
I think it's a good idea and should be included. I haven't looked at
the details of this patch yet, but adding tests etc. would be welcome.
This is the cleaned up version that has a flag rather than twiddling the
global. I think it's all reasonably ready now and if there's any
possibility of getting it included I'll add tests and documentation.
Britton Leo Kerin (1):
Support per-target .ONESHELL
src/commands.c | 2 +-
src/comman
.ONESHELL is now handled entirely in snap_deps(). I don't think
it ever needs to happen as early as check_specials(), and doing
it in snap_deps() is easier and allows a good warning to be given
if it's used with a dependency that doesn't end up with a recipe.
The per target oneshell flag has been
It just twiddles global one_shell which should obviously be improved.
I moved all handling of .ONESHELL from check_special() in read.c to
snap_deps().
check_specials() and record_files() both happen before snap_deps(), but
the reason given for check_specials() to exists (to prevent a wrong
pa
---
Makefile.am | 9 +
src/.cscope_rebuild_commands | 1 +
src/myMakeLog.c | 31 +++
src/myMakeLog.h | 12
4 files changed, 49 insertions(+), 4 deletions(-)
create mode 100644 src/.cscope_rebuild_command
---
src/Makefile.test_per_target_oneshell | 13 +
1 file changed, 13 insertions(+)
create mode 100644 src/Makefile.test_per_target_oneshell
diff --git a/src/Makefile.test_per_target_oneshell
b/src/Makefile.test_per_target_oneshell
new file mode 100644
index ..52980595
--- /d
If there's interest I'd like to ultimately submit this for inclusion in
GNU Make. There's obviously a way to go but I'd appreciate any early
feedback.
Britton Leo Kerin (3):
Add my dev tools
Functioning per-target .ONESHELL...
File used to test things
Makefile.am
On Fri, 21 Jun 2024 11:36:16 -0400
Dmitry Goncharov wrote:
> On Fri, Jun 21, 2024 at 10:30 AM Paul Smith wrote:
> >
> > On Fri, 2024-06-21 at 09:11 -0400, Dmitry Goncharov wrote:
> > > i hope, Paul approves adding tests of this nature.
> >
> > I have no problems with adding unit tests, as lo
On Fri, Jun 21, 2024 at 10:30 AM Paul Smith wrote:
>
> On Fri, 2024-06-21 at 09:11 -0400, Dmitry Goncharov wrote:
> > i hope, Paul approves adding tests of this nature.
>
> I have no problems with adding unit tests, as long as we can find a way
> to integrate it into the test suite in a reasonable
On Fri, 2024-06-21 at 09:11 -0400, Dmitry Goncharov wrote:
> i hope, Paul approves adding tests of this nature.
I have no problems with adding unit tests, as long as we can find a way
to integrate it into the test suite in a reasonable way.
But this particular thing doesn't really feel like a "te
On Wed, Jun 19, 2024 at 5:37 PM Sergei Trofimovich wrote:
> Glancing at tests/ all the tests exercise user-facing `make` API. What
> would be the best way to validate probabilities?
For this type of code like shuffle, i like testing the function itself,
directly. Just calling the function in a t
On Wed, 19 Jun 2024 10:55:53 -0400
Dmitry Goncharov wrote:
> On Tue, Jun 18, 2024 at 5:38 PM Sergei Trofimovich wrote:
> > After the change probabilities are not as biased:
> >
> > 0 1 2 3
> > _ _ _ _
> > 0 | 24.99 24.99 25.01 25.01
> > 1 |
On Tue, Jun 18, 2024 at 5:38 PM Sergei Trofimovich wrote:
> After the change probabilities are not as biased:
>
> 0 1 2 3
> _ _ _ _
> 0 | 24.99 24.99 25.01 25.01
> 1 | 24.99 25.04 24.99 24.99
> 2 | 25.01 25.00 25.00 24.99
> 3 | 25.01
From: Sergei Trofimovich
Artem Klimov noticed that current shuffle implementation suffers from
probability bias due to a typical bug in the shuffling implementation.
When we consider already shuffled element we slightly bias their
propability.
https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_
Follow-up Comment #2, bug #65773 (group make):
[comment #1 comment #1:]
> This patch is fine by me, but I believe we will need a copyright assignment
for you to accept this and other patches you sent.
>
> Would you like me to send you the form to fill and the instructions to go
with i
Follow-up Comment #3, bug #65771 (group make):
Revised "restore Visual C 6 and newer but older VC 200X builds"
-more std C types/casts used, no more app specific "_quad_t" type
also added a 2nd patch fixing build/compile time, for gnumake on old or very
old (2000s era)
users, still exist. The legacy business users
would have all picked NT 4 or Win 2K at the time (1998-2003 ish) for
BSOD/stability reasons for whatever private biz apps they were using. Plus
GFAEx() is available on Win 98/ME, so gnumake isn't dropping all "dos win"
support, with this imp
Follow-up Comment #2, bug #65771 (group make):
[comment #1 comment #1:]
> Thanks. Some comments to the proposed patch:
>
> @@ -576,8 +578,8 @@ char *ttyname (int);
>
> /* Define {u,}intmax_t if not defined in or . */
> #if !HAVE_STDINT_H && !HAVE_INTTYPES_H
>
Follow-up Comment #1, bug #65776 (group make):
We don't use GetFileAttributesEx because it doesn't exist on old Windows
systems, and GNU Make still wants to support those old systems.
So I don't think we should make these changes, sorrty.
___
Update of bug #65775 (group make):
Assigned to:None => eliz
Component Version:None => SCM
Triage Status:None => Medium Effort
___
ge Status:None => Small Effort
___
Follow-up Comment #1:
I have no objections to installing this patch, subject to copyright assignment
paperwork.
Thanks.
__
ge Status:None => Small Effort
___
Follow-up Comment #1:
This patch is fine by me, but I believe we will need a copyright assignment
for you to accept this and other patches you sent.
Would you like me to send you
Update of bug #65772 (group make):
Severity: 3 - Normal => 1 - Wish
Status:None => Wont Fix
Assigned to:None => eliz
Component Version:
t Version:None => SCM
Triage Status:None => Small Effort
___
Follow-up Comment #1:
Thanks. Some comments to the proposed patch:
@@ -576,8 +578,8 @@ cha
URL:
<https://savannah.gnu.org/bugs/?65776>
Summary: [PATCH 1/3] win32 STAT_LITE
Group: make
Submitter: bulk88
Submitted: Thu 23 May 2024 12:21:38 AM UTC
Severity: 3 - Normal
Item Group: Enhan
URL:
<https://savannah.gnu.org/bugs/?65775>
Summary: [PATCH 2/2] win32 dir.c eliminate OS specific
dir-cache agressive reread vs posix
Group: make
Submitter: bulk88
Submitted: Thu 23 May 2024 12:15:27
URL:
<https://savannah.gnu.org/bugs/?65774>
Summary: [PATCH] win32: use link time optimization for Visual
C Release build
Group: make
Submitter: bulk88
Submitted: Thu 23 May 2024 12:13:06 AM UTC
Sever
URL:
<https://savannah.gnu.org/bugs/?65773>
Summary: [PATCH] win32: on VC always make PDB debugging
symbols for Release
Group: make
Submitter: bulk88
Submitted: Thu 23 May 2024 12:12:06 AM UTC
Severity: 3 -
URL:
<https://savannah.gnu.org/bugs/?65772>
Summary: [PATCH] win32: don't twice search disk for $(SHELL)
unless PATH or SHELL changed
Group: make
Submitter: bulk88
Submitted: Thu 23 May 2024 12:1
URL:
<https://savannah.gnu.org/bugs/?65771>
Summary: [PATCH] restore Visual C 6 and newer but older VC
200X builds
Group: make
Submitter: bulk88
Submitted: Thu 23 May 2024 12:09:44 AM UTC
Severity: 3 -
Add the -J/--detect-job-slots flag as an shorthand equivalent for -j
with a value of nproc+2. The help message is deliberately left ambiguous
so that we could change it to a different heuristic in future, if
desired.
The -J flag is *not* passed through to sub-makes in MAKEFLAGS, but
instead expand
> Isn't nproc or nproc+1 too much? On systems with hyper-threading,
> this will try using too many jobs, and might cause the system be
> significantly less responsive. Maybe nproc/2 is a better default?
There have been many other good suggestions of choices for make -j and the
choice depends upo
DSB wrote:
> Isn't nproc or nproc+1 too much? On systems with hyper-threading,
> this will try using too many jobs, and might cause the system be
> significantly less responsive. Maybe nproc/2 is a better default?
>
>
> This is an interesting question and I suppose the answer depend
>
> Isn't nproc or nproc+1 too much? On systems with hyper-threading,
> this will try using too many jobs, and might cause the system be
> significantly less responsive. Maybe nproc/2 is a better default?
>
This is an interesting question and I suppose the answer depends on many
factors. At my o
> Date: Fri, 12 Apr 2024 07:58:28 +0200
> From: Henrik Carlqvist
> Cc: bug-make@gnu.org, matt.stav.tay...@gmail.com
>
> On Fri, 12 Apr 2024 02:13:36 +0100
> Matt Staveley-Taylor wrote:
> > Browsing the mailing list I can see that the behaviour of -j with no
> > arguments has been discussed a few
appropriate.
Yes, it has been discussed. I would not mind if the default without argument
for -j would be to limit to nproc or nproc+1, instead of like now, creating a
fork bomb when compiling a big project.
Slightly related to this is also a patch contributed by me at
https://savannah.gnu.org/bu
Add the -J/--detect-job-slots flag as an shorthand equivalent for
-j$(nproc). The help message is deliberately left ambiguous so that we
could change it to nproc + 1 in future, if desired.
Signed-off-by: Matt Staveley-Taylor
---
Browsing the mailing list I can see that the behaviour of -j with no
On Wed, 2023-12-13 at 20:05 +0900, KO Myung-Hun wrote:
> mkfifo() on OS/2 is a dummy, even it returns a wrong value on error.
>
> Do not use it on OS/2.
I applied this change, thanks!
--
Paul D. Smith Find some GNU Make tips at:
https://www.gnu.org http://make.
on platforms (if any) where struct ar_hdr
> has members so large that they can represent integers that do not fit
> int uintmax_t.
I applied this, thanks for the patch Paul!
--
Paul D. Smith Find some GNU Make tips at:
https://www.gnu.org http://make.mad-sc
ar
+ || INT_MULTIPLY_WRAPV (val, base, &val)
+ || INT_ADD_WRAPV (val, *ptr - '0', &val)
The patch is correct, but there is an opportunity to understand _why_
the old code is incorrect. The test "result < input", here (nv < val),
is a correct test for
* src/arscan.c (parse_int): Use intprops.h macros rather than trying
to detect integer overflow by hand, and doing it incorrectly.
Here is an example of why the old code was incorrect.
If val == 3689348814741910323, base == 10, *ptr == '0', UINTMAX_WIDTH == 64,
then (val * base) + (*ptr - '0') yiel
mkfifo() on OS/2 is a dummy, even it returns a wrong value on error.
Do not use it on OS/2.
* src/makeint.h (JOBSERVER_USE_FIFO): Do not define on OS/2.
---
src/makeint.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/makeint.h b/src/makeint.h
index d55ccb6f..a50cf54
Thanks for the reply Paul.
On 2023-07-12 17:19, Paul Smith wrote:
On Wed, 2023-07-12 at 17:11 +0200, Torbjorn SVENSSON wrote:
* src/job.c (construct_command_argv_internal): Escape space in
$SHELL
Unfortunately this is so simple. Currently the spaces in the SHELL
variable are not escaped, and
On Wed, 2023-07-12 at 17:11 +0200, Torbjorn SVENSSON wrote:
> > * src/job.c (construct_command_argv_internal): Escape space in
> > $SHELL
Unfortunately this is so simple. Currently the spaces in the SHELL
variable are not escaped, and things like this work:
SHELL := /bin/sh -x
and do what y
Gentle ping...
Kind regards,
Torbjörn
On 2023-07-05 11:09, Torbjörn SVENSSON wrote:
One way to trigger the error is to set SHELL to a path that contain
one space character.
To test the behavior, the following can be used:
TESTDIR="`mktemp -d '/tmp/make test.XX'`" && \
m
One way to trigger the error is to set SHELL to a path that contain
one space character.
To test the behavior, the following can be used:
TESTDIR="`mktemp -d '/tmp/make test.XX'`" && \
mkdir -p "$TESTDIR" && \
cd "$TESTDIR" && \
ln -s /bin/sh sh && \
On Sat, 2023-07-01 at 10:38 -0400, Paul Smith wrote:
> On Sat, 2023-07-01 at 11:50 +0200, Torbjorn SVENSSON wrote:
> > Could anyone with write access review these patches and apply them
> > for me if there is no comments on them?
>
> I have them applied locally. I'll try to get them pushed in the
On Sat, 2023-07-01 at 11:50 +0200, Torbjorn SVENSSON wrote:
> Could anyone with write access review these patches and apply them
> for me if there is no comments on them?
I have them applied locally. I'll try to get them pushed in the next
few days.
Gentle 2nd ping.
Could anyone with write access review these patches and apply them for
me if there is no comments on them?
Kind regards,
Torbjörn
On 2023-06-19 09:03, Torbjorn SVENSSON wrote:
Ping!
Kind regards,
Torbjörn
On 2023-06-09 16:09, Torbjörn SVENSSON wrote:
Hi,
This patch
On Sun, 2023-06-18 at 21:33 +0100, Costas Argyris wrote:
> Just checking to see if there is still interest in this feature.
I had that locally but hadn't had time to test it fully. Pushed now.
Ping!
Kind regards,
Torbjörn
On 2023-06-09 16:09, Torbjörn SVENSSON wrote:
Hi,
This patch series addresses all the errors that GCC 7.3 emits when cross
building for Windows in maintainer mode.
Kind regards,
Torbjörn
> From: Costas Argyris
> Date: Sun, 18 Jun 2023 21:33:03 +0100
> Cc: bug-make@gnu.org
>
> Just checking to see if there is still interest in this feature.
Nothing's changed, so yes.
Just checking to see if there is still interest in this feature.
On Thu, 18 May 2023 at 17:49, Costas Argyris
wrote:
> Please find attached the latest patch with everything done so far,
> including the inconsistency I mentioned in my previous email.
>
> This now has all 3 buil
Contributed by STMicroelectronics
Signed-off-by: Torbjörn SVENSSON
---
src/job.c | 2 +-
src/w32/subproc/sub_proc.c | 6 +++---
src/w32/w32os.c| 8
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/job.c b/src/job.c
index f7f97010..1c66090c
Contributed by STMicroelectronics
Signed-off-by: Torbjörn SVENSSON
---
src/function.c | 2 +-
src/os.h | 5 +
src/w32/compat/posixfcn.c | 3 ++-
src/w32/subproc/sub_proc.c | 4 ++--
src/w32/w32os.c| 20 +++-
5 files changed, 25 i
On 2023-06-09 16:53, Martin Dorey wrote:
Primed by our earlier discussion, I wondered "How does that fix the
bad-function-cast warning?", before belatedly noticing the Subject.
This particular patch does not address the bad cast, it's addressed in patch 6
39
To: bug-make@gnu.org
Cc: Torbjörn SVENSSON
Subject: [PATCH 1/6] Fix GCC compile warning for "declaration-after-statement"
* EXTERNAL EMAIL *
Contributed by STMicroelectronics
Signed-off-by: Torbjörn SVENSSON
---
src/w32/w32os.c | 5 +++--
1 file changed, 3 insertions(+),
Contributed by STMicroelectronics
Signed-off-by: Torbjörn SVENSSON
---
src/job.c| 2 +-
src/main.c | 4 ++--
src/w32/subproc/w32err.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/job.c b/src/job.c
index 34ef9b80..f7f97010 100644
--- a/s
Contributed by STMicroelectronics
Signed-off-by: Torbjörn SVENSSON
---
src/w32/compat/posixfcn.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/w32/compat/posixfcn.c b/src/w32/compat/posixfcn.c
index a89c0657..1af66b79 100644
--- a/src/w32/compat/posixfcn.c
+++ b/src/w
Contributed by STMicroelectronics
Signed-off-by: Torbjörn SVENSSON
---
src/w32/w32os.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/w32/w32os.c b/src/w32/w32os.c
index 33828010..015b685e 100644
--- a/src/w32/w32os.c
+++ b/src/w32/w32os.c
@@ -35,6 +35,7 @@ unsigned
Contributed by STMicroelectronics
Signed-off-by: Torbjörn SVENSSON
---
src/w32/compat/posixfcn.c | 2 +-
src/w32/w32os.c | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/w32/compat/posixfcn.c b/src/w32/compat/posixfcn.c
index 1af66b79..72fe5f2e 100644
--
Hi,
This patch series addresses all the errors that GCC 7.3 emits when cross
building for Windows in maintainer mode.
Kind regards,
Torbjörn
Please find attached the latest patch with everything done so far,
including the inconsistency I mentioned in my previous email.
This now has all 3 build approaches, namely:
1) configure
2) Basic.mk
3) build_w32.bat
treating the resource compiler optionally, and building and
embedding the UTF-8
I think this should be added to README.git. Without these
explanations, the purpose of Basic.mk and its auxiliary files, and of
their intended usage, is completely unclear.
I believe this was going to Paul.From my side, these explanations
were really helpful.
On to the Basic.mk patch
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Wed, 17 May 2023 18:04:55 -0400
>
> To remind: the purpose of these is to provide a makefile-based way to
> _develop_ GNU Make itself, on platforms where we can't run ./configure
> to get an automake-generated makefile.
>
> If you need to build G
s you can probably tell).I guess that makes the task of
telling whether 'windres' is on the Windows path easier then, because
GNU Make extensions can be used in mk/Windows32.mk to do it.
I'll try and get something working and update the Basic.mk patch with
windres being optional, l
On Wed, 2023-05-17 at 22:55 +0100, Costas Argyris wrote:
> From a quick search there appear to be many ways
> to do this, but some of them are GNU Make-specific,
> and I believe these Makefiles (Basic.mk and those
> included by it) have to work with any Make, not just
> GNU Make.
No; those makefil
; or 'windres --version'.
But I'm not sure how this is best done from within a
Makefile that has to be processed on Windows by
any Make program.
On Wed, 17 May 2023 at 19:34, Costas Argyris
wrote:
> Here is the patch with the Basic.mk.template and mk/Windows32.mk
> changes.I
Here is the patch with the Basic.mk.template and mk/Windows32.mk
changes.I tried to keep most of the changes in the Windows-specific
file, but something had to happen in the general one as well, as far as
I could tell.
I deliberately sent only the changes relevant to the Basic.mk approach
On Wed, 2023-05-17 at 12:47 +0100, Costas Argyris wrote:
> However, when trying to prepare the new patch I realized that
> Basic.mk is an untracked file which is listed in .gitignore, so how
> would you like me to show you these latest changes?
The file to be changed is Basic.mk.template
working
fine: I got UTF-8-working executables in WinRel\gnumake.exe
and GccRel\gnumake.exe for the two options of TOOLCHAIN
respectively.Note that there is no "tcc" option here, in contrast
to the build_w32.bat file approach.
However, when trying to prepare the new patch I realized tha
udio as the compiler, and it expects
> the invoking shell has set up MSVC using vcvarsall or whatever. If you
> set TOOLCHAIN=gcc on the make command line it should use GCC. I admit
> I haven't tried this one recently.
>
> > So, can this feature proceed without changes in Basic.mk?
>
> It's fine with me if you want to submit a patch that doesn't provide
> these updates. I can add them myself, or not.
>
1 - 100 of 1229 matches
Mail list logo
