[Mingw-w64-public] Patches review

2011-11-24 Thread Jacek Caban
Hi, Please review following patches: http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/bd7caa72f45af8883715e39c7b8d3ba1f26e6f99 This is a regular Wine import update. http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/65bb5e26b0e99b917d294e5741b78ff1a6a1ad35 This solves a problem with

Re: [Mingw-w64-public] error: unknown type name 'VIDEO_STREAM_CONFIG_CAPS'

2012-05-23 Thread Jacek Caban
Hi Kai, Thanks for review, committed as r5050. Cheers, Jacek -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-04 Thread Jacek Caban
On 06/03/12 17:45, JonY wrote: Forwarding to mingw-w64 list. Some of the headers modified is generated from WINE widl, so the preprocessor should be changed instead, jacek? Where? I don't see any. There is one change to propkeydef.h, but and I believe incorrect. Generally, this patch makes

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-12 Thread Jacek Caban
On 06/12/12 07:06, Yaakov (Cygwin/X) wrote: On 2012-06-04 04:04, Jacek Caban wrote: Where? I don't see any. There is one change to propkeydef.h, but and I believe incorrect. Generally, this patch makes REFIID and similar typedefs depend on CINTERFACE, which is not present in MSVC. According

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-12 Thread Jacek Caban
On 06/12/12 10:51, Jacek Caban wrote: On 06/12/12 07:06, Yaakov (Cygwin/X) wrote: On 2012-06-04 04:04, Jacek Caban wrote: Where? I don't see any. There is one change to propkeydef.h, but and I believe incorrect. Generally, this patch makes REFIID and similar typedefs depend on CINTERFACE

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-12 Thread Jacek Caban
On 06/12/12 12:53, Earnie Boyd wrote: On Tue, Jun 12, 2012 at 5:11 AM, Jacek Caban wrote: On 06/12/12 10:51, Jacek Caban wrote: On 06/12/12 07:06, Yaakov (Cygwin/X) wrote: On 2012-06-04 04:04, Jacek Caban wrote: Where? I don't see any. There is one change to propkeydef.h, but and I believe

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-15 Thread Jacek Caban
On 06/14/12 11:55, Yaakov (Cygwin/X) wrote: On 2012-06-12 03:51, Jacek Caban wrote: On 06/12/12 07:06, Yaakov (Cygwin/X) wrote: On 2012-06-04 04:04, Jacek Caban wrote: Where? I don't see any. There is one change to propkeydef.h, but and I believe incorrect. Generally, this patch makes REFIID

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-15 Thread Jacek Caban
On 06/15/12 11:42, Yaakov (Cygwin/X) wrote: On 2012-06-15 03:46, Jacek Caban wrote: On 06/14/12 11:55, Yaakov (Cygwin/X) wrote: Both mingw.org and Wine support CINTERFACE wrt the REF*ID defines. Thanks for the report, I've fixed Wine [1]. Not AFAICS. Look at all the places where REF*ID

Re: [Mingw-w64-public] [patch] Cygwin support, part 0

2012-06-26 Thread Jacek Caban
On 06/26/12 15:34, Kai Tietz wrote: Hi Corinna, 2012/6/26 Corinna Vinschen vinsc...@redhat.com: Hi, for a start in supporting Cygwin, I created this patch. It doesn't error out just because _WIN32 is not defined and the new _cygwin.h file (which will probably get a lot more to do later

Re: [Mingw-w64-public] [ANNOUNCEMENT] mingw-w64-headers build behavior changes in trunk (v3)

2012-07-09 Thread Jacek Caban
Hi Jon, On 07/09/12 01:02, JonY wrote: Hello all, mingw-w64-headers will now install headers to $PREFIX/include instead of $PREFIX/$HOST/include, where $PREFIX is whatever passed to configure for --prefix= The $HOST part is no longer there, please take note and check your buildscripts

Re: [Mingw-w64-public] Tapi.h and libtapi32

2012-07-11 Thread Jacek Caban
On 07/11/12 11:14, JonY wrote: On 7/11/2012 14:51, Peter Schaefer wrote: Hi! I'm using the recent rubenvb-gcc-4.7.1 release and tried to compile an application using TAPI, however tapi.h cannot be compiled:

Re: [Mingw-w64-public] [patch] _mingw.h: Introduce the __32LONG macro

2012-07-13 Thread Jacek Caban
On 07/12/12 23:30, Ozkan Sezer wrote: On 7/12/12, Corinna Vinschen vinsc...@redhat.com wrote: Hi, unused so far, but that's the obvious starting point for the entire operation as discussed on IRC. Corinna * _mingw.h.in (__32LONG): Define. Explain what it's good for. Any specific

Re: [Mingw-w64-public] include: fix mingw64 build

2012-07-16 Thread Jacek Caban
On 07/15/12 14:21, Nicolas Le Cam wrote: 2012/7/4 Jacek Caban ja...@codeweavers.com: On 07/03/12 20:10, Jacek Caban wrote: On 06/29/12 03:35, Austin English wrote: On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam niko.le...@gmail.com wrote: 2012/6/29 Austin English austinengl...@gmail.com

Re: [Mingw-w64-public] include: fix mingw64 build

