date:20160824

[Mingw-w64-public] [PATCH] Fix prototype for _difftime32 & _difftime64

2016-08-24 Thread David Wohlferd


Use correct prototype for _difftime32 & _difftime64.

Note that time.h already uses the correct prototype.

Question: Could the intent here have been to treat the (normally) signed 
__time32_t as unsigned in an attempt to squeeze more life out of it (the 
'2038' problem)?  If so, 'tricking' the compiler by having mismatched 
headers seems the wrong way to achieve this. Not to mention that this 
approach has other problems 
(https://en.wikipedia.org/wiki/Year_2038_problem#Solutions).


dw

diff --git a/mingw-w64-crt/misc/difftime32.c b/mingw-w64-crt/misc/difftime32.c
index 9eb3ecf..b893944 100644
--- a/mingw-w64-crt/misc/difftime32.c
+++ b/mingw-w64-crt/misc/difftime32.c
@@ -1,8 +1,8 @@
-double _difftime32(unsigned int _Time1,unsigned int _Time2);
+#include 
 
-double _difftime32(unsigned int _Time1,unsigned int _Time2)
+double __cdecl _difftime32(__time32_t _Time1,__time32_t _Time2)
 {
-  unsigned int r = _Time1 - _Time2;
+  __time32_t r = _Time1 - _Time2;
   if (r > _Time1)
 return -((double) (_Time2 - _Time1));
   return (double) r;
diff --git a/mingw-w64-crt/misc/difftime64.c b/mingw-w64-crt/misc/difftime64.c
index d50006b..54f9a12 100644
--- a/mingw-w64-crt/misc/difftime64.c
+++ b/mingw-w64-crt/misc/difftime64.c
@@ -1,8 +1,8 @@
-double _difftime64(unsigned long long _Time1,unsigned long long _Time2);
+#include 
 
-double _difftime64(unsigned long long _Time1,unsigned long long _Time2)
+double __cdecl _difftime64(__time64_t _Time1,__time64_t _Time2)
 {
-  unsigned long long r = _Time1 - _Time2;
+  __time64_t r = _Time1 - _Time2;
   if (r > _Time1)
 return -((double) (_Time2 - _Time1));
   return (double) r;
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] DirectWrite additions

2016-08-24 Thread Jacek Caban

Hi Ruben,

I'm sorry I didn't look at this earlier.

I committed winerror.h (it seems that you included the same defines in
two different places in those patches, so please retest with committed
version) and wincodec.idl parts.

However, dwrite_2.h needs some more work. We try to provide dwrite APIs
for plain C, which makes things a bit more painful than that. You need
to add THIS (for functions with no arguments) or THIS_ macros in the
beginning of declaration of each functions. Also to preserve proper vtbl
layout, declaration of parent interface needs to be copied inside
__cplusplus guard. See other declarations for an example. Also we try to
avoid using things like _In_, _Out_ macros in our headers.

Thanks,
Jacek

On 24.08.2016 18:25, Ruben Van Boxem wrote:
> I would like to reiterate my request to include the following the changes
> in MinGW-w64. I have no commit rights, and Kai half-OKed them, so input
> from someone in the team that can commit them directly would be greatly
> appreciated!
>
> I'll attach both patches (which are required to build Skia with MinGW-w64)
> to this email for convenience. Note there were duplicate GUID's in the
> previous patch, those were removed here.
>
> Please OK and apply so I can stop keeing my custom builds of MinGW-w64
> around, thanks :)
>
> Cheers!
>
> Ruben
>
> 2016-08-09 19:44 GMT+02:00 Ruben Van Boxem :
>
>> Hi Kai (and Jacek),
>>
>> Thanks for taking a look.
>>
>> Note there are two patches: one I linked to in the body of my email, the
>> other was attached. Both would need to be applied by someone (I don't have
>> commit rights).
>>
>> Cheers,
>>
>> Ruben
>>
>> 2016-08-09 10:58 GMT+02:00 Kai Tietz :
>>
>>> Hi Ruben,
>>>
>>> patch looks fine to me.  As long as there are no objections (Jacek  do
>>> you?), go ahead and apply.
>>>
>>> Thanks,
>>> Kai
>>>
>>> 2016-08-08 20:57 GMT+02:00 Ruben Van Boxem :
 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/6c0efe37
>>> b32510f72020e38726c7a84690a926fd
 Which is now needed for Qt 5.7 (and skia).

 I would also like to point out attached patch that adds various GUIDs
 missing I ran into when compiling skia.

 Cheers,

 Ruben

 
>>> --
 What NetFlow Analyzer can do for you? Monitors network bandwidth and
>>> traffic
 patterns at an interface-level. Reveals which users, apps, and
>>> protocols are
 consuming the most bandwidth. Provides multi-vendor support for NetFlow,
 J-Flow, sFlow and other flows. Make informed decisions using capacity
 planning reports. http://sdm.link/zohodev2dev
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

>>> 
>>> --
>>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
>>> traffic
>>> patterns at an interface-level. Reveals which users, apps, and protocols
>>> are
>>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>>> planning reports. http://sdm.link/zohodev2dev
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>
>>
>>
>>
>> --
>>
>>
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] DirectWrite additions

