Hello,
for years, I've used mingw-builds ([1], [2]) happily as a default gcc toolchain
of my choice
on Windows hosts. However I can see there are no new builds for many months
although
there were some gcc releases (6.1, 5.4) in the mean time. That makes me
wondering about
its current status.
Maybe we misunderstand each other?
I understood your question as a proposal to make -D_WIN32_WINNT=xy imply
also implicitly some --enable-threads=xy. That would be a problem, because
semantics of -D_WIN32_WINNT=xy should imho have no implication on chosen
run time, but just on what's made availab
I was able to find this:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-March/014130.html
It mentions June 14th, 2014.
(But of course that can be hardly seen as some authoritative source.)
M.
> massimo 2014-07-22 20:24:
>> Yes
>> http://www.google.com/patents/US5628016
>
> I can not see the
Hi,
I tried to use gcc 4.9.0 with -fsanitize=address or -fsantize=undefined.
However linker then failed, as the options imply -lasan or -lubsan
respectivelly.
Are these supposed to work in mingw-w64? If not, then perhaps the options
should fail early and tell they are not supported rather then le
Hello,
when I tried LTO (link time optiomization) the last time (gcc 4.8 or 4.7,
I do not remember precisely), it did not work much for me (frequent
crashes during my project build with LTO enabled).
I know gcc dev team spent a lot of time on improving LTO in 4.9.
So, what is LTO status in ming
Hello,
I would like to ping this:
http://sourceforge.net/p/mingw-w64/patches/67/
I understand the proposed solution is not nice but I right now I can not
see any better one.
Regards,
Martin
--
CenturyLink Cloud: The Le
I believe it is possible, but you have to explicitly tell it with the gcc
option -municode.
Martin
> I am not sure what is the status now, but couple of years ago, GCC could
> not compile programs with UNICODE version of WinMain. If it still
> persist, you will need to declare the entry point as
bably may have more experience how to
>> to push patches for binutils, or get some feedback if the patch is not
>> satisfactory for binutils standards??
>>
>>
>> [1] https://github.com/mity/mctrl/issues/13
>> [2] https://sourceware.org/ml/binutils/2013-10/msg00305.ht
Hi.
I'm using the Coverity scan [1] for static source analyzes for mCtrl
project [2] on a regular basis before each release. I've recently got some
false positives resulting from each usage of the macro InlineIsEqualGUID
from mingw-w64 system headers.
It actually results in reports similar to th
> 2013/7/22 Jacek Caban:
>
>> BTW, it should be GCC version independent, it's a matter of
>> mingw-w64-crt.
> I know that. But, in order to determine the mingw-w64-crt revision, I
> need to know the revision of the build, but TS haven't choose that.
> (for 4.8.1, there are three revisions of buil
> On 06/26/13 23:57, dw wrote:
>>> I still don't get, why we need those functions in crt.
>> The problem is that in MSVC it it perfectly legal to just copy/paste the
>> prototype for one of the intrinsics in your file and use it (see example
>> below). It is NOT necessary to include intrin.h. If
> On Jun 11 12:58, Ray Donnelly wrote:
>> I for one am hugely appreciative of all the hard work that Corinna, Kai,
>> redhat, the mingw-w64 team and also Alexey has put into both Cygwin and
>> MSYS2.
>>
>> Cygwin and MSYS2 exist for different, mutually exclusive goals. Anything
>> we
>
> I fail to
>
> You *have* to install the headers first as a prerequisite for the crt to
> work. There are generated headers required for the CRT, not a plain and
> simple -I.
Many packages generate headers or some sources. Consider config.h.in ->
config.h as the most common case. I cannot see that as a reas
Hi Ruben,
thanks for the work.
Just one point annoys me a bit: The Windows packages targeting win32 and
win64 respectively differ in prefixes of binutils, e.g.:
mingw32/bin/windres.exe vs. mingw64/bin/x86_64-w64-mingw32-windres.exe.
This complicates things for those who (like me) need/want to u
>>
>> This is nice, but far from enough. There should be clear policy who from
>> the team is responsible for release management, how often (approx.) you
>> plan to release (e.g. 2 times a year or every month), if there is any
>> public RC (and for how long before the planned final release), so
>>
> I wrote up some base information on our Wiki to describe things in
> more detail. Especially the download-section looks on the first
> glance a bit weird,
>
> Please read in our Wiki
> https://sourceforge.net/apps/trac/mingw-w64/wiki/Structure%20on%20SF%20download%20page
> for some more details
Hi all,
although I appreciate the hard work on the mingw-w64 project, I must agree
here with the voices calling for more transparent release policies. Now
it's really a pain.
I think mingw-w64 forum and mailing lists already presented a frustration
of community about this.
Consider for example t
17 matches
Mail list logo