2012-07-16 Thread Jacek Caban
On 07/16/12 11:02, Ozkan Sezer wrote: On Mon, Jul 16, 2012 at 11:33 AM, Jacek Caban ja...@codeweavers.com wrote: On 07/15/12 14:21, Nicolas Le Cam wrote: 2012/7/4 Jacek Caban ja...@codeweavers.com: On 07/03/12 20:10, Jacek Caban wrote: On 06/29/12 03:35, Austin English wrote: On Thu, Jun 28

Re: [Mingw-w64-public] include: fix mingw64 build

2012-07-16 Thread Jacek Caban
On 07/16/12 11:06, JonY wrote: On 7/16/2012 16:33, Jacek Caban wrote: On 07/15/12 14:21, Nicolas Le Cam wrote: 2012/7/4 Jacek Caban: On 07/03/12 20:10, Jacek Caban wrote: On 06/29/12 03:35, Austin English wrote: On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam wrote: 2012/6/29 Austin English

Re: [Mingw-w64-public] include: fix mingw64 build

2012-07-16 Thread Jacek Caban
On 07/16/12 14:26, Ozkan Sezer wrote: On Mon, Jul 16, 2012 at 3:03 PM, JonY jo...@users.sourceforge.net wrote: On 7/16/2012 19:10, JonY wrote: On 7/16/2012 18:46, Ozkan Sezer wrote: On Mon, Jul 16, 2012 at 1:38 PM, JonY wrote: On 7/16/2012 17:19, Jacek Caban wrote: Sorry about that, I treat

Re: [Mingw-w64-public] include: fix mingw64 build

2012-07-17 Thread Jacek Caban
On 07/16/12 15:33, Jacek Caban wrote: On 07/16/12 14:26, Ozkan Sezer wrote: On Mon, Jul 16, 2012 at 3:03 PM, JonY jo...@users.sourceforge.net wrote: On 7/16/2012 19:10, JonY wrote: On 7/16/2012 18:46, Ozkan Sezer wrote: On Mon, Jul 16, 2012 at 1:38 PM, JonY wrote: On 7/16/2012 17:19, Jacek

Re: [Mingw-w64-public] [patch/bulk] ddk: Use __MSABI_LONG where appropriate

2012-07-18 Thread Jacek Caban
Hi Corinna On 07/18/12 14:45, Corinna Vinschen wrote: Hi, the below patch needs a thorough second pair of eyes. I did a quick look, not a real review. It looks mostly OK, except when a constant is a parameter to DEFINE_GUID, it's safe to just skip the long suffix and always pass int. That

Re: [Mingw-w64-public] error when building mingw-w64-crt from trunk

2012-07-24 Thread Jacek Caban
On 07/24/12 16:45, niXman wrote: Hello, Subj. Makefile:26134: *** missing separator. Stop. Yeah the commit: http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/27cfb5c70b2e0566d6dba3e6e190af7e5f03d988 had a typo, I've committed a fix:

Re: [Mingw-w64-public] error when building mingw-w64-crt from trunk

2012-07-24 Thread Jacek Caban
On 07/24/12 17:12, niXman wrote: 2012/7/24 Jacek Caban: had a typo, I've committed a fix: http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/7ce0e293f687202dbe051d5668e5a79fee528560 Hmm... The same error in rev5259: You may need to make sure that Makefile is updated (by invoking configure

Re: [Mingw-w64-public] [patch/bulk] Use __MSABI_LONG throughout

2012-07-27 Thread Jacek Caban
On 07/27/12 16:48, Corinna Vinschen wrote: On Jul 27 15:10, Corinna Vinschen wrote: On Jul 27 14:47, Kai Tietz wrote: Hello Corinna, The patch is ok. My eyes suffer pain ;) I share your pain. Proof-reading this patch is a PITA. Patch applied. Next week I'll start with the __LONG32 stuff.

Re: [Mingw-w64-public] [patch] oleacc.idl: Use ULONG

2012-08-01 Thread Jacek Caban
On 08/01/12 11:49, Corinna Vinschen wrote: Hi, the below patch changes oleacc.idl to use ULONG rather than unsigned long in all calls to the XXX_UserYYY automation functions. MSDN documents the BSTR and VARIANT functions to use ULONG. I couldn't find documentation for the equivalent HMENU

Re: [Mingw-w64-public] [patch] oleacc.idl: Use ULONG

2012-08-01 Thread Jacek Caban
On 08/01/12 12:22, Corinna Vinschen wrote: On Aug 1 11:54, Jacek Caban wrote: On 08/01/12 11:49, Corinna Vinschen wrote: Hi, the below patch changes oleacc.idl to use ULONG rather than unsigned long in all calls to the XXX_UserYYY automation functions. MSDN documents the BSTR and VARIANT

Re: [Mingw-w64-public] [patch/bulk] long-LONG, unsigned long-ULONG in all idl files

2012-08-01 Thread Jacek Caban
On 08/01/12 15:49, Corinna Vinschen wrote: On Aug 1 15:27, Jacek Caban wrote: Hi Corinna, On 08/01/12 14:57, Corinna Vinschen wrote: Hi, per our discussion in the previous thread, here's a patch which replaces all long and unsigned long with LONG and ULONG in .idl files

Re: [Mingw-w64-public] [patch] Fix types for XXX_UserSize, XXX_UserMarshal, XXX_UserUnmarshal, and XXX_UserFree functions