2016-08-24 Thread Ruben Van Boxem

I would like to reiterate my request to include the following the changes
in MinGW-w64. I have no commit rights, and Kai half-OKed them, so input
from someone in the team that can commit them directly would be greatly
appreciated!

I'll attach both patches (which are required to build Skia with MinGW-w64)
to this email for convenience. Note there were duplicate GUID's in the
previous patch, those were removed here.

Please OK and apply so I can stop keeing my custom builds of MinGW-w64
around, thanks :)

Cheers!

Ruben

2016-08-09 19:44 GMT+02:00 Ruben Van Boxem :

> Hi Kai (and Jacek),
>
> Thanks for taking a look.
>
> Note there are two patches: one I linked to in the body of my email, the
> other was attached. Both would need to be applied by someone (I don't have
> commit rights).
>
> Cheers,
>
> Ruben
>
> 2016-08-09 10:58 GMT+02:00 Kai Tietz :
>
>> Hi Ruben,
>>
>> patch looks fine to me.  As long as there are no objections (Jacek  do
>> you?), go ahead and apply.
>>
>> Thanks,
>> Kai
>>
>> 2016-08-08 20:57 GMT+02:00 Ruben Van Boxem :
>> > 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/6c0efe37
>> b32510f72020e38726c7a84690a926fd
>> >
>> > Which is now needed for Qt 5.7 (and skia).
>> >
>> > I would also like to point out attached patch that adds various GUIDs
>> > missing I ran into when compiling skia.
>> >
>> > Cheers,
>> >
>> > Ruben
>> >
>> > 
>> --
>> > What NetFlow Analyzer can do for you? Monitors network bandwidth and
>> traffic
>> > patterns at an interface-level. Reveals which users, apps, and
>> protocols are
>> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> > J-Flow, sFlow and other flows. Make informed decisions using capacity
>> > planning reports. http://sdm.link/zohodev2dev
>> > ___
>> > Mingw-w64-public mailing list
>> > Mingw-w64-public@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>> >
>>
>> 
>> --
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
>> traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols
>> are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>> planning reports. http://sdm.link/zohodev2dev
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
>
diff --git a/mingw-w64-headers/include/wincodec.h 
b/mingw-w64-headers/include/wincodec.h
index a863a6c..f853407 100644
--- a/mingw-w64-headers/include/wincodec.h
+++ b/mingw-w64-headers/include/wincodec.h
@@ -319,6 +319,30 @@ DEFINE_GUID(GUID_WICPixelFormat48bppRGB, 
0x6fddc324,0x4e03,0x4bfe,0xb1,0x85,0x3d
 DEFINE_GUID(GUID_WICPixelFormat64bppRGBA, 
0x6fddc324,0x4e03,0x4bfe,0xb1,0x85,0x3d,0x77,0x76,0x8d,0xc9,0x16);
 DEFINE_GUID(GUID_WICPixelFormat64bppPRGBA, 
0x6fddc324,0x4e03,0x4bfe,0xb1,0x85,0x3d,0x77,0x76,0x8d,0xc9,0x17);
 DEFINE_GUID(GUID_WICPixelFormat32bppCMYK, 
0x6fddc324,0x4e03,0x4fbe,0xb1,0x85,0x3d,0x77,0x76,0x8d,0xc9,0x1c);
+
+DEFINE_GUID(GUID_WICPixelFormat32bppBGR101010, 0x6fddc324, 0x4e03, 0x4bfe, 
0xb1, 0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x14);
+DEFINE_GUID(GUID_WICPixelFormat16bppGrayFixedPoint, 0x6fddc324, 0x4e03, 
0x4bfe, 0xb1, 0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x13);
+DEFINE_GUID(GUID_WICPixelFormat16bppGrayHalf, 0x6fddc324, 0x4e03, 0x4bfe, 
0xb1, 0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x3e);
+DEFINE_GUID(GUID_WICPixelFormat32bppGrayFloat,  0x6fddc324, 0x4e03, 0x4bfe, 
0xb1, 0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x11);
+DEFINE_GUID(GUID_WICPixelFormat32bppGrayFixedPoint, 0x6fddc324, 0x4e03, 
0x4bfe, 0xb1, 0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x3f);
+DEFINE_GUID(GUID_WICPixelFormat32bppRGBE, 0x6fddc324, 0x4e03, 0x4bfe, 0xb1, 
0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x3d);
+DEFINE_GUID(GUID_WICPixelFormat48bppBGR, 0xe605a384, 0xb468, 0x46ce, 0xbb, 
0x2e, 0x36, 0xf1, 0x80, 0xe6, 0x43, 0x13);
+DEFINE_GUID(GUID_WICPixelFormat48bppRGBFixedPoint, 0x6fddc324, 0x4e03, 0x4bfe, 
0xb1, 0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x12);
+DEFINE_GUID(GUID_WICPixelFormat48bppBGRFixedPoint, 0x49ca140e, 0xcab6, 0x493b, 
0x9d, 0xdf, 0x60, 0x18, 0x7c, 0x37, 0x53, 0x2a);
+DEFINE_GUID(GUID_WICPixelFormat48bppRGBHalf, 0x6fddc324, 0x4e03, 0x4bfe, 0xb1, 
0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x3b);
+DEFINE_GUID(GUID_WICPixelFormat64bppRGBFixedPoint, 0x6fddc324, 0x4e03, 0x4bfe, 
0xb1, 0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x40);
+DEFINE_GUID(GUID_WICPixelFormat64bppRGBHalf, 0x6fddc324,

[Mingw-w64-public] Clang++ bug for typeinfo generation targeted at x86_64 (working for i686)

2016-08-24 Thread Eric PAIRE

Dear all,

Just to let you know that I have found a bug in the last officially released 
clang package version 3.8.0-3 targeted at x86_64, that does not exist for i686 
target. I directly reported its description in LLVM Bugzilla database (see 
https://llvm.org/bugs/show_bug.cgi?id=29116) to avoid bug report duplication...

I do not think it is hard to fix for someone knowing the LLVM x86_64 back-end 
(not my case).

Regards,
Eric

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] undefined references to _set_abort_behavior and ??_7type_info@@6B@

2016-08-24 Thread Josealf.rm

Mario,

I'm glad you made a lot of progress.
Like the old philosophers of yore said:
- Choose your battles carefully; some battles aren't worth fighting for.
- Choose your weapons carefully. Some weapons will work against you, not the 
enemy.
8-)

Regards,
Jose

> El 24/08/2016, a las 2:20 a.m., Mario Emmenlauer  
> escribió:
> 
> 
> Dear Jose,
> 
> thanks, you are awesome! I was so hooked on a specific tutorial for
> building MyQL-python, that I did not try anything else. With your
> pointers I changed linking mysqlclient with mysql, and it links
> without any trouble! No need for all the __chkstk and whatnot! So
> for MinGW that seems highly prefered. I haven't tested the package
> yet, keep fingers crossed :-) :-)
> 
> Thanks again and all the best,
> 
>Mario
> 
> 
> 
> 
>> On 23.08.2016 16:10, Jose Alf. wrote:
>> Mario,
>> Sorry. I don't know how to solve that. As I understand that symbol is const 
>> type_info::vftable, related to virtual function table/rtti - run time type 
>> information, and even if you can link it, I doubt your binary will work. I 
>> think you should try to get a libmysql compiled with mingw or compile one 
>> yourself.
>> You may get help form this:
>> https://sites.google.com/site/bauyt008/code--blocks-tips--tricks-and-tutorials/c-mysql
>> http://forums.mysql.com/read.php?167,295483,297733#msg-297733
>> Regards,Jose
>> 
>> 
>> 
>>  From: Mario Emmenlauer 
>> To: mingw-w64-public@lists.sourceforge.net 
>> Sent: Tuesday, August 23, 2016 8:09 AM
>> Subject: Re: [Mingw-w64-public] undefined references to _set_abort_behavior 
>> and ??_7type_info@@6B@
>> 
>> 
>> Dear Josealf,
>> 
>> awesome! The MSVCRT == 9 did solve the issue with _set_abort_behavior!
>> Now I'm only lacking ??_7type_info@@6B@, which is undefined in
>> mysqlclient.lib. Do you know how I could get this?
>> 
>> Thanks and all the best,
>> 
>>Mario
>> 
>> 
>> 
>>> On 23.08.2016 13:22, Josealf.rm wrote:
>>> Link against MSVCRT >= 9 ?
>>> 
>>> Something like :
>>> 
>>> gcc -o out.exe yourmain.c -D__MSVCRT_VERSION__=0x900 -lmsvcr90
>>> 
>>> 
>>> 
 El 23/08/2016, a las 4:24 a.m., Mario Emmenlauer  
 escribió:
 
 
 Dear all,
 
 I've managed to find several more symbols, but I'm still left without
 being able to link MySQL. Its quite a standard library, would be great
 if I could get it to link. The remaining missing symbols are:
 
