Re: Unable to cross build for Windows

2023-06-08 Thread Eli Zaretskii
> Date: Thu, 8 Jun 2023 20:39:43 +0200
> CC: 
> From: Torbjorn SVENSSON 
> 
> > If you get the error about casting _get_osfhandle to HANDLE only for
> > the 32-bit build, and you don't care about that build, then just
> > ignore it.  But if that error is emitted for the 64-bit build, then
> > there's something strange here, since on 64-bit Windows 'long long'
> > should be compatible with 'void *'.
> 
> The error is emitted in both builds, but let's ignore 32-bit for now.
> Both the errors that I pasted above are emitted using
> x86_64-w64-mingw32 and need to have some kind of fix to have a successful
> build.
> 
> Any idea what could be done except disabling the warning for the cast.

I'd post to the MinGW64 forum and perhaps also to the GCC list.  It
sounds like a bogus warning to me, i.e. a bug.  The question is: is
the bug in GCC itself or in some MinGW64 header files?



Re: Unable to cross build for Windows

2023-06-08 Thread Paul Smith
On Thu, 2023-06-08 at 20:39 +0200, Torbjorn SVENSSON wrote:
> > If you get the error about casting _get_osfhandle to HANDLE only
> > for the 32-bit build, and you don't care about that build, then
> > just ignore it.  But if that error is emitted for the 64-bit build,
> > then there's something strange here, since on 64-bit Windows 'long
> > long' should be compatible with 'void *'.
> 
> The error is emitted in both builds, but let's ignore 32-bit for now.
> Both the errors that I pasted above are emitted using
> x86_64-w64-mingw32 and need to have some kind of fix to have a
> successful build.
> 
> Any idea what could be done except disabling the warning for the
> cast.

I have no comment on how to successfully cross-compile for Windows.

However I will say that as a general policy GNU programs never enable
-Werror for our published packages, because different compilers, and
different versions of compilers, generate different warnings and
there's no way we can know what they will be, when we release the
software.