2012-08-02 Thread Jacek Caban
On 08/01/12 22:10, Kai Tietz wrote: Hi Corinnna, patch looks ok to me. See if Jacek have any objections (I wouldn't assume so). Yeah, looks good to me. Jacek -- Live Security Virtual Conference Exclusive live

Re: [Mingw-w64-public] Conflicting declaration of getcwd in io.h

2012-08-17 Thread Jacek Caban
On 08/17/12 11:42, Rainer Emrich wrote: Am 17.08.2012 11:29, schrieb Kai Tietz: Hallo Rainer, well, the issue is that msvcrt's getcwd has as second argument the pointer-length-argument typed as 'int'. You can check this also by seaching on msdn for getcwd. For 32-bit it is just a

Re: [Mingw-w64-public] Conflicting declaration of getcwd in io.h

2012-08-17 Thread Jacek Caban
On 08/17/12 11:33, Rainer Emrich wrote: Am 17.08.2012 09:37, schrieb Rainer Emrich: After the gcc cxx-conversion merge has taken place, I get a conflicting declaration of getcwd in io.h in several places while bootstrapping gcc-4.8.0. In file included from

Re: [Mingw-w64-public] IsEqualGUID

2012-08-24 Thread Jacek Caban
On 08/24/12 18:24, Roger Pack wrote: I don't know if this is a bug, or even the right forum, but this line: IsEqualGUID(FORMAT_WaveFormatEx, FORMAT_WaveFormatEx); The correct form is probably: IsEqualGUID(FORMAT_WaveFormatEx, FORMAT_WaveFormatEx); Your form would be valid in C++, but not in C.

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?

2012-10-25 Thread Jacek Caban
On 10/24/12 21:19, Kai Tietz wrote: So I would like to get your opinion. You might have complete different opinion about planning mingw-w64's release-cycles, so don't hesitate to tell us what you think about this subject. Current release-cycles strategy works fine for me, but now that you

Re: [Mingw-w64-public] Recent commit

2012-10-29 Thread Jacek Caban
He admitted on IRC that he never had 32-bit .def file and didn't compile-test his commit, so I reverted the commit as r5438. Also I've updated Wine-imported headers as r5439. Cheers, Jacek On 10/29/12 09:40, Kai Tietz wrote: JonY, you've added libsapi.a to Makefile, but you missed to add its

Re: [Mingw-w64-public] dlgs.h: rad1, rad2 macros

2012-11-11 Thread Jacek Caban
On 11/11/12 9:46 AM, Václav Šmilauer wrote: Hello, I got recently hit by compilation error due to dlgs.h (included from windows.h) #defining several macros with common names - in my case rad1, rad2 (for radius 1, radius 2). Are those part of Windows API or could they be renamed to something

Re: [Mingw-w64-public] MinGW-w64 trunk ia32intrin C++ problem

2012-12-22 Thread Jacek Caban
On 12/22/12 12:23 PM, Kai Tietz wrote: Please include first the windows.h header, and then do other includes. There is nothing to fix on mingw-w64's side. It might be a gcc-intrinsic header bug, as API should be artificial but still has language-binding. AFAIR there is already a bug-report

Re: [Mingw-w64-public] MinGW-w64 trunk ia32intrin C++ problem

2012-12-22 Thread Jacek Caban
On 12/22/12 1:43 PM, Ruben Van Boxem wrote: 2012/12/22 Jacek Caban ja...@codeweavers.com mailto:ja...@codeweavers.com On 12/22/12 12:23 PM, Kai Tietz wrote: Please include first the windows.h header, and then do other includes. There is nothing to fix on mingw-w64's side

Re: [Mingw-w64-public] MinGW-w64 trunk ia32intrin C++ problem

2012-12-22 Thread Jacek Caban
On 12/22/12 8:41 PM, Ruben Van Boxem wrote: 2012/12/22 Jacek Caban ja...@codeweavers.com mailto:ja...@codeweavers.com On 12/22/12 1:43 PM, Ruben Van Boxem wrote: 2012/12/22 Jacek Caban ja...@codeweavers.com mailto:ja...@codeweavers.com On 12/22/12 12:23 PM, Kai Tietz

Re: [Mingw-w64-public] Patch for widl Makefile rule bug when builddir!=srcdir

2013-01-14 Thread Jacek Caban
Hi Ray, .idl.h: crt/_mingw.h - $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include -I$(srcdir)/direct-x/include -Icrt -I$(srcdir)/crt -h -o $(srcdir)/$@ $ + $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include -I$(srcdir)/direct-x/include -Icrt -I$(srcdir)/crt -h -o $@ $ The current code is indeed a

Re: [Mingw-w64-public] Suggestion for FAQ Re _vswprintf and msvcrt.dll on XP SP1

2013-01-21 Thread Jacek Caban
On 01/21/13 13:39, JonY wrote: On 1/21/2013 09:43, Herb Thompson wrote: Q: Why do some 32-bit MinGW-w64 applications fail with '... _vswprintf could not be located in the dynamic link library msvcrt.dll' on Windows XP SP1? A: For C++, MinGW-w64 implements 'vswprintf (wchar_t *__stream,

Re: [Mingw-w64-public] Patch for widl Makefile rule bug when builddir!=srcdir

2013-02-11 Thread Jacek Caban
: Hi Jacek, Sorry for the long response time. Please find attached a new version of the patch that adds the warning you mentioned. I also named it as .a txt file and removed all auto generated files. Best regards, Ray. On Mon, Jan 14, 2013 at 12:40 PM, Jacek Caban ja...@codeweavers.com

Re: [Mingw-w64-public] Patch for widl Makefile rule bug when builddir!=srcdir

2013-02-13 Thread Jacek Caban
having avoided it so far! Ho hum... an update is in progress. On Mon, Feb 11, 2013 at 10:58 AM, Jacek Caban ja...@codeweavers.com wrote: Hi Ray, Sorry for my response time too... Why don't you put the warning in configure.ac instead of Makefile? Also the warning could say something like

Re: [Mingw-w64-public] IID_IWbemLocator

2013-02-22 Thread Jacek Caban
On 02/20/13 14:42, Christian Franke wrote: Ahmet Alacadoğan wrote: which lib has this reference in mingw w64 i used -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lcomdlg32 -ladvapi32 -lwindowscodecs -ld3d9 -lole32 -loleaut32 -luuid no luck No lib*.a file from recent (Cygwin) package

Re: [Mingw-w64-public] error while compiling libvmime

2013-02-26 Thread Jacek Caban
On 02/26/13 15:53, Vincent Torri wrote: hey while compiling libvmime 0.9.1 with gcc 4.7.2 (targetting 64 bits), i had that error libtool: compile: x86_64-w64-mingw32-g++ -DHAVE_CONFIG_H -I. -I.. -I/opt/efl64/include -I.. -D_REENTRANT=1 -D_THREAD_SAFE=1

Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers

2013-03-14 Thread Jacek Caban
On 3/14/13 8:00 PM, NightStrike wrote: Pretty much nobody uses the top level configure. It was an idea that I had that nobody really wanted, and so it fell into disuse and doesn't really work (which I guess is what you are seeing). Personally I like the idea of top level configure, *but* the

Re: [Mingw-w64-public] Typos in d3dcompiler.h

2013-04-11 Thread Jacek Caban
Hi Jonathan, On 04/11/13 12:57, Jonathan Liu wrote: Hi, I noticed some typos in d3dcompiler.h and corrected them. See attached patch. This header is imported from Wine and patches should go upstream. Please send the patch to wine-patc...@winehq.org. Thanks, Jacek

Re: [Mingw-w64-public] Typos in d3dcompiler.h

2013-04-12 Thread Jacek Caban
On 04/11/13 13:15, Jacek Caban wrote: Hi Jonathan, On 04/11/13 12:57, Jonathan Liu wrote: Hi, I noticed some typos in d3dcompiler.h and corrected them. See attached patch. This header is imported from Wine and patches should go upstream. Please send the patch to wine-patc...@winehq.org

Re: [Mingw-w64-public] [PATCH] msvcr*: add aliases for some underscore prefixed funtions:

2013-04-18 Thread Jacek Caban
On 04/18/13 09:41, Rafaël Carré wrote: Le 18/04/2013 09:40, Kai Tietz a écrit : Hello Rafael, patch is ok. Could you do the same for msvcrt.def files, too? I was unsure if doing it was necessary because they are already present in moldname, should they be removed from moldname then? Could

Re: [Mingw-w64-public] [PATCH] msvcr*: add aliases for some underscore prefixed funtions:

2013-04-18 Thread Jacek Caban
On 04/18/13 10:37, Rafaël Carré wrote: Le 18/04/2013 10:11, Jacek Caban a écrit : On 04/18/13 09:41, Rafaël Carré wrote: Le 18/04/2013 09:40, Kai Tietz a écrit : Hello Rafael, patch is ok. Could you do the same for msvcrt.def files, too? I was unsure if doing it was necessary because

Re: [Mingw-w64-public] Msvcrt.dll

2013-04-23 Thread Jacek Caban
On 04/23/13 09:01, Алексей Павлов wrote: Hi! With mingw-w64 runtime revision 5806 I have error when building Python (32 and 64 bit) version: Entry point daylight not found in msvcrt.dll With revision 5806 I don't have this error. Are you sure about the revision? That commit didn't touch

Re: [Mingw-w64-public] Msvcrt.dll

2013-04-23 Thread Jacek Caban
On 04/23/13 12:12, Alexpux wrote: Sorry I am not clearly write here. Revision 5806 is work. But last revision 5811 has issue that I wrote in top message. Please try try his patch: http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/6ef6839128c1c71fd72d6c492bfdec4a0ea3913e Jacek

Re: [Mingw-w64-public] Msvcrt.dll

2013-04-24 Thread Jacek Caban
On 04/23/13 14:06, Алексей Павлов wrote: Thanks Jacek. Your patch resolv issue with daylight. The patch is committed to SVN now. Cheers, Jacek -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only

Re: [Mingw-w64-public] Suggestion for FAQ Re _vswprintf and msvcrt.dll on XP SP1

2013-05-08 Thread Jacek Caban
On 5/8/13 7:27 AM, xunxun wrote: 于 2013/1/21 星期一 21:07, Kai Tietz 写道: 2013/1/21 Jacek Caban ja...@codeweavers.com: On 01/21/13 13:39, JonY wrote: On 1/21/2013 09:43, Herb Thompson wrote: Q: Why do some 32-bit MinGW-w64 applications fail with '... _vswprintf could not be located

Re: [Mingw-w64-public] Suggestion for FAQ Re _vswprintf and msvcrt.dll on XP SP1

2013-05-10 Thread Jacek Caban
On 05/10/13 11:11, xunxun wrote: 于 2013/5/9 星期四 10:40, xunxun 写道: 于 2013/5/9 星期四 6:27, Jacek Caban 写道: On 5/8/13 7:27 AM, xunxun wrote: 于 2013/1/21 星期一 21:07, Kai Tietz 写道: 2013/1/21 Jacek Caban ja...@codeweavers.com: On 01/21/13 13:39, JonY wrote: On 1/21/2013 09:43, Herb Thompson wrote

Re: [Mingw-w64-public] Suggestion for FAQ Re _vswprintf and msvcrt.dll on XP SP1

2013-05-13 Thread Jacek Caban
On 05/13/13 03:56, xunxun wrote: 于 2013/5/10 星期五 17:17, Jacek Caban 写道: On 05/10/13 11:11, xunxun wrote: 于 2013/5/9 星期四 10:40, xunxun 写道: 于 2013/5/9 星期四 6:27, Jacek Caban 写道: On 5/8/13 7:27 AM, xunxun wrote: 于 2013/1/21 星期一 21:07, Kai Tietz 写道: 2013/1/21 Jacek Caban ja...@codeweavers.com

Re: [Mingw-w64-public] [PATCH] dxva2api.h: include d3d9.h

2013-06-10 Thread Jacek Caban
On 06/10/13 11:48, Rafaël Carré wrote: diff --git a/mingw-w64-headers/include/dxva2api.idl b/mingw-w64-headers/include/dxva2api.idl index c0fd3b0..5d8646f 100644 --- a/mingw-w64-headers/include/dxva2api.idl +++ b/mingw-w64-headers/include/dxva2api.idl @@ -12,6 +12,8 @@ typedef DWORD

Re: [Mingw-w64-public] endpointvolume.h and KS* structures inconsistencies

2013-06-13 Thread Jacek Caban
On 06/13/13 00:11, JonY wrote: I discovered it was including devicetopology.h and then including ks.h and ksmedia.h. These declarations are already in devicetopology.h but dummied out because it was checking for _KS_ #define before declaring these. ks.h defines it and blocks the declaration.

Re: [Mingw-w64-public] What is the purpose of intrin.h?

2013-06-14 Thread Jacek Caban
On 06/14/13 09:43, dw wrote: I'd like to discuss the entire purpose of the intrin.h file in gcc. In response to my recent proposed patch re __faststorefence, Kai remarked that making changes to intrin.h is something we should be minimizing/avoiding. Until this point, I hadn't been aware

Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange

2013-06-17 Thread Jacek Caban
On 06/16/13 11:42, Erik van Pienbroek wrote: Erik van Pienbroek schreef op vr 14-06-2013 om 19:28 [+0200]: For now I've managed to workaround the regression by partially reverting r5713. This change makes intrincs/ilockcxch.c part of libmingwex instead of libkernel32 (as it was before r5713).

Re: [Mingw-w64-public] WIDL feature requests

2013-06-19 Thread Jacek Caban
Hi Geoffroy, On 06/17/13 18:42, Geoffroy Couprie wrote: Hi, I am currently working on writing the IDL files for new WinRT interfaces (mostly Windows.Storage and Windows.Foundation for now), and there are a few things I would need to make it work. Right now, I can comment out the problematic

Re: [Mingw-w64-public] What is the purpose of intrin.h?

2013-06-26 Thread Jacek Caban
On 06/25/13 21:05, Kai Tietz wrote: Ok, patch is ok. I would like that Jacek takes a closer look to it, too. I still don't get, why we need those functions in crt. I retested and: - -fno-inline is not a problem here. We use always_inline attribute and it works fine, whatever compiler/linker

Re: [Mingw-w64-public] What is the purpose of intrin.h?

2013-06-27 Thread Jacek Caban
On 06/26/13 23:57, dw wrote: I still don't get, why we need those functions in crt. The problem is that in MSVC it it perfectly legal to just copy/paste the prototype for one of the intrinsics in your file and use it (see example below). It is NOT necessary to include intrin.h. If we want

Re: [Mingw-w64-public] [PATCH] ___lc_codepage_func: use correct name and export from all versions of MSVCRT

2013-06-27 Thread Jacek Caban
Hi Rafaël, On 06/26/13 22:53, Rafaël Carré wrote: based on a patch by Jacek Thanks for taking care of this! --- mingw-w64-crt/def-include/msvcrt-common.def.in | 2 ++ mingw-w64-crt/lib32/msvcrt.def.in | 1 - mingw-w64-crt/lib64/msvcrt.def.in | 1 - I don't think

[Mingw-w64-public] Direct2D 1.1 support

2013-06-27 Thread Jacek Caban
Hi, Please review following patches adding support for more Direct2D stuff, most notably its 1.1 version. http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/f4447e79179ac9761331eb9372542cb165667230 http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/ef66da51ded4b378a9e6fa541934386cee555a9e

Re: [Mingw-w64-public] [PATCH] ___lc_codepage_func: use correct name and export from all versions of MSVCRT

2013-06-27 Thread Jacek Caban
On 06/27/13 18:11, Rafaël Carré wrote: Le 27/06/2013 17:17, Earnie Boyd a écrit : On Thu, Jun 27, 2013 at 10:21 AM, Rafaël Carré wrote: However ___lc_codepage_func seems to be also present in msvcrt.dll so why do we need emul? That depends on the version of MSVCRT.DLL on the users system. It

Re: [Mingw-w64-public] What is the purpose of intrin.h?

2013-06-28 Thread Jacek Caban
On 06/28/13 01:39, dw wrote: While I wasn't fun of adding new header in your previous patch (why would we do that if it's included only from one file, intrin.h, anyway?), we may add (yet another:/) new header for those shared intrins and include it both from winnt.h and intrin.h. I'm not

