Re: [Mingw-w64-public] To 32 or 64, that is the question :)

[Koehne Kai]

> -Original Message-
> From: Peter Kennard [mailto:pet...@livingwork.com]
> Sent: Friday, June 20, 2014 2:19 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] To 32 or 64, that is the question :)
> 
> as the unified installer has options for 64 and 32 bit installs.
> 
> I assume the 64 bit install will not run on a 32 bit machine or a 32 bit OS 
> install.

Yes (unless you're running it inside in an emulator ;)
 
> Does which install is chosen ONLY effect the actual running of the tools
> themselves on the HOST machine or does it have any influence on what the
> tools build and link - ie: what compile targets are built and what libraries 
> are
> present and/or linked with?

The bitness in the installer first of all says how the _toolchain_ is compiled.
By default the toolchain will also generate code for the same bitness (
32 bit gcc toolchain will generate 32 bit applications, a 64 bit gcc toolchain 
will generate
64 bit applications), but gcc is also able to work as a cross-compiler (-m64 
-m32 gcc arguments). 
I don't think all toolchains support this though, you'd have to check. Last 
time I tried the mingw-builds
toolchains supported this. 

> Or is what target is built 100% selected by the build scripts coded to use the
> tools?
>
> Related, Will both versions run underneath 32 bit shells or interpreters like
> ant, make, or ruby that may be 32 bit executables themselves yet running on
> a 64 bit OS?

Yes.

> If there is a difference in the output targets, can one install BOTH versions 
> in
> the same install directory (ie: can then unzip on either a
> 32 or 64 bit machine and the proper libraries/dlls for runtime are lanuched by
> the master .exe or does one have two installs and select which one to use by
> setting the path appropriately?

The master.exe determines the bitness. You can't AFAIK mix 32 bit libraries 
with 64 bit executables under Windows, or the other way round.
 
> Hope this isn't too messy a set of questions :)  I just didn't see any 
> explicit
> mention of it.

Regards

Kai 

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] mingw-w64 may move to git in the future

[Koehne Kai]

> -Original Message-
> From: JonY [mailto:jo...@users.sourceforge.net]
> 
> Hi,
> 
> mingw-w64 may migrate from svn to git in the future, seeing that sf can now
> do multiple repos per project.
> 
> Structure wise, everything under trunk will still stay together in the new 
> repo,
> but any externals, /experimental/* and /web may move into its own repo.
> 
> Discuss.

+1 

Just because I'm a daily git user, and I'm having a hard time doing anything 
beyond a mere check-out in svn. Again and again :) Just this morning I was 
searching for a semi-official github clone of Mingw-w64 ...

It obviously depends from what you know, but git really has established itself 
as 'the' versioning system in the open source world by now.

Regards

Kai

PS: Maybe interesting: Why the ICU project won't move from svn to git any time 
soon: http://sourceforge.net/p/icu/mailman/message/31814825/ . It comes down to 
references to svn revisions all over the place.
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Experimental builds of GCC-4.9.0

[Koehne Kai]

> -Original Message-
> From: niXman [mailto:i.nix...@autistici.org]
> Sent: Tuesday, November 19, 2013 10:10 PM
> To: mingw-w64-public
> Subject: [Mingw-w64-public] Experimental builds of GCC-4.9.0
> 
> 
> Hi guys!
> Just now I uploaded new builds based on the GCC-4.9.0-trunk(rev.
> 205009), mingw-w64-trunk(rev. 6379)

Hi!

Gcc 4.9.0 got finally released two days ago ... Do you plan to ship pre-built 
binaries for it soon, too? Would be pretty cool to give the new features a 
whirl :)

Thanks for your incredible work!

Kai

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Determining whether mingw dll is a debug build based on PE structure?

[Koehne Kai]

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 03.04.2014 14:42, Koehne Kai wrote:
> > Hi,
> >
> > Anyone knows by heart what to check for in a PE header to decide
> > whether a dll is a debug build, or not?
> >
> > Background: Qt has a neat tool to package all of the Qt/non qt
> > dependencies together for deployment: windeployqt. To function
> > properly, it has to decide whether an executable/dll is a debug build,
> > or not ...
> 
> Why does it need to know whether a binary is a debug build or not?

Because in the Qt packages we go the 'MSVC way' in Qt and offer both a full 
debug build and a release build of our libraries side by side.

You don't really want to package all of them by default though (the gcc debug 
binaries can be obscenely large). So given a binary, I need a hint what type of 
build it is. 

> Also, define "debug build"? -g? -O0? -DDEBUG=1?

Well, in the MSVC world it's easy: A debug build is s.th. that depends on debug 
version of the MSVC runtime :) For my use case, I think actually any of the 
above would be 'good enough'.

(Btw, what I'd _love_ to do actually is having a setup like it's common on 
Linux, where you've one set of libs/binaries, but stripped debug information 
besides. Never managed to get this working with MinGW though ... Anyone has 
experience with such a setup ?)

Regards

Kai

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

Re: [Mingw-w64-public] Determining whether mingw dll is a debug build based on PE structure?

[Koehne Kai]

> -Original Message-
> From: TOCK [mailto:tock.c...@gmail.com]
> Sent: Thursday, April 03, 2014 12:59 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Determining whether mingw dll is a debug
> build based on PE structure?
> 
> I think you can use objdump to determine it.
> For example on my PC:
> 
> C:\Users\TOCK>objdump -f foo.dll
> 
> foo.dll: file format pei-x86-64
> architecture: i386:x86-64, flags 0x013b:
> HAS_RELOC, EXEC_P, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, D_PAGED start
> address 0x6ae81400
> 

Objdump was a great hint, thanks! I checked the source code of the pfd library 
it uses, and it seems it just checks for the IMAGE_FILE_DEBUG_STRIPPED flag in 
the PE header:

  if ((internal_f->f_flags & IMAGE_FILE_DEBUG_STRIPPED) == 0)
abfd->flags |= HAS_DEBUG;


I've yet to experiment a bit with it , but right now it looks like I could use 
that check, too ...

Regards

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

[Mingw-w64-public] Determining whether mingw dll is a debug build based on PE structure?

[Koehne Kai]

Hi,

Anyone knows by heart what to check for in a PE header to decide whether a dll 
is a debug build, or not?

Background: Qt has a neat tool to package all of the Qt/non qt dependencies 
together for deployment: windeployqt. To function properly, it has to decide 
whether an executable/dll is a debug build, or not ... 

The logic so far is at:
https://qt.gitorious.org/qt/qttools/source/24ed30750d87e022f583c64cf0ff77652ec1078b:src/windeployqt/utils.cpp#L731

And we decide whether it's a debug build or not is essentially (32 bit):

ntHeaders32->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_DEBUG].Size != 0

Now that fails for Mingw :(

I've to admit I'd have only occasionally exposure to the PE file format, so 
before spending too much time on it: Does anyone know a way to do this check 
for MinGW? Is it even possible?

Regards

Kai

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

Re: [Mingw-w64-public] Building a library for use under Visual Studio 2008

[Koehne Kai]

> -Original Message-
> From: Suresh Govindachar [mailto:sgovindac...@yahoo.com]
> [...]
>   I have no preference for what command line compiler I use (g++,
>   clang, llvm) (provided the installation involves just extracting
>   files and setting up paths) and I don't care how the binary files
>   are organized as long as I can use Makefiles, Vim, and C++
>   features, while recipients of my work can work under Visual Studio
>   2008 without needing the tools I would have on my computer.

I'd really recommend going down the well trotted path of shipping sources
that compile natively on all toolchains. If you can start relying on 2014
that's actually not that much of a headache any more, even for
most C++11 features. You'll hit issues the first time you try, but then again
the solution is most likely only one stackoverflow page away :)

For the build system, it's easiest to use a system that can either
generate .vsproj files, or nmake/jom friendly Makefiles (like cmake, qmake ...)
If you insist on rolling your own Makefile (to everyone what he prefers),
you can try to write one that both GNU make and nmake/jom are happy with.

Regards

Kai

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] build cross compiler mingw w64 gcc 4.8.2 on linux with winpthreads

[Koehne Kai]

> -Original Message-
> From: lh_mouse [mailto:lh_mo...@126.com]
> Sent: Friday, February 21, 2014 9:21 AM
> To: mingw-w64-public
> Subject: Re: [Mingw-w64-public] build cross compiler mingw w64 gcc 4.8.2 on
> linux with winpthreads
> 
> It CRASHES.

Can you elaborate?  Are you talking about crashes unrelated to the 
alien-callstack problem?

We (Qt Project) are happily shipping mingw-builds 
x32-4.8.0-release-posix-dwarf-rev2 as part of our SDK, without any problems 
(also from users). For Qt 5.3 we'll plan to ship 
i686-4.8.2-release-posix-dwarf-rt_v3-rev2...

Previously we were shipping x32-4.7.2-release-posix-sjlj-rev8 , but got bug 
reports that compiled binaries were to slow (also compared to mingw.org). And 
the culprit was ... SJLJ, with about 25% penality for an application that 
essentially didn't use exceptions at all!

See also
http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/6874

It's of course up to everyone to decide whether the performance penality is 
worth the ability to throw exceptions to alien call stacks ... In the Qt world 
exceptions are traditionally used very conservatively.

Regards

Kai

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] build cross compiler mingw w64 gcc 4.8.2 on linux with winpthreads

[Koehne Kai]

> -Original Message-
> From: JonY [mailto:jo...@users.sourceforge.net]
> [...]
> FYI dwarf2 exception is known to be broken for Windows.

The only defect I know of is that it doesn't support throwing exceptions 
through native stacks (i.e. Windows handlers). Or is there anything else? Cause 
SJLJ comes with such a high runtime price that I wouldn't recommend anyone to 
use it if he doesn't need it, for the reason above.

Let's just hope we get SEH at some point.

Regards

Kai 


--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Memory alignment issue with _mm_loadu_si128 (gcc 4.8.2 32 bit / MinGW-w64 3.0)

[Koehne Kai]

> -Original Message-
> From: Kai Tietz [mailto:ktiet...@googlemail.com]
> Sent: Wednesday, February 12, 2014 1:02 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Memory alignment issue with
> _mm_loadu_si128 (gcc 4.8.2 32 bit / MinGW-w64 3.0)
> 
> 2014-02-12 12:56 GMT+01:00 Koehne Kai :
> > Hi,
> >
> > I'm currently investigating a crash [1] in Qt that was caused by introducing
> SSE2 optimized code. My best guess is that, when calling _mm_loadu_si128 ,
> the generated assembly actually chokes on non-aligned data.
> >
> > This is the code line (with annotated assembly, from gdb):
> >
> > __m128i a_data = _mm_loadu_si128((__m128i*)ptr);
> > 0x6b7f7df4  <+0x0049> movdqa %xmm0,-0x28(%ebp)

Actually I was a bit tricked by gdb here: It didn't show the full assembly by 
default. Only when I stepped into _mm_loadu_si128 I got the full picture:

0x6b7f7de2  <+0x0037> jmp0x6b7f7eac 
0x6b7f7de7  <+0x003c> mov-0xc(%ebp),%eax
0x6b7f7dea  <+0x003f> mov%eax,-0x58(%ebp)
0x6b7f7ded  <+0x0042> mov-0x58(%ebp),%eax
0x6b7f7df0  <+0x0045> movdqu (%eax),%xmm0
0x6b7f7df4  <+0x0049> movdqa %xmm0,-0x28(%ebp)

So we're shuffling registers around here, and it looks like movdqu is used to 
align the data.

Turned out that the core of the problem was (once more) the stack alignment 
when MinGW is called from MSVC runtime, and the fix is __attribute__ 
((force_align_arg_pointer)) .

Regards

Kai

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Memory alignment issue with _mm_loadu_si128 (gcc 4.8.2 32 bit / MinGW-w64 3.0)

[Koehne Kai]

Hi,

I'm currently investigating a crash [1] in Qt that was caused by introducing 
SSE2 optimized code. My best guess is that, when calling _mm_loadu_si128 , the 
generated assembly actually chokes on non-aligned data.

This is the code line (with annotated assembly, from gdb):

__m128i a_data = _mm_loadu_si128((__m128i*)ptr);
0x6b7f7df4  <+0x0049> movdqa %xmm0,-0x28(%ebp)

You see that the _mm_loadu_si128 call, that should work for non-aligned memory 
addresses, actually is is implemented with movdqa, which is " Move Aligned 
Double Quadword".

So, do you think this is a bug, or am I on the wrong track here? If so, is it a 
gcc, or MinGW-w64 issue?

Regards

Kai

PS: I've been able to reproduce this with both Mingw-builds 
i686-4.8.2-release-posix-dwarf-rt_v3-rev2 and Mingw-builds 
x32-4.7.2-release-posix-sjlj-rev8 .

[1]: https://bugreports.qt-project.org/browse/QTBUG-36807

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mingw toolchains and Clang

[Koehne Kai]

> -Original Message-
> From: Alexey Pavlov [mailto:alex...@gmail.com]
> Sent: Wednesday, January 15, 2014 6:36 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] Mingw toolchains and Clang
> 
> Long time ago we add possibility to build Clang into mingw-builds scripts.
> Now we want to provide Clang builds for mingw-w64 toolchains.
> 
> There are two possibilities that we can do:
> 1. Include clang builds into toolchain archive 2. Provide separate builds of
> GCC+Clang
> 
> I have a question to users what use our toolchains.
> I want you to vote for the best variant of doing that.

I'd like to vote for the separate builds too. I'm especially afraid that having 
the two toolchains in one package / bin folder could confuse users, and tools 
like configure. 

(But I understand as well that creating yet another set of packages for clang 
might be quite some work for you. A compromise could be shipping clang, but in 
a separate folder, like 'clang-experimental\bin' or similar ...)

Regards

Kai

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Conflicting C/C++ linkage in xmmintrin.h vs intrin.h [solved]

[Koehne Kai]

> [..] 
>   Well, for some reason the xmmintrin.h in
> 
>   http://softlayer-dal.dl.sourceforge.net/project/mingw-
> w64/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-
> builds/4.8.2/threads-posix/dwarf/i686-4.8.2-release-posix-dwarf-rt_v3-
> rev0.7z
> 
>   doesn't seem to be from revision 6346, although buld-info.txt seems
> to claim so. It's definitely missing the patch ...
> 
> 
> 
> Subversion has sequentially numbered commits. And when we get last
> commit from stable it return current commit in all tree.
> Build-info.txt is right. You need to see not only commit but url too.

You're right, I accidentally compared revision 6346 from 
svn://svn.code.sf.net/p/mingw-w64/code/trunk, instead of 
svn://svn.code.sf.net/p/mingw-w64/code/stable/v3.x/mingw-w64-headers ...

Sorry for the noise,

Kai 

who's apparently completely git'ified by now.


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Conflicting C/C++ linkage in xmmintrin.h vs intrin.h

[Koehne Kai]

> Well, for some reason the xmmintrin.h in

I meant i686-w64-mingw32\include\intrin.h, sorry.
 
> http://softlayer-dal.dl.sourceforge.net/project/mingw-
> w64/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-
> builds/4.8.2/threads-posix/dwarf/i686-4.8.2-release-posix-dwarf-rt_v3-
> rev0.7z
> 
> doesn't seem to be from revision 6346, although buld-info.txt seems to claim
> so. It's definitely missing the patch ...
> 
> Regards
> 
> Kai
> 
> 
> --
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.cl
> ktrk
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Conflicting C/C++ linkage in xmmintrin.h vs intrin.h

[Koehne Kai]

> -Original Message-
> From: Alexpux [mailto:alex...@gmail.com]
> Sent: Wednesday, December 04, 2013 11:55 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Conflicting C/C++ linkage in xmmintrin.h vs
> intrin.h
> 
> 
> 04 дек. 2013 г., в 14:52, Jacek Caban  написал(а):
> 
> 
>   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 user of my Arch User Repository
> packages about the
>   necessity of this patch:
>   http://pkgs.fedoraproject.org/cgit/mingw-
> gcc.git/tree/gcc-make-
>   xmmintrin-header-cplusplus-compatible.patch
> 
> 
> 
>   Also we have more complex patch for it:
>   https://github.com/Alexpux/mingw-
> builds/blob/mingw-w64-
>   builds/patches/gcc/gcc-4.8-intrin.patch
> 
> 
> 
> 
>   Actually this patch seems missing from latest Mingw-builds
> 4.8.2 packages (e.g. i686-4.8.2-release-posix-dwarf-rt_v3-rev0), resulting in
> compilation errors e.g. for upcoming Qt 5.2 in release mode:
> 
>   https://bugreports.qt-project.org/browse/QTBUG-35364
> 
>   Was it a conscious decision to drop it? The upstream bug at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 still is in limbo state ...
> 
> 
> 
>   What you need is probably commit r6303, which didn't make into v3
> (it
>   was too late). I guess some distros include it. If that's the case, then
>   we should have it tested pretty well, so it could be a good candidate
>   for a cherry-pick.
> 
> 
> 
> Jacek, yes I use latest 6390 runtime from trunk for my toolchain and it works
> well.


Well, for some reason the xmmintrin.h in 

http://softlayer-dal.dl.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.2/threads-posix/dwarf/i686-4.8.2-release-posix-dwarf-rt_v3-rev0.7z

doesn't seem to be from revision 6346, although buld-info.txt seems to claim 
so. It's definitely missing the patch ...

Regards

Kai 


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Conflicting C/C++ linkage in xmmintrin.h vs intrin.h

[Koehne Kai]

> -Original Message-
> From: Alexpux [mailto:alex...@gmail.com]
> Sent: Wednesday, December 04, 2013 11:18 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Conflicting C/C++ linkage in xmmintrin.h vs
> intrin.h
> 
> 
> 04 дек. 2013 г., в 13:37, Koehne Kai  написал(а):
> 
> >
> >> -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 user of my Arch User Repository packages about the
> >> necessity of this patch:
> >>http://pkgs.fedoraproject.org/cgit/mingw-gcc.git/tree/gcc-make-
> >> xmmintrin-header-cplusplus-compatible.patch
> >>
> >>
> >>
> >> Also we have more complex patch for it:
> >> https://github.com/Alexpux/mingw-builds/blob/mingw-w64-
> >> builds/patches/gcc/gcc-4.8-intrin.patch
> >>
> >
> >
> > Actually this patch seems missing from latest Mingw-builds 4.8.2 packages
> (e.g. i686-4.8.2-release-posix-dwarf-rt_v3-rev0), resulting in compilation
> errors e.g. for upcoming Qt 5.2 in release mode:
> >
> > https://bugreports.qt-project.org/browse/QTBUG-35364
> >
> > Was it a conscious decision to drop it? The upstream bug at
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 still is in limbo
> > state :
> >
> 
> 
> Hi, Kai!
> I just now building 32-bit Qt-5.2.0 with gcc-4.8.2 and process right now on
> building QtSvg module. And I don't get this error while building QtGui.

Weird. Are you doing a release build (the definitions in xmmintrin.h is 
surrounded by #ifdef __OPTIMIZE__ ...) ?

Regards

Kai 

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Conflicting C/C++ linkage in xmmintrin.h vs intrin.h

[Koehne Kai]

> -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 user of my Arch User Repository packages about the
> necessity of this patch:
>   http://pkgs.fedoraproject.org/cgit/mingw-gcc.git/tree/gcc-make-
> xmmintrin-header-cplusplus-compatible.patch
> 
> 
> 
> Also we have more complex patch for it:
> https://github.com/Alexpux/mingw-builds/blob/mingw-w64-
> builds/patches/gcc/gcc-4.8-intrin.patch
> 


Actually this patch seems missing from latest Mingw-builds 4.8.2 packages (e.g. 
i686-4.8.2-release-posix-dwarf-rt_v3-rev0), resulting in compilation errors 
e.g. for upcoming Qt 5.2 in release mode:

https://bugreports.qt-project.org/browse/QTBUG-35364

Was it a conscious decision to drop it? The upstream bug at 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 still is in limbo state ...

Regards

Kai

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Trouble with libstdc++-6.dll

[Koehne Kai]

> -Original Message-
> From: Ingo Maindorfer [mailto:i...@liquidcooling.de]
> Sent: Tuesday, November 26, 2013 2:42 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Trouble with libstdc++-6.dll
> 
> Hi Ruben,
> 
> Am 26.11.2013 14:35, schrieb Ruben Van Boxem:
> > Exactly what Qt did you download. I can't seem to find a MinGW version
> > of 64-bit Qt 4.8.5 on the Qt Project download website.
> 
> I've loaded this one:
> http://sourceforge.net/projects/mingwbuilds/files/external-binary-
> packages/Qt-Builds/x64-Qt-4.8.5%2Bqtcreator-3.0.0-beta-%28gcc-4.8.2-seh-
> rt_v3-rev0%29.7z/download

Just a word of caution: Qt Creator 3.0 is the first version that'll make good 
use of Qt 5 features. We still keep it compiling with Qt 4, but you'll miss 
some goodies (right now Welcome Screen, Qml Designer, Qml Profiler, list will 
probably extend in the future ...)

Regards

Kai


--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Koehne Kai]

-- 
   Kai Köhne, Senior Software Engineer - Digia, Qt
   Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
   Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
   Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868
   Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


> -Original Message-
> From: Kai Tietz [mailto:ktiet...@googlemail.com]
> Sent: Friday, September 13, 2013 11:25 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers
> 
> [...]
> The idea to use an svn-hook for this, is pretty bad, as it could lead to 
> issues
> about consistency of patches due a hidden commit-conflict ... additionally SF
> has disallowed custom svn-hooks AFAIK.

Are you sure about that? I don't have a sourceforge.net project on my own (so I 
can't check), but links like below suggest to me that you can now actually have 
your own svn-hooks :

http://sourceforge.net/p/forge/documentation/svn/#hooks
http://sourceforge.net/apps/trac/sourceforge/ticket/25700


Regards

Kai 

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Koehne Kai]

> > -Original Message-
> > From: Erik van Pienbroek [mailto:e...@vanpienbroek.nl]
> > Sent: Thursday, September 12, 2013 1:00 PM
> > To: mingw-w64-public@lists.sourceforge.net
> > Subject: Re: [Mingw-w64-public] mingw-w64 v3 release calling for
> > testers
> >
> > Koehne Kai schreef op do 12-09-2013 om 06:51 [+]:
> > > > As there are no macros inside
> > > > mingw-w64 which identify the svn revision all I could came up with
> > > > is a '__MINGW64_VERSION_MAJOR < 3' conditional as best possible
> > solution.
> > >
> > > So which toolchains / Mingw-w64  versions would still break with the
> > "VERSION_MAJOR < 3" check?
> >
> > I would expect that such a conditional would break all v3/trunk
> > snapshots predating r6215, but I haven't verified this yet
> >
> > > What I care most about is that compilation still succeeds with the
> > > toolchains
> > we 'officially' shipped and endorsed in the Qt SDK at one point. That is:
> > >
> > >mingw-builds x32-4.8.0-release-posix-dwarf-rev2 using revision 5540
> > >mingw-builds x32-4.7.2-release-posix-sjlj-rev8 using revision
> > > 5796
> >
> > I don't know whether these toolchains are v2 or v3/trunk based. If it
> > is v3/trunk based, you could try to apply the patch locally on your
> > environment and see if it really does break compilation for you.
> 
> The above toolchains work just fine with the patches ... However, with the
> 
> http://sourceforge.net/projects/mingw-
> w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-
> builds/4.8.1/threads-win32/dwarf/x32-4.8.1-release-win32-dwarf-rev0.7z

Toolchain niXman provided I still get undefined symbol errors for 
IID_IFileDialogHelpers ...

./.obj\debug_shared\qwindowsdialoghelpers.o: In function 
`ZN36QWindowsNativeFileDialogEventHandler6c
reateEP28QWindowsNativeFileDialogBase':
D:/dev/qt/qt-dev/src/qtbase/src/plugins/platforms/windows/qwindowsdialoghelpers.cpp:833:
 undefined r
eference to `IID_IFileDialogEvents'
./.obj\debug_shared\qwindowsdialoghelpers.o: In function 
`ZN36QWindowsNativeFileDialogEventHandler14
QueryInterfaceERK5_GUIDPPv@12':
D:/dev/qt/qt-dev/src/qtbase/src/plugins/platforms/windows/qwindowsdialoghelpers.cpp:791:
 undefined r
eference to `IID_IFileDialogEvents'
./.obj\debug_shared\qwindowsdialoghelpers.o: In function 
`ZN28QWindowsNativeFileDialogBase6createEN1
8QFileDialogOptions10AcceptModeERK28QWindowsFileDialogSharedData':
D:/dev/qt/qt-dev/src/qtbase/src/plugins/platforms/windows/qwindowsdialoghelpers.cpp:1508:
 undefined
reference to `IID_IFileOpenDialog'
D:/dev/qt/qt-dev/src/qtbase/src/plugins/platforms/windows/qwindowsdialoghelpers.cpp:1514:
 undefined
reference to `IID_IFileSaveDialog'
collect2.exe: error: ld returned 1 exit status
jom: 
D:\dev\qt\qt-dev\mingw-builds-32-4.8.1-posix-dwarf\qtbase\src\plugins\platforms\windows\Makefil
e.Debug [..\..\..\..\plugins\platforms\qwindowsd.dll] Error 1
jom: 
D:\dev\qt\qt-dev\mingw-builds-32-4.8.1-posix-dwarf\qtbase\src\plugins\platforms\windows\Makefil
e [debug] Error 2

Indeed the IID_IFile* symbols are not exported anywhere? 


Anyhow, the patch looks fine to me, though I assume 
"__IShellEnumItems_INTERFACE_DEFINED__" was just a typo, and you could remove 
it from the check.


Do you want to put it on codereview.qt-project.org, qtbase dev branch?

Regards

Kai

PS: Sorry for the incomplete mail, Outlook once in a while tricks me by the 
'Ctrl+Enter' shortcut ...

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Koehne Kai]

> -Original Message-
> From: Erik van Pienbroek [mailto:e...@vanpienbroek.nl]
> Sent: Thursday, September 12, 2013 1:00 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers
> 
> Koehne Kai schreef op do 12-09-2013 om 06:51 [+]:
> > > As there are no macros inside
> > > mingw-w64 which identify the svn revision all I could came up with
> > > is a '__MINGW64_VERSION_MAJOR < 3' conditional as best possible
> solution.
> >
> > So which toolchains / Mingw-w64  versions would still break with the
> "VERSION_MAJOR < 3" check?
> 
> I would expect that such a conditional would break all v3/trunk snapshots
> predating r6215, but I haven't verified this yet
> 
> > What I care most about is that compilation still succeeds with the 
> > toolchains
> we 'officially' shipped and endorsed in the Qt SDK at one point. That is:
> >
> >mingw-builds x32-4.8.0-release-posix-dwarf-rev2 using revision 5540
> >mingw-builds x32-4.7.2-release-posix-sjlj-rev8 using revision 5796
> 
> I don't know whether these toolchains are v2 or v3/trunk based. If it is
> v3/trunk based, you could try to apply the patch locally on your environment
> and see if it really does break compilation for you.

The above toolchains work just fine with the patches ... However, with the 

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.1/threads-win32/dwarf/x32-4.8.1-release-win32-dwarf-rev0.7z

Regarding the specific patch:


 
> > Ideally every Qt version should still compile which every toolchain using
> 'newer' headers, but that's just a goal.
> 
> > PS: Is it possible to put the svn revision in a macro, so that we can use 
> > it in
> future incidents like that?
> 
> I totally agree, it has already happened to us Fedora folks on multiple
> occasions that we had to manually patch downstream packages due to
> changes in mingw-w64 and where it is hard to remain compatible with older
> mingw-w64 releases/snapshots.
> 
> Regards,
> 
> Erik
> 
> 
> --
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT 2.
> Standardize and globalize service processes across IT 3. Implement zero-
> touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clk
> trk
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Koehne Kai]

> -Original Message-
> From: Erik van Pienbroek [mailto:e...@vanpienbroek.nl]
> Sent: Thursday, September 12, 2013 12:40 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers
> 
> Erik van Pienbroek schreef op di 10-09-2013 om 20:25 [+0200]:
> > qt5-qtbase:
> > ---
> >
> > /builddir/build/BUILD/qtbase-opensource-src-
> 5.1.1/src/plugins/platforms/windows/qwindowsdialoghelpers.cpp:236:8:
> error: redefinition of 'struct IEnumShellItems'
> >  DECLARE_INTERFACE_(IEnumShellItems, IUnknown)
> > ^
> > In file included
> > from /usr/i686-w64-mingw32/sys-root/mingw/include/shlobj.h:100:0,
> >
> > from /builddir/build/BUILD/qtbase-opensource-src-
> 5.1.1/src/plugins/platforms/windows/qwindowsdialoghelpers.cpp:70:
> > /usr/i686-w64-mingw32/sys-root/mingw/include/shobjidl.h:10605:1: error:
> > previous definition of 'struct IEnumShellItems'
> >  IEnumShellItems : public IUnknown
> >  ^
> >
> > This is still the same as in the previous test run. I'm doing more
> > research into this one now
> 
> I've finished my research on this one and came up with a patch for qt5-
> qtbase (attached). 

Hi Erik,

Thanks a lot for the investigation !

> The annoying part is that this patch can't be properly
> upstreamed. The last part of the patch breaks compilation against older
> mingw-w64 snapshots. This is due to a change which was done in r6215:
> http://sourceforge.net/p/mingw-w64/code/6215/
> 
> In this commit the prototype for the symbol SHGetPathFromIDList get
> changed (the argument 'LPCITEMIDLIST pidl' got changed to
> 'PCIDLIST_ABSOLUTE pidl'). The qt5 folks used to work-around the invalid
> function prototype in the past but now that mingw-w64 is implementing
> things correctly this workaround breaks stuff. As there are no macros inside
> mingw-w64 which identify the svn revision all I could came up with is a
> '__MINGW64_VERSION_MAJOR < 3' conditional as best possible solution.

So which toolchains / Mingw-w64  versions would still break with the 
"VERSION_MAJOR < 3" check?

What I care most about is that compilation still succeeds with the toolchains 
we 'officially' shipped and endorsed in the Qt SDK at one point. That is:

   mingw-builds x32-4.8.0-release-posix-dwarf-rev2 using revision 5540
   mingw-builds x32-4.7.2-release-posix-sjlj-rev8 using revision 5796

Ideally every Qt version should still compile which every toolchain using 
'newer' headers, but that's just a goal.

Regards

Kai

PS: Is it possible to put the svn revision in a macro, so that we can use it in 
future incidents like that?
--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Javascript switch statement misbehavior in QtWebkit - gcc 4.8 32 bit optimization bug ?

[Koehne Kai]

> -Original Message-
> From: Kai Tietz [mailto:ktiet...@googlemail.com]
> Sent: Thursday, August 29, 2013 3:13 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Javascript switch statement misbehavior in
> QtWebkit - gcc 4.8 32 bit optimization bug ?
> 
> Hi Kai,
> 
> 2013/8/29 Koehne Kai :
> > Hi,
> >
> > We've been dealing with a strange bug report in Qt Webkit: A javascript
> 'switch' statement that does fail to work correctly, but only in the mingw
> packages.
> >
> > https://bugreports.qt-project.org/browse/QTBUG-31988
> >
> > Apparently it only affects gcc 4.8.x , 32 bit, release builds. It's also no 
> > 'new'
> code, which led us to believe it might indeed be a gcc compiler optimization
> bug.
> >
> > I know it's not much information, but isolating a small demo application out
> of the monster that is qtwebkit is challenging, so ... maybe this rings a 
> bell for
> someone? Are you aware of optimization bugs in gcc 4.8 that might explain
> the error?
> >
> > Thanks
> >
> > Kai
> 
> What gcc 4.8 version was used here?  

I tried with several versions (gcc 4.8.0, gcc 4.8.1), all from mingw-builds.

> I know that within 4.8.1 (and later on
> 4.8.x - branch), some fixes were done for C++ and throw-code.
>  Nevertheless the issue here is for sure not directly mingw-w64 related.  It
> seems to be more a general g++ issue (and should be reproducable on other
> targets too).

Good point! I tried now with a gcc 4.8.1 installed on Ubuntu 32 bit, but I 
couldn't see the error there. Well, at least the example program did work, 
which might however be just luck ...

Thanks for the idea, anyway.

Kai

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Javascript switch statement misbehavior in QtWebkit - gcc 4.8 32 bit optimization bug ?

[Koehne Kai]

Hi,

We've been dealing with a strange bug report in Qt Webkit: A javascript 
'switch' statement that does fail to work correctly, but only in the mingw 
packages.

https://bugreports.qt-project.org/browse/QTBUG-31988

Apparently it only affects gcc 4.8.x , 32 bit, release builds. It's also no 
'new' code, which led us to believe it might indeed be a gcc compiler 
optimization bug.

I know it's not much information, but isolating a small demo application out of 
the monster that is qtwebkit is challenging, so ... maybe this rings a bell for 
someone? Are you aware of optimization bugs in gcc 4.8 that might explain the 
error?

Thanks

Kai

-- 
   Kai Köhne, Senior Software Engineer - Digia, Qt
   Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
   Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
   Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868
   Registergericht: Amtsgericht Charlottenburg, HRB 144331 B



--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] End of rubenvb builds

[Koehne Kai]

> -Original Message-
> From: Adrien Nader [mailto:adr...@notk.org]
> Sent: Sunday, July 07, 2013 2:31 PM
> To: Ruben Van Boxem
> Cc: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] End of rubenvb builds
> 
> Hi,
> 
> Sorry for answering that late, I was away a bit and could catch up properly
> only now.
> 
> This email is unfortunately a bit long, sorry for that too.
> 
> On Sun, Jun 23, 2013, Ruben Van Boxem wrote:
> > Hi everyone,
> >
> > I have come to the conclusion that my MinGW-w64 builds bring too
> > little to the table for me to continue maintaining them.
> >
> > I strongly encourage you to use the plethora of toolchains in a
> > multitude of configurations available at mingw-builds. Comparing
> > download numbers they have a much higher visibility, and e.g. their
> > adoption by the Qt Project speaks of their quality. They have
> > succeeded in doing what I missed when I decided to start building GCC,
> > so my effort spent in doing that is now wasted.
> >
> > I may dabble into getting Clang 3.3 to work on Windows, perhaps even
> > with
> > libc++, but I am not promising anything.
> >
> > I'll still linger around here though, don't worry.
> 
> This is sad to read.
> As a packager I can only understand, in particular when you say that you will
> probably continue but not try to be as up-to-date as you've been so far, which
> you've done remarkably well.
> 
> I believe no such work is ever "wasted work". Remember that a few years ago,
> GCC for Windows meant mingw.org and lots of issues, starting with building
> your own toolchain. The current ease of build proves how much work on this
> has been done by everyone: building, helping, testing, fixing and so on.

I completely agree. Even while we in the qt-project ultimately went for 
mingw-builds, the personal builds by rubenv has always been my test whether a 
problem was in the mingw-builds package, or a more general upstream problem ...

> If I've understood correctly, you're basing your decision partly on the
> download stats from SF.net and the use of the mingw-builds toolchains by the
> Qt project.
> 
> Aaron Seigo had mentionned that the toolchain for the Qt project SDK had to
> use Dwarf2 EH. He also had a whole liste of *hard* requirements (like having
> multilib [ which I don't understand since QtCreator would hide it anyway ]).
> This is a case where having more choice changes a lot of
> things: most of us don't build multilib toolchains with dwarf2 eh.
> This choice doesn't change anything to the quality of the toolchains and of 
> the
> work behind them.

The requirements you mentioned didn't came from Aaron Seigo, but were collected 
on the qt-developers mailing list and put down at 
http://qt-project.org/wiki/MinGW-64-bit , 'section Criteria for original 
decision on toolchain'. They weren't really *hard requirements*, but more like 
a wishlist to at least make a decision for one project. Anyway, as Alex as 
pointed out some of them are now obsolete, since we didn't go down the path of 
e.g. using one toolchain for 32 bit and 64 bit builds.

Anyhow, the decision to go for mingw-builds was in the end not only based on 
technical criteria (besides some small mingw-make issue that was quickly 
resolved, rubenv's builds were working just fine for Qt IIRC), but also on soft 
facts like a personal build being by definition bound to one person.

> [...]
>
> You usually don't hear about users and I'm under the impression that for
> packagers it's even worse. However there are users; it might be difficult to
> understand who they are, where they are and how they use the binaries but
> they definitely exist.
> 
> I'm not trying to change anyone's mind but I know this has been an open
> question for a long time now and currently we're probably missing 99% of the
> answer.

While the question about what current users are using is already hard to 
answer, there's IMO a bigger one: What _potential_ users are there that aren't 
already using mingw-w64 :) I started looking into mingw-w64 maybe a year ago, 
only to find out that
 - there's no 'official' installer/ toolchain
 - there are a whole bunch of 'personal' builds & mingw-w64 derived projects
 - different projects provide a myriad of different gcc versions x architecture 
x exception handling mechanism x threading library combinations (and again, 
little hints on what is the 'recommended' configuration for most users).

I can easily imagine a lot of potential users are being scared away by this 
overwhelming choice.
 
Anyhow, this is going off topic here ...

Kind regards

Kai


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clk

Re: [Mingw-w64-public] PRIu64 and uint64_t

[Koehne Kai]

> -Original Message-
> From: Jim Michaels [mailto:jmich...@yahoo.com]
> Sent: Tuesday, June 11, 2013 9:23 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] PRIu64 and uint64_t
> 
> 
> why would I want to use __mingw_printf? what exactly is it? why shouldn't I
> just use printf like I think I should (end-user's prospective)? normally I 
> would
> see that and assume it's some sort of internal compiler-use thing and avoid it
> and just stick with the the standard c library or c++ library stuff.

http://sourceforge.net/apps/trac/mingw-w64/wiki/gnu%20printf

> 
> this is news to me, and I have been working with mingw-w64 for a few years
> now - lost count. new feature?

I think that's an old problem.

Regards

Kai 


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] format check broken

[Koehne Kai]

> -Original Message-
> From: Jim Michaels [mailto:jmich...@yahoo.com]
> Sent: Monday, May 06, 2013 9:12 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] format check broken
> 
>  what is %lldb? never heard of it. I don't see it in the gcc manual.

lldb is the debugger of the llvm project: http://lldb.llvm.org/ , which 
reportedly actually can debug gcc binaries.

Anyhow, in this context it was just a typo :) I of course meant %lld . See also 
my second mail.

Regards

Kai


--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] format check broken

[Koehne Kai]

> -Original Message-
> From: Koehne Kai [mailto:kai.koe...@digia.com]
> Sent: Friday, May 03, 2013 2:29 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] format check broken
> 
> 
> 
> > -Original Message-
> > From: Ozkan Sezer [mailto:seze...@gmail.com]
> > Sent: Friday, May 03, 2013 2:12 PM
> > To: mingw-w64-public@lists.sourceforge.net
> > Subject: Re: [Mingw-w64-public] format check broken
> >
> > [...]
> > Even then, it affects libstdc++ compilation itself. IMO, mingw[-w64]
> > should not default to __USE_MINGW_ANSI_STDIO=1 by itself and leave
> the
> > decision to user (which is what we already do at present.)
> 
> Since all newer versions of MSVC runtimes support e.g. %lldb 

I mean %lld, of course. Actually I am compiling lldb in the background, but for 
entirely different reasons ...

>  I think having
> an ANSI compliant default would make IMO even more sense.
> 
> Anyhow, isn't the problem that gcc on windows still defaults to win_printf?

It's called ms_printf.

:)

> So even if your printf supports %lldb, it'll warn about it?


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] format check broken

[Koehne Kai]

> -Original Message-
> From: Ozkan Sezer [mailto:seze...@gmail.com]
> Sent: Friday, May 03, 2013 2:12 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] format check broken
> 
> [...]
> Even then, it affects libstdc++ compilation itself. IMO, mingw[-w64] should
> not default to __USE_MINGW_ANSI_STDIO=1 by itself and leave the
> decision to user (which is what we already do at present.)

Since all newer versions of MSVC runtimes support e.g. %lldb  I think having an 
ANSI compliant default would make IMO even more sense.

Anyhow, isn't the problem that gcc on windows still defaults to win_printf? So 
even if your printf supports %lldb, it'll warn about it?

Regards

Kai 

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] i686-w64-mingw32-clang-3.2-release-win32_rubenvb package missing dependencies?

[Koehne Kai]

Hi Ruben,

Just downloaded 

http://sourceforge.net/projects/mingw-w64/files/Toolchains targetting 
Win32/Personal 
Builds/rubenvb/clang-3.2-release/i686-w64-mingw32-clang-3.2-release-win32_rubenvb.7z

Anyhow, launching "bin\clang" after unpacking fails because of missing 
LIBGCC_S_DW2-1.dll, LIBSTDC++-6.dll files. I then copied over these files from 
one of your gcc builds (i686-w64-mingw32-gcc-dw2-4.8.0-win32_rubenvb.7z) , but 
then clang crashes in the libs, so they do not seem to be compatible.

Any hint on where to get compatible libs? Is the clang package meant to be used 
in a certain environment?

Regards

Kai

--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Interest] Not getting large file support when configuring Qt 4.8.4 for win32-g++-4.6

[Koehne Kai]

> -Original Message-
> From: K. Frank [mailto:kfrank2...@gmail.com]


[...]
> > Is there some sort of log? Hard to tell what configure did to test
> > without it.
> 
> First, I don't know whether configure does a test.  I saw some online
> comments that suggest it does, but nothing definitive.
> 
> Second, I don't see anything that looks like a log of tests run by configure.
> (But I certainly don't know where to look.)

Run configure with -v option to see the configure log. Anyhow, there's indeed
No compile time check... configure.exe in qt4 just sets it to 'NO'.

Actually the configure option is new in 4.8.4, and a backport from qt 5.0 :

https://codereview.qt-project.org/#change,27591

Unfortunately the following fix for the multiple defines issue wasn't 
backported:

https://codereview.qt-project.org/#change,29140

I uploaded

https://codereview.qt-project.org/53769

to fix it in the next qt 4.8 release.

So ... LFS is enabled with 4.8.4 on MinGW by default, and the configure output 
is just plain wrong. Just ignore it.

Regards

Kai

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Performance changes when switching to 4.8.0

[Koehne Kai]

> -Original Message-
> From: Etienne Sandré-Chardonnal [mailto:etienne.san...@m4x.org]
> Sent: Wednesday, March 27, 2013 3:43 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Performance changes when switching to
> 4.8.0
> 
> I'm using the rubenvb with no "dw2" in the archive name, so I suppose I'm
> using SJLJ in 32bit and SEH in 64bit?

I guess so.

> Can there be a 30% speed difference just due to SJLJ, even if I do not use any
> exception handling in my code? 

Yes, actually I had measured about 25% slow down e.g. in creator startup, and 
for the test case in the bug report it's even 300%.

The jumps implementing SJLJ are automatically added to any code block that 
_might_ throw, or propagate, an exception. So you don't have to have any try {} 
catch {} blocks to get the slowdown, I understood.

> Other libs may use exceptions, but my app is
> running my code 99% of the time, as libs are only used for GUI and during
> initialization.

Well, it's enough if you're using e.g. QtCore, which is compiled with exception 
handling enabled. Only if you do -fno-exceptions for all libs you should be on 
the safe side, performance wise.

> What do I risk with dw2? I've read the main guidelines, but my understanding
> of exception handling and stack frame unwinding is too short to understand
> if this will impact my work.

There are problems (crashes) with dwarf as soon as you actually use exceptions, 
and you want them to propagate to stacks not compiled with the same compiler. 
Also Jonathan Liu reported issues with LoadLibrary/FreeLibrary, see 
http://qt-project.org/wiki/MinGW-64-bit .

Anyway, we plan to switch to a dwarf toolchain for official Qt packages with 
5.1 onwards.

Regards

Kai


--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Performance changes when switching to 4.8.0

[Koehne Kai]

> -Original Message-
> From: Etienne Sandré-Chardonnal [mailto:etienne.san...@m4x.org]
> Sent: Wednesday, March 27, 2013 3:12 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] Performance changes when switching to 4.8.0
> 
> Dear all,
> 
> Until a few days ago, I was using:
>  - Old mingw32 shipped with Qt (gcc 4.4.0) for 32bit builds
>  - Mingw-w64 x86_64 rubenvb build (gcc 4.7.1)
> 
> My code (an intensive calculation) was running at similar speed with 32-bit
> and 64-bit build (speed index : 510-520, only a few % difference between
> both)
> 
> I just switched to 4.8.0 rubenvb builds for both 32bit and 64bit builds

> Here are the results:
>  - 32bits : speed index around 420 (strong decrease)
>  - 64bits : speed index around 630 (Wow! That's a good surprise!)
> 
> Besides the fact that 4.8.0 has fantastic performances in 64bit (now it beats
> MSVC fingers in the nose), do you have an idea why the 32bit build is
> significantly slower?


Are you using sjlj or dw2 as exception handling for 32 bit? It's a known issue 
that the sjlj exception handling model has much worse performance, see also 
https://bugreports.qt-project.org/browse/QTBUG-29653 . 

Give  gcc-4.8-dw2-release/ a try.

Regards

Kai

--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] SJLJ vs DW2 - fact checking

[Koehne Kai]

> -Original Message-
> From: Kai Tietz [mailto:ktiet...@googlemail.com]
> Sent: Tuesday, February 26, 2013 11:00 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] SJLJ vs DW2 - fact checking
> 
> Hello Kai,
> 
> 2013/2/26 Koehne Kai :
> > Hi there,
> >
> > For Qt 5.0 we've been packaging a 32bit mingw-builds toolchain with SJLJ
> exception handling. However, it now became clear that the performance
> penalty for SJLJ is quite heavy (e.g. 25% for startup of a medium-sized
> application, up to 3x slow down for a small test application, see also
> https://bugreports.qt-project.org/browse/QTBUG-29653 ). I'm therefore
> inclined to recommend a switch to a DW2 based version for Qt 5.1.
> 
> Hmm, it is true that SjLj is slower as table-based unwind-information.
>  That mainly caused by the need of actual executing code for it, even if
> exception wasn't thrown.  So I am bit curious why there is a penalty of 25%
> on startup.  An average execution-penalty of 5-10% I might could
> understand.  Could you describe in more detail what "startup" actual means?

Hi Kai :)

As described in the other mail the startup times are the time between the first 
debugger log entry, and the last entry, when starting qt creator 2.6.2 with

C:\> bin\qt-creator -profile -settingspath some-inexisting-dir

What happens during startup that around 75 .dlls (Qt dlls and creator plugins) 
are loaded. Every plugin also initializes itself by e.g. checking for settings 
on the filesystem, creating objects etc. 

There's some variation in the results, probably due to file system access times 
/ other processes kicking in, but even the slowest startup time measured for 
the dw2 based creator (1,301 ms) was still faster  than the fastest startup for 
the sjlj compiled creator (1,493 ms).

I'm open to trying other benchmarks if anyone has an idea :)

Regards

Kai

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] SJLJ vs DW2 - fact checking

[Koehne Kai]

> -Original Message-
> From: Ruben Van Boxem [mailto:vanboxem.ru...@gmail.com]
> Sent: Tuesday, February 26, 2013 10:01 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] SJLJ vs DW2 - fact checking
> 
> 2013/2/26 Koehne Kai 
> 
> 
>   Hi there,
> 
>   For Qt 5.0 we've been packaging a 32bit mingw-builds toolchain with
> SJLJ exception handling. However, it now became clear that the performance
> penalty for SJLJ is quite heavy (e.g. 25% for startup of a medium-sized
> application, up to 3x slow down for a small test application, see also
> https://bugreports.qt-project.org/browse/QTBUG-29653 ). I'm therefore
> inclined to recommend a switch to a DW2 based version for Qt 5.1.
> 
>   There's lots of bits and pieces about DW2 vs SJLJ  exception handling
> on the web, but I'd like to check with you whether I got the following facts
> right:
> 
>- SJLJ incurs a performance penalty even when no exceptions are
> thrown at runtime. The penalty is >10% for typical applications.
>- DW2 potentially generates bigger libraries. The overhead however
> is not big (< 10%) for typical applications.

Actually I had a second look on this. It seems that the differences in size are 
minor for code that is compiled with exceptions enabled. However, for libs that 
are compiled with -fno-exceptions the size of the dw2 toolchain is somewhat 
bigger than the same code compiled with sjlj. E.g. when compiling Qt5Core 
without exceptions the size of the dll with the sjlj toolchain is 3,342 MB, vs 
3,826 MB with DW2. With exceptions enabled, the size is 4,164MB (sjlj) vs 
4,125MB (dw2).

>- if using DW2, things will go wrong (crashing?) if one tries to throw
> exceptions through stack frames not compiled with DW2 (typical case:
> Windows callbacks).
>   - following from the above, one should never mix code compiled
> with DW2, and code compiled with SJLJ, in one project.
>- mingw.org has switched to DW2 since a while.
>- For gcc 4.7/64 bit, only SJLJ is available. gcc 4.8 will feature SEH,
> which solves the performance problems SJLJ has. Anyhow, gcc 4.8 most
> probably won't feature SEH for 32 bit.
> 
>   Anything I missed?
> 
> 
> 
> This is pretty complete. It is also the first time I saw figures that high in 
> the
> disadvantage of SJLJ EH. The testcase is weird though: turning off exceptions
> (compiling with -fno-exceptions) should remove all EH code and related
> slowdowns if I'm not mistaken... 

The slowdown of the benchmark stems from Qt5Core, which is compiled with 
exceptions enabled by default. If I manually disable exceptions in QtCore 'by 
hand' (commenting out CONFIG+=exceptions in qtcore.pro), the benchmark 
differences go down from 300% slowdown to about 10 % . That is, there's no easy 
way for applications to fix this.

> There is a high lack of profiling in this
> discussion about performance. There are literally tens of other things that
> might be affecting performance. To name one thing, the different mingw-
> builds version used in the comparison. 

Fair enough. I now did the same tests (running the benchmark attached to the 
bug report + profiling creator startup times) with both 
x32-4.7.2-release-posix-dwarf-rev8.7z and x32-4.7.2-release-posix-sjlj-rev8.7z 
, with almost the same results. I tried to really use the same configuration on 
both tests, did a release build etc. I might still of course screwed it 
somewow, so it would be cool  to have numbers from other tests/people, too :)

Just for the record, here's the configuration I used:

Compiled ICU-49, Qt-5.1 (without webkit), configure line for Qt 5: 'configure 
-opensource -confirm-license -nomake examples -nomake tests -debug-and-release 
-release'
Compiled both creator (2.6.2) and benchmark with 'qmake -r CONFIG+=release'.

The creator startup times are a median of 10 different runs with

'start /high bin\qtcreator -profile -settingspath D:\inexistingdir'

And checking for the time span between the first debug message, and the last 
message, in windows debugger log (dbgview).

Regards

Kai
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] SJLJ vs DW2 - fact checking

[Koehne Kai]

Hi there,

For Qt 5.0 we've been packaging a 32bit mingw-builds toolchain with SJLJ 
exception handling. However, it now became clear that the performance penalty 
for SJLJ is quite heavy (e.g. 25% for startup of a medium-sized application, up 
to 3x slow down for a small test application, see also 
https://bugreports.qt-project.org/browse/QTBUG-29653 ). I'm therefore inclined 
to recommend a switch to a DW2 based version for Qt 5.1.

There's lots of bits and pieces about DW2 vs SJLJ  exception handling on the 
web, but I'd like to check with you whether I got the following facts right:

 - SJLJ incurs a performance penalty even when no exceptions are thrown at 
runtime. The penalty is >10% for typical applications.
 - DW2 potentially generates bigger libraries. The overhead however is not big 
(< 10%) for typical applications.
 - if using DW2, things will go wrong (crashing?) if one tries to throw 
exceptions through stack frames not compiled with DW2 (typical case: Windows 
callbacks).
- following from the above, one should never mix code compiled with DW2, 
and code compiled with SJLJ, in one project.
 - mingw.org has switched to DW2 since a while.
 - For gcc 4.7/64 bit, only SJLJ is available. gcc 4.8 will feature SEH, which 
solves the performance problems SJLJ has. Anyhow, gcc 4.8 most probably won't 
feature SEH for 32 bit.

Anything I missed?

Thanks

Kai

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingwbuilds-users] Qt 5.0.1 binary packages with MinGW-builds toolchain

[Koehne Kai]

> Subject: Re: [Mingwbuilds-users] Qt 5.0.1 binary packages with MinGW-builds   
>   toolchain
>
> 2013/1/31 Koehne Kai:
>> E.g. the msvc package doesn't ship a toolchain. But that's just 271 MB of 
>> the 405 MB difference. It seems most of > the difference is actually in the 
>> debugging info: E.g. Qt5Guid.dll for MinGW is a 131 MB big, while MSVC 
>> Qt5Guid.dll + Qt5Guid.pdb is just 24 MB.
>
> Strange that Qt builds made by Alexey within the Qt-builds project,
> have almost twice the smaller size of archive.
> Its builds contain also debug & release builds:
> http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/Qt-Builds/
>
> I don't understand why your archive turned out such huge... Or your
> installer doesn't compress files?

It's using 7z archives too, so that shouldn't make a difference. However, 
Alexey's package is just the barebone Qt binaries - the official installer also 
ships the Qt sources, Qt Creator, the Qt documentation, and the actual 
MinGW-builds toolchain.

Regards

Kai

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingwbuilds-users] Qt 5.0.1 binary packages with MinGW-builds toolchain

[Koehne Kai]

> -Original Message-
> From: niXman [mailto:i.nix...@gmail.com]
> Sent: Thursday, January 31, 2013 3:48 PM
> To: Koehne Kai; Mingw-w64-public@lists.sourceforge.net; mingwbuilds-
> us...@lists.sourceforge.net
> Subject: Re: [Mingwbuilds-users] Qt 5.0.1 binary packages with MinGW-
> builds toolchain
> 
> 2013/1/31 Koehne Kai:
> > Hi there,
> >
> > The qt-project and Digia just released Qt 5.0.1 binary installer for MinGW!
> >
> > http://blog.qt.digia.com/blog/2013/01/31/qt-5-0-1-released/
> >
> > The binary is compiled with and comes with the x32-4.7.2-release-posix-
> sjlj-rev8.7z toolchain from MinGW-builds. Quite a lot of you have been
> helping to get this going, so thanks a lot and be proud :)
> Tell me please, why the 64-bit build is missing?

No special reason apart from the fact that we considered 32 bit to be more 
important. Note that we're also still missing MSVC 64 bit packages, too ... 
it's a matter of resources, both in the build & test system and when it comes 
to release testing etc. We might consider shipping a 64 bit version in an 
upcoming installer, let's see what the feedback says.

But I'm compiling locally with the 64 bit toolchain too, without any troubles.

Regards

Kai
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingwbuilds-users] Qt 5.0.1 binary packages with MinGW-builds toolchain

[Koehne Kai]

-Original Message-
> From: niXman [mailto:i.nix...@gmail.com]
> Sent: Thursday, January 31, 2013 3:05 PM
> To: Koehne Kai; mingwbuilds-us...@lists.sourceforge.net; Mingw-w64-
> pub...@lists.sourceforge.net
> Subject: Re: [Mingwbuilds-users] Qt 5.0.1 binary packages with MinGW-
> builds toolchain
> 
>[...]
>
> It is excellent!
> But tell me please, why the archive for MinGW in the size is almost twice
> more than all other builds? Is it normal?

E.g. the msvc package doesn't ship a toolchain. But that's just 271 MB of the 
405 MB difference. It seems most of the difference is actually in the debugging 
info: E.g. Qt5Guid.dll for MinGW is a 131 MB big, while MSVC Qt5Guid.dll + 
Qt5Guid.pdb is just 24 MB.

Don't know whether the size of debugging info can  be reduced somehow?

Regards

Kai

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Qt 5.0.1 binary packages with MinGW-builds toolchain

[Koehne Kai]

Hi there,

The qt-project and Digia just released Qt 5.0.1 binary installer for MinGW!

http://blog.qt.digia.com/blog/2013/01/31/qt-5-0-1-released/

The binary is compiled with and comes with the 
x32-4.7.2-release-posix-sjlj-rev8.7z toolchain from MinGW-builds. Quite a lot 
of you have been helping to get this going, so thanks a lot and be proud :)

You rock

Kai



--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Qt wiki

[Koehne Kai]

Hi guys,

Thanks for the lively discussion! In the end we (Qt 5.0.1 release team) decided 
to stick with the 'posix' (libwinpthread) toolchain: There's obviously no 
consensus what do use in the community here, and I personally don't have enough 
insight to make a really 'informed' decision.

If we get bug reports etc there's still the option to switch in later versions 
...

Regards

Kai

PS: I think it would be help adaptation of the project a lot if things like 
posix vs win32 threading, and sjlj vs dw2 exception handling (preferably even 
with an advice what to use by default) would be documented somewhere within the 
mingw-w64 project site. 

> -Original Message-
> From: K. Frank [mailto:kfrank2...@gmail.com]
> Sent: Monday, January 21, 2013 3:50 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Qt wiki
> 
> Hello niXman!
> 
> I agree with what you are saying.
> 
> On Mon, Jan 21, 2013 at 9:27 AM, niXman  wrote:
> >> On top of that, Qt already caters for all the C++11 multithreading classes:
> >> QThread, QMutex, etc... all exist and are probably the ones used in
> >> Qt projects. I'll leave the final decision up to you, but for
> >> stability's sake I'd suggest using plain win32 threading (Qt is used
> >> by a lot of people and it'd suck for people to have a bad MinGW-w64
> experience with it).
> >
> > You say this as if those who use Qt, do not use C++11 and its
> > 'threading support'.
> > I know that winpthreads has some bugs, иut this does not mean that you
> > can not use winpthreads. The less MinGW users will use builds with
> > winpthreads, the fewer bugs will be found and even fewer corrected. If
> > your words said above serve to this purpose, I...hmmm...better say
> > nothing.. =)
> 
> From my perspective, I want to use c++11 / std::thread with Qt, and I am,
> using Ruben's std::thread
> 
> > Kai, I would not recommend to use win32-threads builds, because so the
> > full support for 'C++11 threads support library' will appear only
> > after several years.
> > About the current support for 'C++11 threads support library' in MinGW
> > we can not say that it does not exist or it is not working. It exists,
> > and it works. And I think it works quite well.
> 
> I have not succeeded in breaking mingw-w64's std::thread (based on
> winpthreads) support.  I have run basic tests that cover all of the standard
> facilities (mutexes, condition variables, joins, futures, throwing exceptions
> across futures).  I'm not saying it's perfect or has no bugs, but I haven't 
> found
> any yet.
> 
> > P.S.
> > the discussed above was about the overhead created by winpthreads.
> > on my own behalf, I would say that this overhead is so insignificant
> > that it is ridiculous to discuss it =)
> 
> From the std::thread perspective, I have identified some overhead caused
> by implementing std::thread on top of winpthreads relative to implementing
> it directly on top of win32, but it is not excessive.
> Also, Kai's winpthreads implementation also outperforms certain facets of
> the native implementation.
> 
> Obviously giving users a "broken" Qt / mingw-w64 experience because of
> winpthreads would be a bad idea.  But it works for me.  And I agree with
> niXman that if things are working reasonably well (I think they are.), then
> encouraging people to go the winpthreads route will only server to
> strengthen winpthreads.
> 
> > Regards,
> > niXman
> 
> 
> Best.
> 
> 
> Frank R. Brown
> 
> --
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC,
> Windows 8 Apps, JavaScript and much more. Keep your skills current with
> LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and
> experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Qt wiki

[Koehne Kai]

> -Original Message-
> From: Suresh Govindachar [mailto:sgovindac...@yahoo.com]
> Sent: Sunday, January 20, 2013 11:15 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Qt wiki
> 
> [...]
>My questions:
> 
>A) Can one go through the "getting started examples" such as
>qt_quick_app_dev_intro_src.zip, canvasexample_src.zip and
>notezapp_src.zip (with associated learning guides:
>QtQuickAppDevIntro.pdf, QtQuickCanvasTutorial.pdf and
>QtQuickApplicationGuide4Desktop.pdf) found on
>http://qt-project.org/wiki/developer-guides using AlexPux's
>prebuilt SDK?
> 
>B) Also, although I was able to use google to find the pdfs for
>the above examples, the links on the qt-project.org page for these
>pdfs are broken.  Does the non-functioning of the links to the
>pdfs mean that these are old examples that might not be applicable
>to Qt 5.x, and that there are better examples for learning Qt
>starting with Qt 5.x?

Not sure about the pdf's . What definitely be up to date is the Getting Started 
guides on http://qt-project.org/doc/qt-5.0/qtdoc/gettingstarted.html

Regards

Kai

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Qt wiki

[Koehne Kai]

> -Original Message-
> From: Алексей Павлов [mailto:alex...@gmail.com]
> Sent: Monday, January 21, 2013 9:55 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Qt wiki
> 
> Hi, Kai!
> Does the issue reported on https://bugreports.qt-
> project.org/browse/QTBUG-28845 is closed?

Well, technically it's still 'not evaluated' :)

I never had that problem personally before, nor did it occur in the CI system. 
But then again I'm using jom, maybe it's a jom vs mingw32-make difference ... 
will try later on with mingw32-make.

> And I have one patch that not in release branch yet:
> 
> --- a/qtwebkit/Tools/qmake/mkspecs/features/default_pre.prf.orig 2013-
> 01-11 14:18:00 +0300
> +++ b/qtwebkit/Tools/qmake/mkspecs/features/default_pre.prf 2013-01-11
> +++ 14:18:07 +0300
> @@ -21,6 +21,9 @@
>  WEBKIT_SUBDIR = $$replace(_PRO_FILE_PWD_, $${ROOT_WEBKIT_DIR},)
> ROOT_BUILD_DIR = $$replace(OUT_PWD, $${WEBKIT_SUBDIR}$,)
> 
> +# Make sure we process the PKGCONFIG variable if applicable
> +!mac: CONFIG += link_pkgconfig
> +
>  # Now we're ready to load default_pre from Qt
>  load(default_pre)

Can you elaborate what that fixes + is there a bugreport for it? Note that 
we're pretty near the 5.0.1 release (which will include pre-built MinGW 
packages + Mingw-builds toolchain), so if we want still something fixed we've 
to hurry up ...

Regards

Kai 


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Qt wiki

[Koehne Kai]

> -Original Message-
> From: Koehne Kai [mailto:kai.koe...@digia.com]
> Sent: Monday, January 21, 2013 9:30 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Qt wiki
> 
> 
> 
> Actually all that should be needed for latest qt5/release branch (upcoming
> 5.0.1) is the toolchain + ICU and openssl dlls, which you can get e.g. from
> http://origin.releases.qt-project.org/prebuilt/mingw_32/ .

Alright, I guess I forgot to mention Python, Perl, Ruby + ICU and OpenSSL 
headers , and optionally the DirectX SDK :)

The point I was trying to make was: You shouldn't need any patches for Qt 
itself anymore.

Regards

Kai 

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Qt wiki

[Koehne Kai]

> -Original Message-
> From: Ruben Van Boxem [mailto:vanboxem.ru...@gmail.com]
> Sent: Saturday, January 19, 2013 9:27 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] Qt wiki
> 
> Hi,

Hi Ruben & others,

Thanks for the fixes to the wiki!
 
> I have updated the Qt wiki on MinGW-w64:
> http://qt-project.org/wiki/MinGW-64-bit
> 
> 
> It has a nice explanation (which was *wrong* on many accounts until now) of
> various "stuff".
>
> I'm attempting to build the prereqs now, I might upload them when I
> succeed.

Actually all that should be needed for latest qt5/release branch (upcoming 
5.0.1) is the toolchain + ICU and openssl dlls, which you can get e.g. from 
http://origin.releases.qt-project.org/prebuilt/mingw_32/ .

> 
> Also: it seems the Qt Project chose for "posix" threading for all the wrong
> reasons in their own release to public installers, and has no idea of the
> possible performance impact. It will be positive to get winpthreads and posix
> threading out in the wild though :-)

The section of posix vs win32 threading was just what I found out on the web 
after googling for 10 minutes ;) We just had to settle for one. If there's 
consensus that win32 threading is preferred by more people we can  switch to it 
e.g. for Qt 5.1 ...

Regards

Kai

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] abort() crashing for -Wl,-subsystem,windows

[Koehne Kai]

> -Original Message-
> From: Kai Tietz [mailto:ktiet...@googlemail.com]
> Sent: Wednesday, January 16, 2013 5:50 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] abort() crashing for -Wl,-
> subsystem,windows
> 
> Hi,
> 
> I just tested your report with my toolchain - I am using 4.8 with mingw-w64's
> trunk version- and I have to admit that I don't see any of those issues on my
> Windows 8 box.
>
> So first question is, what compiler-version, what mingw-w64 version you are
> using?

Sorry, should have included this information in the first place. I can 
reproduce this with different toolchains based on gcc 4.7 (e.g. Mingw-builds 
x32-4.7.2-release-posix-sjlj-rev1.7z, Mingw-builds  
x64-4.7.2-release-posix-sjlj-rev1.7z, 
i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb.7z). I now also tried 
i686-w64-mingw32-gcc-4.8-unstable-win32_rubenvb.7z and actually a stone-age gcc 
4.4.0 from MinGW.org ... same behavior. 

Maybe it's really something on my machine (Windows 7 64 bit, though I just 
reinstalled it two weeks ago) ... Pretty mysterious.

> 
> Kai
> 
> 
> 2013/1/16 Koehne Kai :
> > Hi,
> >
> > Take following program:
> >
> > ---
> > #include 
> >
> > int main(int, char**)
> > {
> > abort();
> > return 0;
> > }
> > ---
> >
> > Compiling it with "g++ -o test.exe test.cpp" and running it will print 
> > (both in
> a pop up and in a dialog):
> >
> > "
> > This application has requested the Runtime to terminate it in an unusual
> way.
> > Please contact the application's support team for more information.
> > "
> >
> > However, if you link with "-Wl,-subsystem,windows" , after showing the
> > above in a dialog the application will crash (extra dialog "test.exe
> > has stopped working"), and the windows debugger log contains
> >
> > [1464] Invalid parameter passed to C runtime function.
> >
> >
> > So it seems that somehow things go wrong in the crash handler. Any idea
> where and whether it has been reported before? Especially the "Invalid
> parameter' warning is somewhat misleading, and sounds like a bug ...
> >
> >
> >
> > Regards
> >
> > Kai
> >
> > PS: Googling for it turns out a number of similar reports, e.g.
> > http://stackoverflow.com/questions/13893122/q-assert-has-different-beh
> > avior-when-my-project-is-built-in-visual-studio-vs-qt ,
> >
> > --
> >  Master Java SE, Java EE, Eclipse, Spring, Hibernate,
> > JavaScript, jQuery and much more. Keep your Java skills current with
> > LearnJavaNow -
> > 200+ hours of step-by-step video tutorials by Java experts.
> > SALE $49.99 this month only -- learn more at:
> > http://p.sf.net/sfu/learnmore_122612
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> 
> 
> 
> --
> |  (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
> 
> --
> Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and
> much more. Keep your Java skills current with LearnJavaNow -
> 200+ hours of step-by-step video tutorials by Java experts.
> SALE $49.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122612
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] abort() crashing for -Wl,-subsystem,windows

[Koehne Kai]

Hi,

Take following program:

---
#include 

int main(int, char**)
{
abort();
return 0;
}
---

Compiling it with "g++ -o test.exe test.cpp" and running it will print (both in 
a pop up and in a dialog):

"
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
"

However, if you link with "-Wl,-subsystem,windows" , after showing the above in 
a dialog the application will crash (extra dialog "test.exe has stopped 
working"), and the windows debugger log contains

[1464] Invalid parameter passed to C runtime function.


So it seems that somehow things go wrong in the crash handler. Any idea where 
and whether it has been reported before? Especially the "Invalid parameter' 
warning is somewhat misleading, and sounds like a bug ... 



Regards

Kai

PS: Googling for it turns out a number of similar reports, e.g. 
http://stackoverflow.com/questions/13893122/q-assert-has-different-behavior-when-my-project-is-built-in-visual-studio-vs-qt
 , 

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] New-B

[Koehne Kai]

> -Original Message-
> From: ext Arbol One [mailto:arbol...@hotmail.ca]
> Sent: Tuesday, January 15, 2013 5:24 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] New-B
> 
> Humm, some how I felt that there was something very wrong in my
> installation. All I want from the compiler is to debug using 32-bit, and then
> create a final built in 64-bit. I not interested in cross compiling, it is 
> just that I
> want to deploy under 64-bit Windows 7/8.

Just to get this straight:
- "cross compiling" in this context means that you're using a 32 bit toolchain 
to generate a 64 bit binary, or the other way round.
- You can deploy 32 bit binaries on 64 bit Windows 7 / 8. This is done by an 
emulation layer called WoW (Windows on Windows), but really works without any 
hassles. Just check out "C:\Program Files (x86)", all apps here should be 32 
bit ! It doesn't work the other way round though, 64 bit binaries can't run on 
a 32 bit Windows.
- That said, there are of course applications that benefit from using 64 bit 
(e.g. using a lot of memory, kernel tools etc...)

> Please, could you tell me which MinGW-64 flavour I should download in
> order to this?

I'd personally avoid the cross-compiler hassle, and use a native 32 bit 
toolchain. If you then decide you really want a 64 bit binary, just install a 
64 bit toolchain alongside and recompile your project ... That said, at least 
TDM-GCC supports generating  too.

Regards

Kai

> TIA
> 
> From: Ruben Van Boxem 
> Sent: Tuesday, January 15, 2013 10:40 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] New-B
> 
> 2013/1/15 Arbol One 
> 
> 
>   I hope someone is willing to reply to my question, even though they
> sound not very smart, the truth is that I am trying to understand the
> different aspects of MinGW64, I am really confused about how it works.
> 
> 
>   Thanks in advance
> 
>   From: Arbol One 
>   Sent: Tuesday, January 15, 2013 9:25 AM
>   To: mingw-w64-public@lists.sourceforge.net
>   Subject: Re: [Mingw-w64-public] New-B
> 
>   D:\MinGW64
>  +bin
> -i686-w64-mingw32-g++.exe
>  +i686-w64-mingw32
> +bin
>-g++.exe
>   
>   What is the difference between './bin/i686-w64-mingw32-g++.exe'
> and './i686-w64-mingw32/bin/g++.exe'? What are they used for?
> 
> 
> My toolchains do not have the second variation (last time I checked, I could
> very well be wrong though). What file did you download?
> 
> 
> It seems you downloaded a toolchain built as a cross-compiler. The prefix
> i686... means it targets 32-bit Windows. A prefix of x86_64... means it 
> targets
> 64-bit. If you don't want prefixed executables, download a native compiler.
> For my toolchains, this means using files with names of the form i686...win32
> and x86_64win64.
> 
> 
> If you know how GCC works on Unix, all you should know to use MinGW-w64
> toolchains is that you need to add the toplevel "bin" directory to PATH and
> call the compiler executables as you would on Unix.
> 
> 
> Ruben
> 
> 
> 
> 
>   TIA
> 
>   From: Ruben Van Boxem 
>   Sent: Tuesday, January 15, 2013 9:13 AM
>   To: mingw-w64-public@lists.sourceforge.net
>   Subject: Re: [Mingw-w64-public] New-B
> 
>   2013/1/15 Arbol One 
> 
> 
>   In the‘/MinGW64’ folder I have  ‘./lib’,  ‘/bin’ and ‘./include’
> subdirectories, am I to assume that this are the 32-bit files while their 
> 64-bit
> counterparts are in the ‘./i686-w64-mingw32’ directory?
> 
> 
>   No. Depending on what exactly you downloaded (filename of the file
> you got suffices), some stuff will be located in different places.
> 
>   I'm assuming you have downloaded a 32-bit native non-multilib
> toolchain, then this is the general structure:
> 
>   mingw32/bin: directory to add to PATH. Contains all the toolchain
> executables like gcc, g++, gdb, ld, nm, etc...
> 
>   mingw32/lib and mingw32/include: GCC search paths, ignore them.
> 
>   mingw32/i686-w64-mingw32/include and lib: these are the MinGW-
> w64 headers and import libraries (the stuff built from the source you first
> downloaded). These include some C headers and standard Win32 API
> headers like windows.h
> 
> 
>   Ruben
> 
> 
> 
> 
> 
>   TIA
> 
>   From: Ruben Van Boxem
> 
>   Sent: Tuesday, January 15, 2013 7:18 AM
>   To: mingw-w64-public@lists.sourceforge.net
>   Subject: Re: [Mingw-w64-public] New-B
> 
>   2013/1/15 Arbol One 
> 
> 
>   Hello there!
>   I just downloaded and unpacked mingw-w64-v1.0.7.
> in my D: directory, what else do I have to do now? is there a tutorial
> explaining what has to be added to the path and what is the toolchai

Re: [Mingw-w64-public] x86_64-w64-mingw32-g++.exe links with 32 bit libs

[Koehne Kai]

> -Original Message-
> From: ext JonY [mailto:jo...@users.sourceforge.net]
> Sent: Saturday, November 17, 2012 12:23 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] x86_64-w64-mingw32-g++.exe links with
> 32 bit libs
> 
> On 11/17/2012 19:17, deneme.true wrote:
> > Hello,
> >
> > I am trying to cross-compile wxWidgets library on 32 bit machine for
> > Win64. I haven't a 64 bit machine and 64 bit OS. I've seen that linker
> > links the object files with 32 bit
> > libraries(kernel32.lib,advapi32,wsock32,gdi32 etc.) Isn't it suppose
> > to link with 64 bit libraries(kernel64.lib,advapi64,wsock64,gdi64
> > etc.) instead of 32 bit libraries? Does linker make valid 64 bit
> > library with linking with 32 bit libraries?
> 
> 32 in the name does not mean 32bit, they are still named similarly for 64bit.
> You'll have to ask MS why they named it that way.

Compatiblity reasons :) See also 
http://stackoverflow.com/questions/949959/why-do-64-bit-dlls-go-to-system32-and-32-bit-dlls-to-syswow64-on-64-bit-windows

Regards

Kai


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] incorrect syntax while building QT 4.8.3

[Koehne Kai]

> -Original Message-
> From: ext CanisMajorWuff [mailto:canismajorw...@gmail.com]
> Sent: Friday, November 02, 2012 6:49 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] incorrect syntax while building QT 4.8.3
> 
> Hello!
>>
> I have troubles building QT 4.8.3.
> I configure QT using this command.
>
> configure -platform win32-g++ -opensource

Maybe you should try win32-g++-4.6 (that is, if you're using gcc>=4.6 , which 
is most likely the case if you're using mingw-w64).

> 
> After that I execute
> 
> mingw32-make
>
> As a result I get this
> 
> D:/qt/4.8.3/bin/moc.exe -DQT_SHARED -DQT_THREAD_SUPPORT -
> DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_CORE_LIB -DQT
> _NO_USING_NAMESPACE -DQT_MAKEDLL -DQT_ASCII_CAST_WARNINGS -
> DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -
> D_USE_MATH_DEFINES -DQLIBRARYINFO_EPOCROOT -
> DHB_EXPORT=Q_CORE_EXPORT -DQT_DLL -DQT_HAVE_MMX -
> DQT_HAVE_SSE -DQT_HA VE_MMXEXT -DQT_HAVE_SSE2 -I'../../include' -
> I'../../include/QtCore'
> -I'tmp/rcc/debug_shared' -I'tmp' -I'global' - I'../../tools/shared' -
> I'../3rdparty/zlib' -I'../3rdparty/harfbuzz/src'
> -I'../3rdparty/md5' -I'../3rdparty/md4' - I'../../include/ActiveQt' -
> I'tmp/moc/debug_shared'
> -I'../../mkspecs/win32-g++-4.6' -D__GNUC__ -DWIN32 animation/q
> abstractanimation.h -o

Is there really a space between q and abstractandimation.h?

> tmp/moc/debug_shared/moc_qabstractanimation.cpp
> The syntax of the command is incorrect.

This seems to be a windows command line error, so my guess is it's not a MinGW 
error, but a Qt one (if at all). 

Regards

Kai

> mingw32-make[2]: *** [tmp/obj/debug_shared/qt_pch.h.gch/c++] Error 1
> mingw32-make[2]: Leaving directory `D:/qt/4.8.3/src/corelib'
> mingw32-make[1]: *** [debug-all] Error 2
> mingw32-make[1]: Leaving directory `D:/qt/4.8.3/src/corelib'
> mingw32-make: *** [sub-corelib-make_default-ordered] Error 2
> 
> --
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command
> center Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Latest binary mingw build -- from 2011 12 20?

[Koehne Kai]

> -Original Message-
> From: ext Suresh Govindachar [mailto:sgovindac...@yahoo.com]
> Sent: Thursday, October 25, 2012 2:36 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] Latest binary mingw build -- from 2011 12 20?
> 
> 
> Hello,
> 
> The latest mingw-w64 binary for mingw that I have been able to find is the
> following:
> 
>  mingw-w64-bin_i686-mingw_20111220.zip

You probably want either a package from a personal builds directories (e.g. 
rubenv's), or go for MinGW-builds or TDM-mingw (which both use mingw-w64 as a 
base, too). It's a bit unfortunate that the website still prominently features 
the automated build directory where you got the download from, since these are 
stale and not really meant for production use (that's my understanding, at 
least).

Regards

Kai

> Is there a newer build?
> 
> Thanks,
> 
> --Suresh
> 
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics Download AppDynamics Lite
> for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problem with mingw32-make and long commands (x86_64-w64-mingw32-gcc-4.7.2-release-win64_rubenvb)

[Koehne Kai]

> -Original Message-
> From: ext Ruben Van Boxem [mailto:vanboxem.ru...@gmail.com]
> Sent: Friday, September 28, 2012 11:47 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Problem with mingw32-make and long
> commands (x86_64-w64-mingw32-gcc-4.7.2-release-win64_rubenvb)
> 
> 2012/9/28 Koehne Kai 
> 
> 
>   Hi Ruben,
> 
>   I ran into an issue with your mingw32-make and a really long
> compiler line: http://pastebin.com/h5tNV7x5 . We're obviously hitting a
> buffer limit here ... However, if I replace your mingw32-make
> 
>   GNU Make 3.82
>   Built for x86_64-w64-mingw32
> 
>   With the one from latest mingw-builds:
> 
>   GNU Make 3.82.90
>   Built for x86_64-w64-mingw32
> 
>   The compilation succeeds.
> 
> 
> 
> Hi,
> 
> I know my mingw32-make builds are flawed :( I haven't been able to build it
> from cvs directly (there's cvs "dead" files that are needed by autoconf), and
> there seem to be no svn or git mirrors that are any more decent or usable.
>
> Could you please try the "official" mingw-w64 make (which is just an old cvs
> checkout with I believe upstream patches) from here:
> http://sourceforge.net/projects/mingw-
> w64/files/External%20binary%20packages%20%28Win64%20hosted%29/m
> ake/make-3.82.90-2015.zip/download

It's not only your build: Neither the one you linked to, nor the one from 
mingw-32, nor the one from latest mingw-tdm handle this gracefully. Only 
mingw-builds does .

> I have taken this source+patches since my 4.8-seh build and if this fixes the
> problem, that would be great. Otherwise I'd have to go hunting for other
> patches or a decent current snapshot of mingw32-make.
> 
> On a sidenote, I've had great success using Qt's jom.exe even for MinGW
> makefiles. It allows for unseen parallellism in a Qt build. Perhaps it is 
> worth
> looking into solidifying its MinGW makefile support in the near future. I am
> all for leaving mingw32-make behind. It's old and unnecessarily slow.

Actually I didn't know that jom is capable of using GNU makefiles at all until 
last week or so ;) But it's limited to the subset of Makefile constructs qmake 
generates. I expect that it'll break easily for other Makefiles ...

Regards

Kai

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Problem with mingw32-make and long commands (x86_64-w64-mingw32-gcc-4.7.2-release-win64_rubenvb)

[Koehne Kai]

Hi Ruben,

I ran into an issue with your mingw32-make and a really long compiler line: 
http://pastebin.com/h5tNV7x5 . We're obviously hitting a buffer limit here ... 
However, if I replace your mingw32-make 

GNU Make 3.82
Built for x86_64-w64-mingw32

With the one from latest mingw-builds:

GNU Make 3.82.90
Built for x86_64-w64-mingw32

The compilation succeeds.

Regards

Kai

--
Kai Koehne, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. 
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B 



--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Qt 5 and MinGW 64 - great progress!

[Koehne Kai]

Hi all,

I wrote a while ago that 'I haven't found a stock native MinGW 64 bit package 
yet that can compile Qt 5 + Qt Creator.' And since I get cited on this I guess 
it's time to correct it :)

Thanks to personal efforts of various people both on the Qt side (namely 
Jonathan Liu), as well as on the MinGW side I've just compiled Qt Essentials 
(including webkit) + Qt Creator with both MinGW-32, MinGW-builds (gcc 4.7.2, 
native 64), Ruben's MinGW (gcc 4.7.2 native 64) and tdm-gcc (4.7.1, native 64)! 
So thanks to all who contributed!

Regards

Kai


--
Kai Koehne, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. 
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


--
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 respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [Development] Choosing a new MinGW for Qt 5

[Koehne Kai]

> -Original Message-
> From: ext Ruben Van Boxem [mailto:vanboxem.ru...@gmail.com]
>
> [...]
> I have now rebuilt gdb with "--disable-nls" and I believe this is the thing.
> Don't ask me why this is. The startup time reduces from ~19 seconds to 6-7
> seconds, which is the same as mingw-builds gdb.
>
> Should I report a bug for this to the gdb devs? I doubt I will be able to
> describe it well enough to be helpful, nor do I think this will have a high
> priority...

I'm not an gdb expert, but I talked to one in the office ;) He tested gdb 
compiled with and without Native Language Support on Linux, and couldn't 
measure any noticeable difference in startup time. I don't know what the 
priorities are for gdb these days, but sending a bug report doesn't hurt, I'd 
say.

(Speaking from a IDE developers perspective, a tool like gdb dumping output in 
different languages is a nightmare in the first place. But there might be 
people not fluent in English who want to use gdb on the command line, of course 
...)

Btw, maybe the even longer delay K. Frank has noticed is because he's using a 
non-english system language? Just a guess ...

Regards

Kai

> Another mystery solved by your anonymous hero,
 
Great job! It probably has taken you quite some time to test different 
permutations of gdb configurations :) Thanks a lot for this...


> Ruben
> 
> 
> 
> 2012/9/12 
> 
> 
>   K. Frank wrote:
>   > >> Kai wrote:
>   > >>> [...] The only other
> 
>   > >>> difference from the log is that rubenv's gdb also prints some
> '=cmd-param-
>   > >>> changed,param="' messages, while mingw-builds does not.
>   > >>
>   > >> What log is this?  I haven't notices gdb emitting any unexpected
> messages, but
>   > >> I'd be glad to look if this might be a hint about something.
>   > >
>   > > This is from the debugger log output of Qt Creator (Window-
> >Views->Debugger Log).
>   > > Logging the exact times a command took can be enabled in the
> context menu.
>   >
>   > Okay.  I don't use Qt Creator, so I guess I don't have this log.
> 
> 
>   That's also available as "normal" GDB/MI output.
> 
>   You should get it when starting gdb with   -i mi  on the command
> line.
> 
>   Andre'
> 
>   
> --
>   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 respond.
> Discussions
>   will include endpoint security, mobile security and the latest in
> malware
>   threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>   ___
>   Mingw-w64-public mailing list
>   Mingw-w64-public@lists.sourceforge.net
>   https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> 
> 

--
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 respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public