cross compilation

[Eric Pouech]

i'm currently fixing a couple of bugs introduced when linking winedbg 
with msvcrt (cough cough)

a couple of items strike me (for cross compiling only):

- why is cross compilation done with -Wno-format flag? what's the 
rationale behind it (it hides a couple of errors ;-)

- when linked with msvcrt, are we fine with using MS extensions (%Id 
%I32d %I64d and friends?) (read uppercase i)

- could we foresee to use no longer the wine_dbgstr_longlong helper ?

A+

[Alexandre Julliard]

Eric Pouech  writes:
> i'm currently fixing a couple of bugs introduced when linking winedbg with msvcrt (cough cough)
>
> a couple of items strike me (for cross compiling only):
> - why is cross compilation done with -Wno-format flag? what's the rationale behind it (it hides a couple of errors ;-)

It's disabled on 64-bit because most places are still using the Unix
formats. This will have to be fixed eventually, and -Wno-format will
then be applied to non-Mingw builds instead.
> - when linked with msvcrt, are we fine with using MS extensions (%Id %I32d %I64d and friends?) (read uppercase i)

Yes.
> - could we foresee to use no longer the wine_dbgstr_longlong helper ?

Hopefully at some point.

[Eric Pouech]

Le 12/10/2021 à 18:17, Alexandre Julliard a écrit :
> Eric Pouech  writes:
> > i'm currently fixing a couple of bugs introduced when linking winedbg with msvcrt (cough cough)
> >
> > a couple of items strike me (for cross compiling only):
> > - why is cross compilation done with -Wno-format flag? what's the rationale behind it (it hides a couple of errors ;-)
>
> It's disabled on 64-bit because most places are still using the Unix
> formats. This will have to be fixed eventually, and -Wno-format will
> then be applied to non-Mingw builds instead.

you mean replacing all the the %l[udx] (lower case l) by %I[udx] (upper 
case i) ?

BTW, include/msvcrt/stdio.h doesn't use the __attribute__((format)) 
thingie for printf nor scanf families