Re: [Mingw-w64-public] [PATCH] ___lc_codepage_func: use correct name and export from all versions of MSVCRT

2013-06-28 Thread Jacek Caban
On 06/27/13 20:48, Rafaël Carré wrote: Le 27/06/2013 18:33, Kai Tietz a écrit : 2013/6/27 Jacek Caban ja...@codeweavers.com: On 06/27/13 18:11, Rafaël Carré wrote: Le 27/06/2013 17:17, Earnie Boyd a écrit : On Thu, Jun 27, 2013 at 10:21 AM, Rafaël Carré wrote: However ___lc_codepage_func

Re: [Mingw-w64-public] Mass rebuild report for June 30 2013

2013-07-01 Thread Jacek Caban
On 06/30/13 16:03, Erik van Pienbroek wrote: i686-w64-mingw32-g++ -mwindows -o TimeStamp_posix.o -c -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DNO_NSPR_10_SUPPORT -D_IMPL_NS_COM

Re: [Mingw-w64-public] What is the purpose of intrin.h?

2013-07-01 Thread Jacek Caban
On 06/30/13 09:06, dw wrote: So, I have taken another shot at this (attached). It compiles and my test programs are running, but I haven't finished testing it (so please, don't anyone commit this change yet). I think I have included everyone's feedback, but I have thought that before. After

