Aha!
Apparently the reason SF has been eating my patches is that they are
being sent with mime type "text/x-patch." By default, SF strips
attachments that aren't of types "multipart/mixed"
"multipart/alternative" or "text/plain". This can be configured by
someone who knows the mingw-w64-pub
Sorry for the spam, but if this list is how patches are expected to be
sent, I've got to get this working. I'm using gmail's web interface
instead of TB this time. I'm also only sending 1 patch. Fingers crossed...
ext2.patch - Fix macro pasting error and duplicate symbol names.
dw
By request, I am re-sending 4 recent patches. These fix a number of
issues (see below). I am hopeful that by using a different email
account, SF won't EAT my attachments this time.grumble>
Note that I am NOT including the recent warn1.patch (which fixes a whole
bunch of other things), since
I see SF ate my attachment again. As a reminder, warn1.patch is
available at http://www.limegreensocks.com/mingw-w64/Home.html.
Other comments inline.
dw
On 8/8/2016 6:07 AM, Martin Storsjö wrote:
> On Mon, 8 Aug 2016, dw wrote:
>
>> Q3: ARM is giving a bunch of warnings in the form: "dlltool.
Hi guys,
I'm compiling skia with MinGW-w64 GCC, and after the stuff in my previous
mail and some other small things, I came across this:
In file included from C:/Development/skia/src/xps/SkDocument_XPS.cpp:12:0:
C:/Development/skia/src/xps/SkXPSDevice.h:187:15: error: 'XPS_SIZE' does
not name a t
LargeAddressAware
(https://msdn.microsoft.com/en-us/library/wz223b1z.aspx) "tells the
linker that the application can handle addresses larger than 2
gigabytes." For 64bit applications, that's kind of a given.
Are you having some specific issue?
dw
On 8/3/2016 12:05 AM, Dattathreya Hr wrote:
Hi guys,
it would be nice to keep up to date with new APIs that gain real world use,
like this little patch:
https://github.com/Alexpux/mingw-w64/pull/1/commits/6c0efe37b32510f72020e38726c7a84690a926fd
Which is now needed for Qt 5.7 (and skia).
I would also like to point out attached patch that
Am 08.08.2016 um 15:24 schrieb Martin Storsjö:
> ---
> The value 30 is a blind guesstimate of what's sensible; with that, I
> get log() returning values close to the real values (differing only in
> the third digit or so).
>
> I'm not sure exactly how the original logic for the number of rounds
>
Am 08.08.2016 um 15:24 schrieb Martin Storsjö:
> Previously the value wasn't used, and the function was missing
> a return statement.
> ---
> mingw-w64-headers/crt/math.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mingw-w64-headers/crt/math.h b/mingw-w64-headers/crt/
Am 08.08.2016 um 15:24 schrieb Martin Storsjö:
> When building in thumb mode, the conditional instructions are supposed
> to have 'it' instructions preceding them (unless the assembler is
> set to automatically inject such).
>
> This fixes building with clang/llvm 3.9, while the build passed
> wit
On Mon, 8 Aug 2016, Martin Storsjö wrote:
---
The value 30 is a blind guesstimate of what's sensible; with that, I
get log() returning values close to the real values (differing only in
the third digit or so).
I'm not sure exactly how the original logic for the number of rounds
is supposed to w
This fixes printf of floats/doubles with -D__USE_MINGW_ANSI_STDIO=1,
on arm.
---
mingw-w64-crt/stdio/mingw_pformat.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-crt/stdio/mingw_pformat.c
b/mingw-w64-crt/stdio/mingw_pformat.c
index d193519..d
On Mon, 8 Aug 2016, dw wrote:
> Q3: ARM is giving a bunch of warnings in the form: "dlltool.exe: Syntax error
> in def file .../mingw-w64-crt/libarm32/powerwmiprovider.def:62." I have
> looked at the def file, but I don't understand what I am seeing. How do I
> diagnose/repair this?
FWIW, I d
---
The value 30 is a blind guesstimate of what's sensible; with that, I
get log() returning values close to the real values (differing only in
the third digit or so).
I'm not sure exactly how the original logic for the number of rounds
is supposed to work; with any value over 16, it will currentl
Previously the value wasn't used, and the function was missing
a return statement.
---
mingw-w64-headers/crt/math.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-headers/crt/math.h b/mingw-w64-headers/crt/math.h
index 4cbb4d0..b06ca79 100644
--- a/mingw-w64-headers/
When building in thumb mode, the conditional instructions are supposed
to have 'it' instructions preceding them (unless the assembler is
set to automatically inject such).
This fixes building with clang/llvm 3.9, while the build passed
with clang/llvm 3.8 (unsure whether it actually injected such
This fixes duplicate symbols if a calling app links in both e.g.
sqrt and sqrtf.
---
AFAIK, the .def is only there for debugging info - removing the
.global doesn't seem to be enough to avoid the linker failures
at least, but perhaps it can be made debug info for a static symbol
in some other way?
while trying to compile something, I find that MinGW-w64 cannot find
CryptDlg.h. There is a version of this file in Wine; how hard is it to
pull in to MinGW-w64?
--
___
Mingw-w64
Hi all,
Does this new version supports large-adress-aware for 64 bit applications.
--
Regards,
Dattathreya
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforg
Whenever I build mingw-w64, I always get page after page of warning
errors. All that noise makes it hard to find problems my changes have
introduced. Rather than complain and hope someone else would fix it, I
have made the changes myself (see attached patch or 'warn1.patch' on
http://www.Lime
20 matches
Mail list logo