(I was surprised that there wasn't warning about the printf & sscanf 
usage I've just sent a patch for...)

I'll dig into it

A+

[Alexandre Julliard]

Eric Pouech  writes:
> Le 12/10/2021 à 18:17, Alexandre Julliard a écrit :
> > Eric Pouech  writes:
> > > i'm currently fixing a couple of bugs introduced when linking winedbg with msvcrt (cough cough)
> > >
> > > a couple of items strike me (for cross compiling only):
> > > - why is cross compilation done with -Wno-format flag? what's the rationale behind it (it hides a couple of errors ;-)
> >
> > It's disabled on 64-bit because most places are still using the Unix
> > formats. This will have to be fixed eventually, and -Wno-format will
> > then be applied to non-Mingw builds instead.
>
> you mean replacing all the the %l[udx] (lower case l) by %I[udx]
> (upper case i) ?

Yes, but there are other issues, like the fact that we use long instead
of int on 32-bit. It will take some thought to find a way to do the
transition without having to fix a million warnings at once.

[Eric Pouech]

Le 12/10/2021 à 20:37, Alexandre Julliard a écrit :
> Eric Pouech  writes:
> > Le 12/10/2021 à 18:17, Alexandre Julliard a écrit :
> > > Eric Pouech  writes:
> > > > i'm currently fixing a couple of bugs introduced when linking winedbg with msvcrt (cough cough)
> > > >
> > > > a couple of items strike me (for cross compiling only):
> > > > - why is cross compilation done with -Wno-format flag? what's the rationale behind it (it hides a couple of errors ;-)
> > >
> > > It's disabled on 64-bit because most places are still using the Unix
> > > formats. This will have to be fixed eventually, and -Wno-format will
> > > then be applied to non-Mingw builds instead.
> >
> > you mean replacing all the the %l[udx] (lower case l) by %I[udx]
> > (upper case i) ?
>
> Yes, but there are other issues, like the fact that we use long instead
> of int on 32-bit. It will take some thought to find a way to do the
> transition without having to fix a million warnings at once.

for the record, out of the 1300 Mafile.in in the wine tree, only ~180(*) 
generate warnings when removing the -Wno-format

this really calls for removing the -Wno-format and add the -Wno-format 
on a per directory basis

would such a thing be acceptable?

i tried currently with hijacking EXTRAINCL (by appending the -Wno-format 
in Makefile.in) and tweaking makedep to support it

in the tweaking, I made the flag inheritable across the PARENT 
relationship (hence the (*) count above is an underestimation as all 
subdirs with PARENT are not included in the count)

but that's not 100% satisfactory, isn't it?

I was rather tempted to add the attributes format in .h files only when 
WINE_NO_ATTRIBUTE_FORMAT isn't defined, and append for subdirs that 
don't support it that define to the EXTRADEF

comments welcomed

A+

Problem rebasing/ cloning

[Ted Lyngmo]

I suddenly can't rebase:

$ git pull -v -r origin master
Looking up source.winehq.org ... done.
Connecting to source.winehq.org (port 9418) ... fatal: unable to connect 
to source.winehq.org:
source.winehq.org[0: 4.4.81.124]: errno=Connection timed out

I also tried cloning a new copy and got the same result.

$ git clone -v git://source.winehq.org/git/wine.git
Cloning into 'wine'...
Looking up source.winehq.org ... done.
Connecting to source.winehq.org (port 9418) ... fatal: unable to connect 
to source.winehq.org:
source.winehq.org[0: 4.4.81.124]: errno=Connection timed out

Does anyone else have this problem is it this on my side only? I didn't 
have this problem 5 days ago.

Br,
Ted

Problem rebasing/ cloning

[Eric Pouech]

Le 17/10/2021 à 13:17, Ted Lyngmo a écrit :
> I suddenly can't rebase:
>
> $ git pull -v -r origin master
> Looking up source.winehq.org ... done.
> Connecting to source.winehq.org (port 9418) ... fatal: unable to 
> connect to source.winehq.org:
> source.winehq.org[0: 4.4.81.124]: errno=Connection timed out
>
> I also tried cloning a new copy and got the same result.
>
> $ git clone -v git://source.winehq.org/git/wine.git
> Cloning into 'wine'...
> Looking up source.winehq.org ... done.
> Connecting to source.winehq.org (port 9418) ... fatal: unable to 
> connect to source.winehq.org:
> source.winehq.org[0: 4.4.81.124]: errno=Connection timed out
>
> Does anyone else have this problem is it this on my side only? I 
> didn't have this problem 5 days ago.
>
> Br,
> Ted

hi Ted,

works fine here, looks like a connectivity issue from your premises up 
to winehq.org

(got same IP address for winehq.org as you)

can you ping winehq.org?

A+

Problem rebasing/ cloning

[David Kahurani]

Works for me, but could be the issue got fixed, it has been an hour since
your email.

On Sun, Oct 17, 2021 at 2:17 PM Ted Lyngmo  wrote:
> I suddenly can't rebase:
>
> $ git pull -v -r origin master
> Looking up source.winehq.org ... done.
> Connecting to source.winehq.org (port 9418) ... fatal: unable to connect
> to source.winehq.org:
> source.winehq.org[0: 4.4.81.124]: errno=Connection timed out
>
> I also tried cloning a new copy and got the same result.
>
> $ git clone -v git://source.winehq.org/git/wine.git
> Cloning into 'wine'...
> Looking up source.winehq.org ... done.
> Connecting to source.winehq.org (port 9418) ... fatal: unable to connect
> to source.winehq.org:
> source.winehq.org[0: 4.4.81.124]: errno=Connection timed out
>
> Does anyone else have this problem is it this on my side only? I didn't
> have this problem 5 days ago.
>
> Br,
> Ted

Problem rebasing/ cloning

[Ted Lyngmo]

David Kahurani wrote:
> Works for me, but could be the issue got fixed, it has been an hour since your email.

Thanks! I just found the cause. For some reason "winehq.org" couldn't be 
resolved when one of the emails from the list was received so my 
aggressive server decided to add a DROP rule to iptables for 4.4.81.124. :-)

So, my bad! / Ted