Re: [Mingw-w64-public] Direct2D 1.1 support

2013-07-01 Thread Jacek Caban
On 06/27/13 15:17, Jacek Caban wrote: Hi, Please review following patches adding support for more Direct2D stuff, most notably its 1.1 version. http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/f4447e79179ac9761331eb9372542cb165667230 http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff

Re: [Mingw-w64-public] What is the purpose of intrin.h?

2013-07-02 Thread Jacek Caban
On 07/02/13 01:48, dw wrote: I may apply the patch and let my cron jobs run it through Mozilla sources over night if you like. In the past, those caught quite a few problems with intrin.h. That would be great. I've spent a bit more time on in today, and will probably give it a final look in

Re: [Mingw-w64-public] [Patch] intrinsics, __faststorefence, _ReadWriteBarrier et al

2013-07-03 Thread Jacek Caban
On 07/03/13 02:29, dw wrote: Thanks to both Kai and Jacek whose suggestions made this patch much better. This patch includes two parts. The first (and more important) deals with how MSVC's intrinsics are used in mingw-w64: winnt.h: - In all cases (x86, x64, cygwin, not cygwin), remove

Re: [Mingw-w64-public] [Patch] intrinsics, __faststorefence, _ReadWriteBarrier et al

2013-07-03 Thread Jacek Caban
On 07/03/13 12:22, Kai Tietz wrote: 2013/7/3 Jacek Caban ja...@codeweavers.com: Looks good to me. Thanks, Jacek Yes, patch is ok. Jacek feel free to commit. Committed as r5924. Thanks, Jacek -- This SF.net email