_set_abort_behavior
??_7type_info@@6B@
 
 Can you please help me get them from somewhere? Thanks a lot!
 
Mario
 
 
 
 
 
> On 22.08.2016 10:43, Mario Emmenlauer wrote:
> 
> Thanks Kai! I did what you suggest, and now most of the undefined 
> references
> are gone! To help others with the same issue, here is what I did:
> I needed to go back all the way to Microsoft Visual Studio 2005, since the
> newer versions did not have both files. I could then find them easily in 
> the
> Visual Studio installation folder, and link them with gcc without 
> problems.
> 
> I have a few remaining undefined references, do these mean anything to 
> someone?
> Google really did not return anything useful :-(
> 
>  undefined reference to `_set_abort_behavior'
> 
>  undefined reference to `__chkstk'
> 
>  undefined reference to `??_7type_info@@6B@'
> 
> 
> All the best,
> 
>Mario
> 
> 
>>> On 22.08.2016 09:51, Kai Tietz wrote:
>>> 2016-08-22 8:58 GMT+02:00 Mario Emmenlauer :
>>> 
>>> Dear All,
>>> 
>>> I'm trying to link against MySQL, but it fails with undefined references
>>> to __GSHandlerCheck and __security_check_cookie. I searched and this has
>>> been asked before (several years back), but back then there was no 
>>> solution
>>> found. AFAIK these two where not available in MinGW's runtime, and in 
>>> the
>>> end the user was switching compilers. Is there a MinGW-based solution
>>> possible now? I'd very much prefer that. I found people recommending to
>>> link against a "bufferoverflowu.lib" and some 'gshandler.obj'. Do you 
>>> know
>>> if I can take those from Visual Studio and link against them in MinGW?
>>> Would that work? Or other ideas?
>>> 
>>> Thanks for any help,
>>> 
>>>Mario Emmenlauer
>> 
>> We don't support those.  You can link against MS libraries/objects for
>> these symbols.  Or you could work on a patch, which provides support
>> for those.
>> 
>> Regards,
>> Kai
> 
> 
> 
> Viele Gruesse,
> 
>Mario Emmenlauer
> 
> 
> --
> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> D-81669 München  http://www.biodataanalysis.de/
> 
>

[Mingw-w64-public] [PATCH] Fix prototype for _difftime32 & _difftime64

Re: [Mingw-w64-public] DirectWrite additions

Re: [Mingw-w64-public] DirectWrite additions

[Mingw-w64-public] Clang++ bug for typeinfo generation targeted at x86_64 (working for i686)

Re: [Mingw-w64-public] undefined references to _set_abort_behavior and ??_7type_info@@6B@

5 matches

Site Navigation

Mail list logo

Footer information