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+
Eric Pouech <eric.pouech(a)orange.fr> 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. -- Alexandre Julliard julliard(a)winehq.org
Le 12/10/2021 à 18:17, Alexandre Julliard a écrit :
Eric Pouech <eric.pouech(a)orange.fr> 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+
Eric Pouech <eric.pouech(a)orange.fr> writes:
Le 12/10/2021 à 18:17, Alexandre Julliard a écrit :
Eric Pouech <eric.pouech(a)orange.fr> 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. -- Alexandre Julliard julliard(a)winehq.org
Le 12/10/2021 à 20:37, Alexandre Julliard a écrit :
Eric Pouech<eric.pouech(a)orange.fr> writes:
Le 12/10/2021 à 18:17, Alexandre Julliard a écrit :
Eric Pouech<eric.pouech(a)orange.fr> 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+
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
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+
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 <ted(a)lyncon.se> 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
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
participants (4)
-
Alexandre Julliard -
David Kahurani -
Eric Pouech -
Ted Lyngmo