Re: [Mingw-w64-public] What belongs in winnt.h?

2013-07-09 Thread Jacek Caban
On 07/06/13 11:00, dw wrote: 3) Where winbase.h defines __stdcall prototypes for these functions, keep the implementation in the library. You know, now that I think about it, I have to ask if leaving these __stdcall implementations in the library is actually useful. After all, it's not

Re: [Mingw-w64-public] What belongs in winnt.h?

2013-07-11 Thread Jacek Caban
On 07/11/13 00:41, dw wrote: Sorry for the delay Since you always have something interesting to say, you are forgiven. Remove non-underscored (aka. __stdcall) variants from mingwex. It's exported by kernel32.dll, so we may use it if needed (or is there some compatibility reason not to?)

[Mingw-w64-public] Interlocked* patches follow-up

2013-07-15 Thread Jacek Caban
Hi, Please review following patches: http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/45606ff91bcf7bf34e81acc13ce239bc524290cd Let's get rid of empty files. http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/7de73e013cbeec88464d19b07bccfc46285c35a5 Inline functions are better way for

Re: [Mingw-w64-public] Interlocked* patches follow-up

2013-07-16 Thread Jacek Caban
On 07/15/13 22:34, dw wrote: Let's get rid of empty files. Ok by me. Since my automake isn't up to creating .in files, I was going to wait until I was sure I wasn't going to have any more before asking someone to help. I'm aware of at least one more file that needs to have this done

Re: [Mingw-w64-public] Interlocked* patches follow-up

2013-07-16 Thread Jacek Caban
This seems to be GCC limitation. I experimented a bit and it can't inline function if it's also declared as dllimport. That fact, in combination with always_inline, causes an error. We may work around that by not using always_inlines for those functions and being careful to not use dllimport in

