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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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/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:
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 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 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/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/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.
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 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
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
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 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 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
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
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
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 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
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 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
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/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/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 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 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 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 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 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/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/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).
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/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
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/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/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 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 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/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/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?)
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/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
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/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/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 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/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 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/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 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 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
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/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 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/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
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 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 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/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 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:
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
1 - 100 of 813 matches
Mail list logo