We enable -Werror for our internal development builds ("maintainer
builds" in GNU Make) and we fix all warnings there.

I personally recommend you do the same (don't enable -Werror, unless
you're creating a developer build of GNU Make).  But if you're
committed to finding a way to fix this warning that's fine too!



Re: Unable to cross build for Windows

2023-06-08 Thread Torbjorn SVENSSON




On 2023-06-08 17:05, Eli Zaretskii wrote:

Date: Thu, 8 Jun 2023 16:19:04 +0200
CC: 
From: Torbjorn SVENSSON 

On 2023-06-08 16:14, Eli Zaretskii wrote:

Date: Thu, 8 Jun 2023 14:44:35 +0200
From: Torbjorn SVENSSON 

/build/gnu-make_4.4.1-45-g07fcee35/src/function.c: In function 
'windows32_openpipe':
/build/gnu-make_4.4.1-45-g07fcee35/src/function.c:1676:12: error: cast from 
function call of type 'intptr_t {aka long long int}' to non-matching type 'void 
*' [-Werror=bad-function-cast]
  tmpErr = (HANDLE)_get_osfhandle (errfd);
   ^


/build/gnu-make_4.4.1-45-g07fcee35/src/job.c: In function 'create_batch_file':
/build/gnu-make_4.4.1-45-g07fcee35/src/job.c:365:3: error: format not a string 
literal and no format arguments [-Werror=format-security]
  O (fatal, NILF, error_string);
  ^


On the MSDN page for _get_osfhandle, they recommend to case the return value
to HANDLE, but GCC apparently thinks this is not allowed.
Any idea on how to get around this issue?


For the O()-macro; is it correct to use the macro with a variable?
Maybe it's more appropriate to fall fatal directly with the arguments?


Is this with x86_64 being the target or i686?  I'm guessing the
latter, since for 64-bit Windows 'long long' and 'void *' are of the
same width.  If it's indeed for i686, are you sure the MinGW64 headers
you have support 32-bit builds?  Because AFAIR MinGW64 tossed
supported for old Windows versions, which basically means they don't
support 32-bit Windows.


The idea is to have a 64-bit make application. I just included the i686
log for completeness.


If you get the error about casting _get_osfhandle to HANDLE only for
the 32-bit build, and you don't care about that build, then just
ignore it.  But if that error is emitted for the 64-bit build, then
there's something strange here, since on 64-bit Windows 'long long'
should be compatible with 'void *'.


The error is emitted in both builds, but let's ignore 32-bit for now.
Both the errors that I pasted above are emitted using
x86_64-w64-mingw32 and need to have some kind of fix to have a successful
build.

Any idea what could be done except disabling the warning for the cast.



Re: Unable to cross build for Windows

2023-06-08 Thread Torbjorn SVENSSON




On 2023-06-08 16:14, Eli Zaretskii wrote:

Date: Thu, 8 Jun 2023 14:44:35 +0200
From: Torbjorn SVENSSON 

/build/gnu-make_4.4.1-45-g07fcee35/src/function.c: In function 
'windows32_openpipe':
/build/gnu-make_4.4.1-45-g07fcee35/src/function.c:1676:12: error: cast from 
function call of type 'intptr_t {aka long long int}' to non-matching type 'void 
*' [-Werror=bad-function-cast]
 tmpErr = (HANDLE)_get_osfhandle (errfd);
  ^


/build/gnu-make_4.4.1-45-g07fcee35/src/job.c: In function 'create_batch_file':
/build/gnu-make_4.4.1-45-g07fcee35/src/job.c:365:3: error: format not a string 
literal and no format arguments [-Werror=format-security]
 O (fatal, NILF, error_string);
 ^


On the MSDN page for _get_osfhandle, they recommend to case the return value
to HANDLE, but GCC apparently thinks this is not allowed.
Any idea on how to get around this issue?


For the O()-macro; is it correct to use the macro with a variable?
Maybe it's more appropriate to fall fatal directly with the arguments?


Is this with x86_64 being the target or i686?  I'm guessing the
latter, since for 64-bit Windows 'long long' and 'void *' are of the
same width.  If it's indeed for i686, are you sure the MinGW64 headers
you have support 32-bit builds?  Because AFAIR MinGW64 tossed
supported for old Windows versions, which basically means they don't
support 32-bit Windows.


The idea is to have a 64-bit make application. I just included the i686
log for completeness.

If I can get a build going for x86_64-w64-mingw32, I would be okay with
ignoring whatever problems that are unique to the i686-w64-mingw32 target.



Re: Unable to cross build for Windows

2023-06-08 Thread Eli Zaretskii
> Date: Thu, 8 Jun 2023 14:44:35 +0200
> From: Torbjorn SVENSSON 
> 
> /build/gnu-make_4.4.1-45-g07fcee35/src/function.c: In function 
> 'windows32_openpipe':
> /build/gnu-make_4.4.1-45-g07fcee35/src/function.c:1676:12: error: cast from 
> function call of type 'intptr_t {aka long long int}' to non-matching type 
> 'void *' [-Werror=bad-function-cast]
> tmpErr = (HANDLE)_get_osfhandle (errfd);
>  ^
> 
> 
> /build/gnu-make_4.4.1-45-g07fcee35/src/job.c: In function 'create_batch_file':
> /build/gnu-make_4.4.1-45-g07fcee35/src/job.c:365:3: error: format not a 
> string literal and no format arguments [-Werror=format-security]
> O (fatal, NILF, error_string);
> ^
> 
> 
> On the MSDN page for _get_osfhandle, they recommend to case the return value
> to HANDLE, but GCC apparently thinks this is not allowed.
> Any idea on how to get around this issue?
> 
> 
> For the O()-macro; is it correct to use the macro with a variable?
> Maybe it's more appropriate to fall fatal directly with the arguments?

Is this with x86_64 being the target or i686?  I'm guessing the
latter, since for 64-bit Windows 'long long' and 'void *' are of the
same width.  If it's indeed for i686, are you sure the MinGW64 headers
you have support 32-bit builds?  Because AFAIR MinGW64 tossed
supported for old Windows versions, which basically means they don't
support 32-bit Windows.