Re: [Mingw-w64-public] Interlocked* patches follow-up

2013-07-16 Thread Jacek Caban
there a fix for that. It might be interesting if rgat change relaxes the other inline-issue too. Kai Am 16.07.2013 04:31 schrieb Jacek Caban ja...@codeweavers.com mailto:ja...@codeweavers.com: This seems to be GCC limitation. I experimented a bit and it can't inline function if it's also

Re: [Mingw-w64-public] Mass rebuild report for July 15 2013

2013-07-17 Thread Jacek Caban
On 07/15/13 23:50, Erik van Pienbroek wrote: mingw-wine-gecko-2.21-1 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130715/mingw-wine-gecko-2.21-1 Also winpthreads related. Bug has already been reported upstream and a patch is pending approval:

Re: [Mingw-w64-public] Interlocked* patches follow-up

2013-07-17 Thread Jacek Caban
On 07/17/13 01:12, dw wrote: Please review the new patch Well, we got your good news and your bad news. On the plus side, this patch fixes the problem I was seeing with -Os. On the downside, my release build script also uses -fwhole-program. This is giving me a link error: /undefined

Re: [Mingw-w64-public] Interlocked* patches follow-up

2013-07-18 Thread Jacek Caban
On 07/18/13 08:49, dw wrote: this issue seems t be related to a bug fixed for gcc' trunk and for the 4.8 branch. Could you test more recent version to see if issue remains? Umm. Hmm. Ok, well, the compiler now does (silently) pick one of the two defined implementations and uses it

Re: [Mingw-w64-public] [PATCH] Remove reference to strnlen from msvcrt.def

2013-07-19 Thread Jacek Caban
On 07/19/13 07:43, Ozkan Sezer wrote: On Fri, Jul 19, 2013 at 4:16 AM, Kai Tietz ktiet...@googlemail.com wrote: I am not able your patch the next two weeks. If Jacek, Ozkan, or dw confirm, then patch is oj for appkay. Looks good to me. Ideally, we should move that to libmsvcrt.a like some

Re: [Mingw-w64-public] Interlocked* patches follow-up

2013-07-19 Thread Jacek Caban
On 07/18/13 23:43, dw wrote: I can confirm that with GCC 4.9. In cause of our headers, it always chooses inline version, which is good. That is the best possible outcome. For this particular situation. But it's possible that's not always the case. What with normal implementations, inline

Re: [Mingw-w64-public] Interlocked* patches follow-up

2013-07-20 Thread Jacek Caban
On 07/18/13 23:43, dw wrote: I can confirm that with GCC 4.9. In cause of our headers, it always chooses inline version, which is good. That is the best possible outcome. For this particular situation. But it's possible that's not always the case. What with normal implementations, inline

