---
mingw-w64-headers/include/wlanapi.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/mingw-w64-headers/include/wlanapi.h b/mingw-w64-headers/include/wlanapi.h
index fa0e506..1f7dc49 100644
--- a/mingw-w64-headers/include/wlanapi.h
+++ b/mingw-w64-headers/include/wlanapi.h
@@
---
mingw-w64-headers/include/l2cmn.h | 20
1 file changed, 20 insertions(+)
create mode 100644 mingw-w64-headers/include/l2cmn.h
diff --git a/mingw-w64-headers/include/l2cmn.h b/mingw-w64-headers/include/l2cmn.h
new file mode 100644
index 000..8157df9
--- /dev/null
---
mingw-w64-headers/crt/sec_api/string_s.h | 3 +++
mingw-w64-headers/crt/sec_api/wchar_s.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/mingw-w64-headers/crt/sec_api/string_s.h b/mingw-w64-headers/crt/sec_api/string_s.h
index 34d1c99..4b10820 100644
---
---
mingw-w64-headers/include/tsattrs.h | 100
1 file changed, 100 insertions(+)
create mode 100644 mingw-w64-headers/include/tsattrs.h
diff --git a/mingw-w64-headers/include/tsattrs.h b/mingw-w64-headers/include/tsattrs.h
new file mode 100644
index
aren't used. So I would think that attribute unused is missing here.
Additionally the 'inline' looks to me bogus. Either it should be
extern inline, or static with attribute unused.
Kai
2014-08-19 14:02 GMT+02:00 Jacek Caban ja...@codeweavers.com:
---
mingw-w64-headers/crt/sec_api/string_s.h
[x] Yes, move to git
[ ] No, continue with SVN
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing
On 04/28/14 13:17, JonY wrote:
Discuss.
I will just add a huge YEAH from me. I'm happy to help with the migration.
Cheers,
Jacek
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run
On 04/24/14 11:26, G M wrote:
Hi Everyone
I thought you might want to know that if I use clang 3.5 from trunk to
compile mingw's windows.h file like so:
// w3.cpp - no main even
#include windows.h
clang++ -fms-extensions w3.cpp
I get errors the errors shown below. I emailed one of the
On 03/28/14 15:39, Erik van Pienbroek wrote:
Hi,
Attached patch fixes a compatibility issue with p11-kit and sigar on
Windows XP (missing strerror_s symbol). Okay to commit?
Looks good to me.
Thanks,
Jacek
--
Hi,
On the trunk, we no longer need __USE_MINGW_OUTPUT_FORMAT_EMU nor
__mingw_set_output_format. We use linker tricks to do the work without
any user action:
http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/53e6165916a0cdc4d096bff13ce60cb825def2f2
Note that the change affected both headers and
Hi Adrien,
On 02/17/14 21:18, Adrien Nader wrote:
On Wed, Feb 12, 2014, Kai Tietz wrote:
2014-02-12 10:58 GMT+01:00 Jacek Caban ja...@codeweavers.com:
On 02/12/14 08:57, Adrien Nader wrote:
Hi,
I recently stumbled on an issue where dvec.h gets included from intrin.h
and triggers around 140
On 02/12/14 08:57, Adrien Nader wrote:
Hi,
I recently stumbled on an issue where dvec.h gets included from intrin.h
and triggers around 140 different not declared in this scope errors.
Basically, there is an #include dvec.h (which is a C++-only header)
near the top of intrin.h and the
On 12/04/13 10:37, Koehne Kai wrote:
-Original Message-
From: Alexey Pavlov [mailto:alex...@gmail.com]
Sent: Friday, September 20, 2013 9:18 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] mingw-w64 v3.0 RC1
[...]
Hi,
I was asked by a
6e3516a0ce3418dae9cd144b3380a0a91a195a4b
Author: Jacek Caban ja...@codeweavers.com
Date: Thu Sep 12 11:26:03 2013 +0200
intrin.h: Fixes for GCC 4.9.
diff --git a/mingw-w64-headers/crt/intrin.h b/mingw-w64-headers/crt/intrin.h
index ca52e97..4397c43 100644
--- a/mingw-w64-headers/crt/intrin.h
+++ b/mingw-w64-headers/crt
On 09/18/13 12:07, Kai Tietz wrote:
2013/9/18 Jacek Caban ja...@codeweavers.com:
Hi,
Please review the attached patch. It fixes trunk GCC compilation, which
is something I think should be done before v3 release. We already talked
about this on IRC and the comment has short explanation, let
On 09/16/13 21:26, Erik van Pienbroek wrote:
Any ideas on whether this should be fixed in mingw-w64?
AFAICS it's not present in PSDK. It contains only
EXCEPTION_REGISTRATION_RECORD, no EXCEPTION_REGISTRATION. It was added
by Kai in patch:
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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(*
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
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
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
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
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
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
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
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:
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
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
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
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
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
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?)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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).
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
:
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
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,
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
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
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
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
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
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
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.
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
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
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
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
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
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.
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:
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
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
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
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
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
701 - 800 of 813 matches
Mail list logo