New MSYS2 snapshots:
32-bit:
x32-msys2-beta2-20130909.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-beta2-20130909.tar.xz/download>
64-bit:
x64-msys2-beta2-20130909.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/
On 9/9/2013 07:02, K. Frank wrote:
>> why?
>
> I don't really know why, but it looks like memory and other c++-specific
> things are being put in their own c++ subdirectory of include.
>
> Again, I don't know the details, but g++ knows somehow to look there
> automatically.
>
The C++ headers ar
What's the difference between msys2_shell.bat and mingw_shell.bat?
Thanks a lot!
2013/9/9 Alexey Pavlov
> New MSYS2 snapshots:
>
> 32-bit:
> x32-msys2-beta2-20130909.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-beta2-20130909.tar
gt; What's the difference between msys2_shell.bat and mingw_shell.bat?
>
> Thanks a lot!
>
>
> 2013/9/9 Alexey Pavlov
>
>> New MSYS2 snapshots:
>>
>> 32-bit:
>> x32-msys2-beta2-20130909.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/32
t r6233.
The following packages failed to build:
mingw-boost-1.54.0-1
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-boost-1.54.0-1
mingw-gtk3-3.9.14-1
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-gtk3-3.9.14-1
mingw-
JonY writes:
> We will be releasing v3 from trunk soon. Testers, please check with the
> latest trunk version if any of the changes break your applications!
This critical pessimization affecting C++ is still unresolved:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56892
Kai discussed the issue
On 09/07/13 02:44, dw wrote:
>> It's a really delayed reply, dw asked me to join the conversation.
>
> Hey Jacek, thanks for you thoughts on this. However, it doesn't seem
> to have brought us to a conclusion. I've been trying to avoid
> "nagging" (something I am prone to do), especially since I'
>
> Here are the initial results of a test mass rebuild which was done
> against r6233.
> The following packages failed to build:
>
> mingw-boost-1.54.0-1
> Build logs:
> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-boost-1.54.0-1
>
Someth
On 9/9/2013 20:10, Óscar Fuentes wrote:
> JonY writes:
>
>> We will be releasing v3 from trunk soon. Testers, please check with the
>> latest trunk version if any of the changes break your applications!
>
> This critical pessimization affecting C++ is still unresolved:
>
> http://gcc.gnu.org/bu
Why? A fix for this problem was already applied upstream. See ChangeLog
2013-07-08 Kai Tietz
PR target/56892
* config/i386/i386.c (TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P): Define as
hook_bool_const_tree_true.
Regards,
Kai
On 09/09/13 14:32, JonY wrote:
> tkWinSend.c:758:9: error: 'VARIANT' has no member named 'vt'
> vCmd.vt = VT_BSTR;
>
> Kai, does oaidl.h needs fixing?
I may add some info about this. This is a regression from (see changed
#if around __VARIANT_NAME_*):
http://repo.or.cz/w/mingw-w64/jacek.git/c
Ya, I agree with you.
At the end, it does not matter where the files are, what matters is that it
works. If g++ finds it... who cares where the files are, I know that I don't
:)
Have great day!!
-Original Message-
From: K. Frank
Sent: Sunday, September 08, 2013 7:02 PM
To: mingw64
Subje
Hmm? I thought I said already all I have to say to this.
1) I see no good need to remove non-inline variant from libmingwex.a library.
2) If something isn't an intrinsic, well, then move the implementation
file out of the intrinsic-folder, but this doesn't mean we don't want
it in libmingwex.a lib
Agreed.
2013/9/9 Jacek Caban :
> On 09/09/13 14:32, JonY wrote:
>> tkWinSend.c:758:9: error: 'VARIANT' has no member named 'vt'
>> vCmd.vt = VT_BSTR;
>>
>> Kai, does oaidl.h needs fixing?
>
> I may add some info about this. This is a regression from (see changed
> #if around __VARIANT_NAME_*)
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 somethi
Kai Tietz writes:
> Why? A fix for this problem was already applied upstream. See ChangeLog
>
> 2013-07-08 Kai Tietz
>
> PR target/56892
> * config/i386/i386.c (TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P): Define
> as
> hook_bool_const_tree_true.
Thanks Kai. I was looking a
JonY schreef op ma 09-09-2013 om 20:32 [+0800]:
> On 9/9/2013 19:35, Erik van Pienbroek wrote:
> > wine-mono-0.0.8-3
> > Build logs:
> > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/wine-mono-0.0.8-3
> >
I just tried to rebuild this one against
On 9/10/2013 04:48, Erik van Pienbroek wrote:
> JonY schreef op ma 09-09-2013 om 20:32 [+0800]:
>> On 9/9/2013 19:35, Erik van Pienbroek wrote:
>>> wine-mono-0.0.8-3
>>> Build logs:
>>> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/wine-m
On Sun, Aug 4, 2013 at 3:12 PM, NightStrike wrote:
> On Fri, Aug 2, 2013 at 2:59 PM, Derek Buitenhuis
> wrote:
>> As it stands right now, the grouping and wrapping of filenames
>> in MinGW-w64's Makefiles makes tracking or viewing changes in
>> version control very very hard, and makes it non-obv
gt;>> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/wine-mono-0.0.8-3
> >>>
> >
> > I just tried to rebuild this one against the latest svn (r6258) and it
> > still failed to build. Now it got a different error:
> >
> > ./.libs/libmono
20 matches
Mail list logo