Re: [Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?

2013-07-20 Thread Jacek Caban
On 07/20/13 12:22, Erik van Pienbroek wrote: dw schreef op za 20-07-2013 om 02:07 [-0700]: An argument could be made that we have broken backward compatibility and it's our responsibility to fix it. On the other hand, one could say they are using our library incorrectly (by not including any

Re: [Mingw-w64-public] [Patch] Updates for winbase.h

2013-07-22 Thread Jacek Caban
On 07/22/13 03:48, dw wrote: This patch has nothing to do with boost, and makes no changes to inline asm. Just some simple header changes. This patch: - Allows winbase.h to use inline intrinsics whether winnt.h is also included or not. - Brings x86 versions of InterlockedAnd64 et al into

Re: [Mingw-w64-public] Fwd: [Mingwbuilds-users] Is Win 2000 supported?

2013-07-22 Thread Jacek Caban
Hi, I thought it was fixed already, but apparently a part of the fix was missing. I committed a fix. BTW, it should be GCC version independent, it's a matter of mingw-w64-crt. Jacek On 07/22/13 11:14, niXman wrote: -- Forwarded message -- From: *Martin Mitás(*

Re: [Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?

2013-07-22 Thread Jacek Caban
On 07/21/13 17:02, Erik van Pienbroek wrote: Erik van Pienbroek schreef op zo 21-07-2013 om 14:49 [+0200]: So now I think it's up to us to come up with the most proper fix which we can then try to get upstreamed. Attached is the patch I came up with to fix the build issue. It is basically

Re: [Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?

2013-07-22 Thread Jacek Caban
On 07/21/13 23:24, dw wrote: Attached is the patch I came up with to fix the build issue. You are checking for defined(__MINGW64_VERSION_MAJOR). Would it make sense to do (__MINGW64_VERSION_MAJOR = 3)? IMO, if the change works with older mingw-w64 release, not checking version is better. If

Re: [Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?

2013-07-23 Thread Jacek Caban
On 7/23/13 10:53 PM, Erik van Pienbroek wrote: Jacek Caban schreef op ma 22-07-2013 om 11:50 [+0200]: On 07/21/13 23:24, dw wrote: Attached is the patch I came up with to fix the build issue. You are checking for defined(__MINGW64_VERSION_MAJOR). Would it make sense to do

Re: [Mingw-w64-public] [Patch] Fix warning error error for membarrier.c

2013-07-23 Thread Jacek Caban
On 7/23/13 11:20 PM, dw wrote: There is a compile warning coming from intrincs/membarrier.c: /../../mingw-w64/mingw-w64-crt/intrincs/membarrier.c:4:6: warning: no previous prototype for 'MemoryBarrier' [-Wmissing-prototypes]/ There are two ways to fix it. 1) The easy, non-controversial way

Re: [Mingw-w64-public] [Patch] Update winnt.h to be in line with MS

2013-07-25 Thread Jacek Caban
On 07/24/13 23:37, dw wrote: Minor tweaks to bring defs in line with MS. Looks good to me. Thanks, Jacek -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application

Re: [Mingw-w64-public] Dependency on libgcc_s_sjlj-1.dll for i686 shared libraries when gcc 4.8 is used

2013-08-12 Thread Jacek Caban
On 08/12/13 18:02, Erik van Pienbroek wrote: Does anybody have an idea what might be going on here and whether anything can be done to prevent this from happening? It is currently causing issues for us with wine/wine-gecko. This doesn't answer your general question, but for wine-gecko, I fixed

Re: [Mingw-w64-public] Dependency on libgcc_s_sjlj-1.dll for i686 shared libraries when gcc 4.8 is used

2013-08-13 Thread Jacek Caban
On 08/12/13 18:37, Michael Cronenworth wrote: On 08/12/2013 11:23 AM, Jacek Caban wrote: This doesn't answer your general question, but for wine-gecko, I fixed it upstream, see: https://bugzilla.mozilla.org/show_bug.cgi?id=876416 I may provide a backport in release branches, let me know which

Re: [Mingw-w64-public] [Patch] intrinsics

2013-08-17 Thread Jacek Caban
Hi, It's a really delayed reply, dw asked me to join the conversation. On 08/09/13 13:07, Kai Tietz wrote: Hi, sorry for the delayed answer per mail. 2013/8/9 dw limegreenso...@yahoo.com: So, no response here, other than a few (brief) comments on irc. It's hard to know how to advocate

Re: [Mingw-w64-public] [PATCH 1/2] synchapi.h: APIs are not forbidden on Windows Store

2013-08-19 Thread Jacek Caban
On 08/19/13 06:38, Rafaël Carré wrote: Le 18/08/2013 21:43, Kai Tietz a écrit : 2013/8/15 Rafaël Carré fun...@videolan.org: --- mingw-w64-headers/include/synchapi.h | 5 - 1 file changed, 5 deletions(-) diff --git a/mingw-w64-headers/include/synchapi.h

Re: [Mingw-w64-public] Trunk[r6090] broken on redefinition of 'IID_*'

2013-08-19 Thread Jacek Caban
On 08/19/13 10:52, Rafaël Carré wrote: Le 19/08/2013 09:02, Dongsheng Song a écrit : cauchy@CRM-SYSLOG:~/obj/i686-w64-mingw32-gcc48/mingw-w64-crt$ make make all-am make[1]: Entering directory `/home/cauchy/obj/i686-w64-mingw32-gcc48/mingw-w64-crt' i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I.

Re: [Mingw-w64-public] Build issues on trunk

2013-08-22 Thread Jacek Caban
Hi Erik, On 08/21/13 07:55, Erik van Pienbroek wrote: Hi, The current trunk seems to have some conflicting declarations which causes various build failures. Here are the failures we discovered with the test mass rebuild script. === NSIS: i686-w64-mingw32-gcc -o

Re: [Mingw-w64-public] Build issues on trunk

2013-08-27 Thread Jacek Caban
On 08/22/13 15:30, Jacek Caban wrote: Hi Erik, On 08/21/13 07:55, Erik van Pienbroek wrote: Hi, The current trunk seems to have some conflicting declarations which causes various build failures. Here are the failures we discovered with the test mass rebuild script. === NSIS: i686-w64

Re: [Mingw-w64-public] [Patch] intrinsics

2013-09-07 Thread Jacek Caban
On 09/07/13 03:20, JonY wrote: On 9/7/2013 08:44, dw wrote: However, if that's not acceptable, perhaps there is an alternative. If the requirement I'm violating here is simply that these specific functions must be able to support not being inlined, then I believe simply changing them from

Re: [Mingw-w64-public] [Patch] intrinsics

2013-09-09 Thread Jacek Caban
On 09/09/13 14:51, Kai Tietz wrote: Hmm? I thought I said already all I have to say to this. Well, you gave reasons that others don't agree with so we kind of expected you to answer to those doubts. 1) I see no good need to remove non-inline variant from libmingwex.a library. 2) If something

Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers

2013-09-10 Thread Jacek Caban
On 9/10/13 8:25 PM, Erik van Pienbroek wrote: wine-gecko: --- ../../widget/windows/JumpListBuilder.o: In function `ZN7mozilla6widget15JumpListBuilderC2Ev': /builddir/build/BUILD/mingw-wine-gecko-2.21/wine-mozilla-2.21/widget/windows/JumpListBuilder.cpp:54: undefined reference to

Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers

2013-09-11 Thread Jacek Caban
On 09/10/13 20:35, Jacek Caban wrote: On 9/10/13 8:25 PM, Erik van Pienbroek wrote: wine-gecko: --- ../../widget/windows/JumpListBuilder.o: In function `ZN7mozilla6widget15JumpListBuilderC2Ev': /builddir/build/BUILD/mingw-wine-gecko-2.21/wine-mozilla-2.21/widget/windows

  1   2   3   4   5   6   7   8   >