Op do 27 aug. 2020 om 07:18 schreef Vincent Torri :
> On Thu, Aug 27, 2020 at 3:24 AM Liu Hao wrote:
> >
> > 在 2020/8/27 上午2:06, Vincent Torri 写道:
> > >
> > > i've checked in cmd too, same result
> > >
> > > But there is anyway something strange to me :
> > >
> > > myprog_gcc.exe and myprog_vs ar
Op vr 24 jan. 2020 00:30 schreef David Mathog :
> On 2020-01-23 15:08, David Grayson wrote:
> > Since CMake in MSYS2 is a native Windows program, if you ask it to make
> > /tmp, I expect it will make C:/tmp. Did that happen?
>
> Good call, that is exactly what happened!
>
> This is a problem (esp
Op di 21 jan. 2020 om 05:48 schreef Biswapriyo Nath :
> Generally, there would not be any big difference between compiled dll by
> msvc and mingw-w64.
>
There are quite a few differences actually, not limited to:
- dependencies on VS or MinGW-w64/GCC runtime libraries. This will improve
if GCC i
Op wo 11 dec. 2019 23:31 schreef David Mathog :
>
> or some switch
> used with "./configure".
>
You'll need to pass "--host=i686-w64-mingw32".
If you don't, it tries to identify the MSYS2 environment, which in the best
case returns something Unix-like, which is not what you want.
If there are a
This GMP's configure script that is misdetecting your bitness.
Clear your build directory, and be sure to run configure with
"--host=i686-w64-mingw32", perhaps even a "--build=i686-w64-mingw32" if
that's not enough.
That should make sure everything is lined up properly.
Ruben
Op wo 20 nov. 201
This is awesome!
Although winpthreads was a nice in-between solution for this (and it still
is a good solution for those who want a pthreads library on Windows), this
is what everyone (using C++ and/or OpenMP, heck, even C11 thread support)
needs of course.
I'm interested in seeing real-world ben
All this probably is a great idea :). I just have (entirely worthless) 2c
two share on one point you bring up:
Op wo 22 mei 2019 om 21:44 schreef Jacek Caban :
> - mingw-w64 name
>
> There have been talks about rebranding mingw-w64 for a long time (longer
> than I am in joined the project). While
The patch is about something totally different. You're replying to another
thread on this mailing list ;)
Great that you got it to work!
2018-06-10 19:36 GMT+02:00 Brian Johnson :
> Thanks very much for the replies. I was able to successfully link with
> the following string:
>
> sudo ld -dll
It would really helpful there were a backtrace of the crash, so we could
pinpoint where the problem might lie.
Ruben
Op 27 nov. 2017 10:17 a.m. schreef "Christer Solskogen" <
christer.solsko...@gmail.com>:
> Hi!
>
> I cross compile a Atari ST(e) emulator called hatari using a Linux
> machine. Th
ing mode
(-std=c++??).
The question as how I see it is why WIN32 is defined at all in the
-std=gnu++XX modes. There's no answer to that in this thread.
Ruben
Best, Norbert.
On Thu, Oct 12, 2017 at 1:58 PM Ruben Van Boxem
wrote:
> Op 12 okt. 2017 11:15 a.m. schreef "Frédéric"
Op 12 okt. 2017 11:15 a.m. schreef "Frédéric" :
> If you look at MSDN, it's actually _WIN32 is the only macro really
> mentioned anywhere. WIN32 is defined by most Visual studio projects at
that
> level, not the compiler. So in my eyes, changing code to check for _WIN32
> is the only right thing t
If you look at MSDN, it's actually _WIN32 is the only macro really
mentioned anywhere. WIN32 is defined by most Visual studio projects at that
level, not the compiler. So in my eyes, changing code to check for _WIN32
is the only right thing to do.
Ruben
Op 12 okt. 2017 9:11 a.m. schreef "Frédéric
Op 3 aug. 2017 9:26 p.m. schreef "Martell Malone" :
Hey Martin,
Glad to see you following up on my various LLVM adventures :)
From what I remember the initialization is done in mingw-w64/crt/gccmain.c.
I believe it may be possible to add this code and not make is clang
specific.
Before the iter
Op 3 jul. 2017 11:27 p.m. schreef "Riot" :
Sure, but they're embarassingly trivial, as my email suggests.
// build with g++ test_temp_path.cpp -lstdc++fs
#include
#include
auto main()->int {
std::cout << "Temp dir: \"" <<
std::experimental::filesystem::temp_directory_path() << "\"" << std::e
I would maybe go one step further and make this a configure option (with
default value). Then a user can decide if it's necessary to increase this
for any reason whatsoever.
Op 9 jun. 2017 11:18 a.m. schreef "Kai Tietz via Mingw-w64-public" <
mingw-w64-public@lists.sourceforge.net>:
> I agree tha
Hi,
GCC 7.1 warns on implicit fallthrough in switch-case. Adding attributes or
comments silences this warning.
See https://sourceforge.net/p/mingw-w64/bugs/616/
Attached patch solves this for gendef and genpeimg.
Please apply if OK.
Ruben
diff --git a/mingw-w64-tools/gendef/src/gendef.c
b/min
Op 2 jun. 2017 9:54 p.m. schreef "bob by" :
2017-06-02 22:24 GMT+04:00 Ruben Van Boxem :
> Be sure to check the final program code size in case of using such a
> utility library vs just the C++ standard library. You might be
surprised...
>
> Also important to note c+
Op 2 jun. 2017 3:32 p.m. schreef "LRN" :
On 6/2/2017 3:53 PM, bob by wrote:
> On 2017-06-02 16:23 GMT+04:00 LRN wrote:
>> On 6/2/2017 2:47 PM, bob by wrote:
>>> Can somebody here write a replacement for the standard cout, that will
be
>>> able to print strings and integers, and internally will jus
Your attachment was eaten by the Sourceforge cookie monster :)
2017-05-01 18:55 GMT+02:00 David Grayson :
> I sent a patch to this list 6 days ago that fixes a problem with the way we
> use the selectany attribute. If you're getting multiple definition errors
> for GUIDs, this will probably fi
Op 21 mrt. 2017 8:07 a.m. schreef "Liu Hao" :
On 2017/3/20 20:49, Jon Turney wrote:
> Windows 10 now has a separate exception for OutputDebugStringW, rather
than
> converting the string to ANSI and raising DBG_PRINTEXCEPTION_C.
>
> (See https://ntquery.wordpress.com/2015/09/07/windows-10-new-
anti
ranite into a minivan and
surprised it won't budge.
I'm not criticising you, just telling you you're using the tools outside of
their design specifications.
Ruben
Op 14 mrt. 2017 11:48 p.m. schreef "Ruben Van Boxem" <
vanboxem.ru...@gmail.com>:
> Hello again,
>
The default values can be found in
https://github.com/gcc-mirror/gcc/blob/master/gcc/params.def
For example, but I guess you already knew where to find those.
Op 14 mrt. 2017 11:55 p.m. schreef "Ruben Van Boxem" <
vanboxem.ru...@gmail.com>:
> Additionally, if you look at th
Hello again,
Op 14 mrt. 2017 9:26 p.m. schreef "Riot" :
On 14 March 2017 at 18:53, Ruben Van Boxem wrote:
> These options look quite... inefficient... and frankly suboptimal. I hope
> you do regular benchmarking to see if these are actually any/much better
> than default -O
itectural OS limitations.
> 3. I haven't tried stripping the objects prior to linking; I was going to
> do that until I discovered that I can work around the issue by disabling
> the above-mentioned param. If it would still be useful for me to try this
> and test further, I
Hi,
Just some random helpful thoughts:
- the linker typically uses a lot more memory than the sum of everything it
is linking together.
- LTO is still quite unstable, even on Linux, where I know of no Linux
distro that actually enables the option to build its binaries.
- The 32-bit process is limi
Friendly ping!
2016-10-04 21:50 GMT+02:00 Ruben Van Boxem :
> Hi Jacek,
>
> I got delayed doing other stuff like painting doors and partying etc. but
> I still have to patch the MinGW-w64 master version to work with Skia.
> Attached is the patch I need to apply. I tried to matc
ng of declaration of each functions. Also to preserve proper vtbl
> >> layout, declaration of parent interface needs to be copied inside
> >> __cplusplus guard. See other declarations for an example. Also we try to
> >> avoid using things like _In_, _Out_ macros in our head
with MinGW-w64)
to this email for convenience. Note there were duplicate GUID's in the
previous patch, those were removed here.
Please OK and apply so I can stop keeing my custom builds of MinGW-w64
around, thanks :)
Cheers!
Ruben
2016-08-09 19:44 GMT+02:00 Ruben Van Boxem :
> Hi K
2016-08-17 22:08 GMT+02:00 David Wohlferd :
> I'm reluctant to get too far ahead when creating patches. My skills
> with git just aren't up to it.
>
>
I can strongly suggest Sourcetree. With it, you can go line by line through
source files and add only the bits and pieces you want to a commit. It
;s see what upstream thinks about this.
Cheers,
Ruben
2016-08-09 11:00 GMT+02:00 Kai Tietz :
> Hmm, for me it looks like there is the forwarder declaration missing.
> Jacek do you have here any more detailed knowledge?
>
> Thanks,
> Kai
>
> 2016-08-08 22:47 GMT+02:00 R
t; patch looks fine to me. As long as there are no objections (Jacek do
> you?), go ahead and apply.
>
> Thanks,
> Kai
>
> 2016-08-08 20:57 GMT+02:00 Ruben Van Boxem :
> > Hi guys,
> >
> > it would be nice to keep up to date with new APIs that gain real
Hi guys,
I'm compiling skia with MinGW-w64 GCC, and after the stuff in my previous
mail and some other small things, I came across this:
In file included from C:/Development/skia/src/xps/SkDocument_XPS.cpp:12:0:
C:/Development/skia/src/xps/SkXPSDevice.h:187:15: error: 'XPS_SIZE' does
not name a t
Hi guys,
it would be nice to keep up to date with new APIs that gain real world use,
like this little patch:
https://github.com/Alexpux/mingw-w64/pull/1/commits/6c0efe37b32510f72020e38726c7a84690a926fd
Which is now needed for Qt 5.7 (and skia).
I would also like to point out attached patch that
Hi everyone,
Since I am morally compelled to provide a GCCC 6.1 toolchain (even though
Microsoft's S.T.L. has already had one since like, GCC 6.1 was released), I
blew the dust off my old build scripts to see what they are still worth.
Aside from most of the issues that made me put them aside I d
Hi guys,
When I read the email asking for GCC 6.1, I took a look at MinGW-builds and
MSYS2's MinGW-packages and saw both were stuck somewhere in 5.x.
I decided to see if I could blow the dust off my aeons-old build scripts
that are still gathering some stars on github, but were otherwise unused.
Hi!
I do wonder how this compares with e.g. the MinGW-stdthread header only
implementaion on github. As far as I remember, the author explicitly relicensed
his code so it could be used for the same purpose. How dies it compare to your
implementation?
Since the ABI of the toolchain will be diff
I for one am grateful for the configure script. I’m sure I’m not alone.
Ruben
Van: Jean-Baptiste Kempf
Verzonden: maandag 6 juni 2016 21:49
Aan: mingw-w64-public@lists.sourceforge.net
Onderwerp: Re: [Mingw-w64-public] Autotools & git
On 06 Jun, Ozkan Sezer wrote :
> Not everyone would have the r
I'd really really really suggest just using --enable-threads=windows or
something, and implement them using somthing compatible to the windows
runtime if at all possible. This is available on Windows 7+ and seems as
reasonable as anything.
If there are better routines in e.g. Windows 8 or 10, it w
Hi Jim,
I still find it quite astounding that after so many years on this list you
still fail to provide a small, self-contained, compilable example source
code fragment to show the problems you send multiple incomprehensible
emails about.
Show the code or don't get help. I'm quite close to leavi
ge over msys-package?
> Should I use python2 from msys or mingw? Or install both? For another
> build, I tried cmake from msys and miserably failed, whereas cmake from
> mingw worked out of the box. Is mingw usually "preferable"?
>
> Thanks for your help, and all th
Hi Mario,
A thing as large as Qt is quite daunting to get to work, often because each
little thing you try requires a full rebuild to make sure the change was
actually propagated through all the layers of the build system.
I would suggest starting from the PKGBUILD for the binary package, which
2016-03-18 17:22 GMT+01:00 Vitaly Kruglikov :
>
>
>
> >
> >
> >
> >--
> >
> >Message: 3
> >Date: Fri, 18 Mar 2016 04:37:25 +0100
> >From: Vincent Torri
> >Subject: Re: [Mingw-w64-public] Order of -ladvapi32 versus -lkernel32
> >To: "mingw-w64-public@lists.sourceforge.n
2016-03-17 16:23 GMT+01:00 LRN :
>
> Why would you do that? What are you hoping to achieve by telling the
> difference between TDM mingw-w64-based toolchain and non-TDM
> mingw-w64-based toolchain?
>
>
There are ABI differences, but those shouldn't matter inside the code. This
difference should on
2016-03-01 16:58 GMT+01:00 Daniel Franzini :
> I think that comparing floating point numbers this way is wrong (well, at
> least in C it is) because you can't never know how is the precision of this
> comparison. It might be the case that in C++ the == operator is overloaded
> and it performs corr
2016-03-01 15:25 GMT+01:00 Dongsheng Song :
>
> On Tue, Mar 1, 2016 at 8:42 PM, Ismail Donmez wrote:
>
>> Hi,
>>
>> mingw-w64's current mkstemp implementation wrongly uses _O_TEMPORARY which
>> doesn't make sense. Here is a patch from openSUSE we apply to fix it:
>>
>> From: Jan Engelhardt
>> Da
2016-01-20 13:55 GMT+01:00 :
> Hi,
>
> Probably 2 dumb questions - my only excuse is that I haven't been forced to
> consider them before. And that's not a very good excuse.
>
There are no dumb questions, only dumb answers.
> My other sin is that this post pretty much repeats the question I've
2016-01-19 7:07 GMT+01:00 :
> Hi,
>
> On Windows 7, when I build gmp-6.1.0 in the msys shell using gcc-4.9.2
> (i686-posix-sjlj), ABI is set to 32 and the created gmp.h contains entries
> such as:
>
> #define GMP_LIMB_BITS 32
> and
> #define __GMP_CFLAGS
> "-m32 -O2 -pedantic
2015-10-29 3:54 GMT+01:00 Martell Malone :
> My second reason is clang.
> I currently have a mingw-w64 toolchain with this stack.
> clang + libc++ + compiler-rt + lld
> this equates to
> gcc + libstdc++ + libgcc + binutils.
>
> If we want a standalone clang stack using lld we should not have to bu
2015-08-12 13:26 GMT+02:00 Ken Birman :
> Hi guys,
>
>
>
> I’ve long been a fan of the Mingw work and GCC more broadly, but the
> obligatory copyleft language in the threads subpackage for the most recent
> release is a significant issue that will force me to shift towards Clang or
> off of C++ 11
2015-07-31 13:07 GMT+02:00 Edward Diener :
> On 7/31/2015 6:05 AM, Ruben Van Boxem wrote:
> > 2015-07-31 2:04 GMT+02:00 Edward Diener > <mailto:eldlistmaili...@tropicsoft.com>>:
> >
> > On 7/30/2015 10:48 AM, Óscar Fuentes wrote:
> > >
2015-07-31 2:04 GMT+02:00 Edward Diener :
> On 7/30/2015 10:48 AM, Óscar Fuentes wrote:
> > Edward Diener
> > writes:
> >
> >>> Another thing is to get some hints from a .map-file.
> >>> Add "-Wl,--print-map,--sort-common,--cref > file.map" at the
> >>> of the link-cmd.
> >>
> >> I could not find
2015-07-28 14:44 GMT+02:00 Edward Diener :
> On 7/28/2015 8:27 AM, Edward Diener wrote:
> > Without trying immediately to give specific code for what is a large
> > project, I am getting linker errors when trying to link a second shared
> > library which depends on a first shared library that has
2015-07-27 8:54 GMT+02:00 Edward Diener :
> On 7/24/2015 11:13 AM, Ruben Van Boxem wrote:
> > 2015-07-24 17:03 GMT+02:00 Edward Diener > <mailto:eldlistmaili...@tropicsoft.com>>:
> >
> > On 7/24/2015 8:54 AM, Riot wrote:
> > > Where are you de
2015-07-24 17:03 GMT+02:00 Edward Diener :
> On 7/24/2015 8:54 AM, Riot wrote:
> > Where are you defining your template, in the header or the source? You
> > may need to explicitly instantiate.
>
> The template is being defined in the YY.cpp source file.
>
Could you send example files displaying
Here you can find GCC's C++11 implementation status:
https://gcc.gnu.org/projects/cxx0x.html
And the same for C++14:
https://gcc.gnu.org/projects/cxx1y.html
Here you can find libstdc++ implementation status:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html
Make sure you are invoking t
2015-07-05 15:40 GMT+02:00 :
> Can anyone, pleeese, tell me why this extractor operator is not causing
> this
> error:
> C:\tmp\adfs\main.cpp|20|error: no match for 'operator<<' (operand types are
> 'std::wostream {aka std::basic_ostream}' and
> 'std::unique_ptr')|
>
> namespace abc{
> class MyCla
2015-07-01 12:15 GMT+02:00 :
> In this web page:
> http://en.cppreference.com/w/cpp/locale/toupper
>
> I got this code:
> #include
> #include
> #include
>
> int main()
> {
> wchar_t c = L'\u017f'; // Latin small letter Long S ('ſ')
> std::cout << std::hex << std::showbase;
> std::co
y much correct I am left with the same
> question as the OP -> are there no any options if MinGw compiler is used?
>
>
> I have changed the subject of this email to better reflect my predicament
>
> *From:* Ruben Van Boxem
> *Sent:* Monday, June 29, 2015 4:10 AM
> *To:*
question can
throw an exception.
That sounds quite useless to me IMHO.
Just remove it, or ifdef a THROWS macro or some such.
Cheers,
Ruben
> *From:* Ruben Van Boxem
> *Sent:* Monday, June 29, 2015 2:27 AM
> *To:* mingw-w64-public@lists.sourceforge.net
> *Subject:* Re: [Mingw-w64-pub
Op 29-jun.-2015 07:32 schreef :
>
> In VS2013, I declare the member functions like this:
> void setString(const std::wstring& _str) throw(...);
>
> But now that I am switching to MinGW, I get a complain from the compiler
saying:
> error: expected type-specifier before '...' token
> throw(...) {
>
>
2015-06-23 9:31 GMT+02:00 Alexpux :
>
> 23 июня 2015 г., в 10:22, Ruben Van Boxem
> написал(а):
>
>
>
> 2015-06-23 2:17 GMT+02:00 Óscar Fuentes :
>
>>
>> So moving cc1plus.exe to `bin' makes the toolchain "self contained", but
>> it is n
2015-06-23 2:17 GMT+02:00 Óscar Fuentes :
>
> So moving cc1plus.exe to `bin' makes the toolchain "self contained", but
> it is no solution as soon as you try to execute the programs you created
> with that toolchain.
>
Let me just jump in here and add an extra data point to the discussion: I
ha
Op 22-jun.-2015 19:48 schreef "LRN" :
>
> On 22.06.2015 19:09, Etienne Sandré-Chardonnal wrote:
> > On 2015-06-22 17:21 GMT+02:00 LRN wrote:
> >> On 22.06.2015 17:25, Etienne Sandré-Chardonnal wrote:
> >>> Hi,
> >>>
> >>> Without eof, it still returns 262 bytes which is wrong.
> >> That's a very ar
2015-06-22 13:21 GMT+02:00 Etienne Sandré-Chardonnal :
> Hi,
>
> I have tried to open the file with _wfopen(), pass it to __gnu_cxx::
> stdio_filebuf, and set it as the buffer of an std::istream.
> The file is open properly, first bytes are OK, but after 263 read bytes I
> get an eof(), while the
2015-06-19 16:56 GMT+02:00 Ruben Van Boxem :
> 2015-06-19 16:45 GMT+02:00 Etienne Sandré-Chardonnal <
> etienne.san...@m4x.org>:
>
>> Dear all
>>
>> I have found this old gcc discussion from Ruben :
>> http://gcc.gnu.org/ml/libstdc++/2011-06/msg00066.html
2015-06-19 16:45 GMT+02:00 Etienne Sandré-Chardonnal :
> Dear all
>
> I have found this old gcc discussion from Ruben :
> http://gcc.gnu.org/ml/libstdc++/2011-06/msg00066.html
>
> Is this available in recent mingw releases? I cannot find any of these
> extensions in 4.9.2 headers (and it does not
2015-06-19 0:32 GMT+02:00 Jose Alf. :
> You can get rid of the environment variable using a win32 api call as
> explained here:
>
>
> http://stackoverflow.com/questions/2647429/c-windows-path-to-the-folder-where-the-executable-is-located
>
>
>
> On Thursday, June 18, 2015 4:45 PM, Hotmail (Arbol
2015-06-17 18:21 GMT+02:00 lh_mouse :
> g++ and clang++ use Itanium ABI while MSVC uses some M$ specific,
> unpublished ABI. Hence it is not surprising that they are incompatible with
> each other.
>
>
Clang actually aspires to use MSVC's ABI on Windows, and they're close, if
not already in a usef
2015-06-17 17:44 GMT+02:00 Etienne Sandré-Chardonnal :
> Dear all,
>
> I have a plugin system in my app based on interfaces (classes with only
> pure virtual functions). The app is compiled with mingw-w64 4.9.2 and works
> well with plugin dlls compiled with the same compiler.
>
> Now I am trying
2015-06-10 23:24 GMT+02:00 Adrien Nader :
> My initial notes for possible other service providers:
>
> http://librelist.com/ for mailing-lists
> - activity status unknown (not asked)
> - dispute resolution process unknown (not asked)
> - only mailing-lists
>
> http://www.tuxfamily.org/en/about for
2015-06-02 7:26 GMT+02:00 asmwarrior :
> On 2015-5-31 16:22, asmwarrior wrote:
> > On 2015-5-23 9:39, asmwarrior wrote:
> >> I just want to hunt the GCC bug: (big pch file will crash cc1plus.exe)
> >> 56926 – Crash (without ICE) while compiling Boost.Math -
> https://gcc.gnu.org/bugzilla/show_bug.
2015-05-29 13:36 GMT+02:00 Riot :
> I have to disagree. I use lto in large production builds with great
> success. My use case is performance critical (games) and I build with
> -Ofast as well as lto and other heavy optimisations without problems,
> generating executable binaries of over a hundred
2015-05-26 10:57 GMT+02:00 Pavel Fedin :
> Hello!
>
> > IMHO, no project is too small for a separate project page and
> repository. And I don't see how this could ever belong inside the mingw-w64
> project, honestly, as it is not related to the Windows runtime in any way
> (unless I'm missing som
2015-05-26 9:05 GMT+02:00 Pavel Fedin :
> Hi!
>
> > What is your sourceforge ID?
>
> It's sonic_amiga. And it's still operational, to my great surprise :)
>
IMHO, no project is too small for a separate project page and repository.
And I don't see how this could ever belong inside the mingw-w64
Now without zip...
015-05-19 10:17 GMT+02:00 Ruben Van Boxem :
> 2015-05-19 10:03 GMT+02:00 LRN :
>
>> On 19.05.2015 10:09, Ruben Van Boxem wrote:
>> > Hi guys,
>> >
>> > There has recently (as in, yesterday) been a new flicker of activity in
>> the
2015-05-19 9:22 GMT+02:00 Alexpux :
>
> 19 мая 2015 г., в 10:09, Ruben Van Boxem
> написал(а):
>
> Additionally, there seem to be some misconceptions as to the number of
> different toolchains available, I'll offer to straighten that out with him,
> and point him to th
Hi guys,
There has recently (as in, yesterday) been a new flicker of activity in the
mingw-python camp.
For a long time, GCC on Windows was not a usable option for Python without
some pretty big workarounds and hacks to get everything working. The
biggest issue being that you cannot simply build P
2015-05-08 2:19 GMT+02:00 James Franco :
> Just FYI after i hit continue the installation does go on.
>
> On Thu, May 7, 2015 at 5:11 PM, David Macek
> wrote:
>
>> On 7. 5. 2015 22:03, James Franco wrote:
>> > When I attempt to install Msys2 from the download link you suggested
>> > http://source
Guys,
this issue is popping up from time to time. I can understand it might be
hard to solve, but this is not good advertising for the project:
http://stackoverflow.com/questions/30069830/how-to-install-mingw-w64-and-msys2
Maybe storing the repository.txt in some other location might be a
workar
2015-04-28 8:36 GMT+02:00 Pavel :
> On Tue, 2015-04-28 at 08:08 +0200, Christer Solskogen wrote:
> > On 27.04.2015 20:16, LRN wrote:
> >
> > > At a glance it looks like SDL_render_d3d11.c declares and defines
> > > IID_IDXGIFactory2, and mingw's dxgi1_2.h declares IID_IDXGIFactory2 as
> well
> > >
2015-04-23 23:07 GMT+02:00 James Franco :
> Are there any known issues of cc1plus.exe crashing with shift-jis.
> Apparent I have a code base that uses shift-jis (japanese) encoding in
> some source files and cc1plus.exe was crashing. After converting the
> encoding to ascii cc1plus is not crashin
2015-04-14 19:13 GMT+02:00 James Franco :
> I am attempting to port a project from Visual Studio to Mingw 64 bit GCC.
> During the port when I attempt to build a certain component using Mingw g++
> through CodeBlocks I get the error
> "cc1plus.exe has stopped working." Is there a way for me to fig
2015-03-24 21:20 GMT+01:00 Adrien Nader :
> Hi,
>
> On Tue, Mar 24, 2015, David Macek wrote:
> > On 20. 3. 2015 22:51, Adrien Nader wrote:
> > > Hi,
> > >
> > > I've just pushed a redirect from http://mingw-w64.sourceforge.net to
> > > http://mingw-w64.yaxm.org in order to serve a new website.
> >
2015-03-18 16:28 GMT+01:00 Derek Buitenhuis :
> On 3/17/2015 11:27 PM, Vadim Chugunov wrote:
> > I think I am bumping into the issue described here:
> https://sourceware.org/bugzilla/show_bug.cgi?id=16598. The bug also has
> a patch attached. What would it take to get someone to merge it?
>
> Th
2015-03-08 12:20 GMT+01:00 Marco Costalba :
> I am one of the developer of a chess engine called Stockfish:
>
> https://github.com/official-stockfish/Stockfish
>
> A chess engine is a high performance piece of multi-thread software, where
> even a small sub-optimal code path immediately translates
2015-02-23 18:42 GMT+01:00 David Rysdam :
> David Rysdam writes:
> > That seems to succeed, although I'm still not sure what > build machine> should be. I'll keep moving forward and if I have
> > problems checkpoint back to this.
>
> New problem and I don't see any obvious way it is related to t
2015-02-12 7:41 GMT+01:00 Jim Michaels :
> 1MiB variable size limit in dongsheng daily gcc-5.0-win64_5.0.0-20141105
> did this get fixed? for example the standard c++ string library.
> I need it much larger.
> one of the things I might do is put a whole file content into a string to
> process. I h
2015-01-03 20:44 GMT+01:00 Kai Tietz :
> Yeah, the issue about releasing something not really completing a
> feature is ... well ... feeling bad. Nevertheless I admit that
> already a lot of changes went into master already, and it is obvious
> that our users are eager to get all this in an offic
2014-12-16 9:56 GMT+01:00 Jim Michaels :
>
> usually, any microsoft _PTR is a *, but DWORD_PTR is defined as long long
> unsigned int.
> winerrstr.cpp:83:24: error: invalid conversion from 'DWORD* {aka long
> unsigned int*}' to 'DWORD_PTR {aka long long unsigned int}' [-fpermissive]
> DWORD_PTR
2014-12-12 16:04 GMT+01:00 John E. / TDM :
>
> On 12/12/2014 3:13 AM, Massimo Belgrano wrote:
> > Nice see tdm reborn
> > How many mingw version exist for windows ?
> > wich are the differences?
>
> Too many to list for you here. I'll just stick with the ones you're
> likely to hear about on this m
Hi guys,
I'd like to draw your attention to a std::thread implementation written
without pthreads.
It seems quite lightweight, and almost too small to be fully compliant.
If it is at all useful or even completely/nearly bug-free, perhaps it would
be worth getting this into GCC/libstdc++ mainline
2014-12-08 19:32 GMT+01:00 Jim Michaels :
> is this msys2 something that applies to mingw-w64? should I be using this
> instead of
> https://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/
> ?
>
That is a ridiculously outdated all-
2014-12-09 14:24 GMT+01:00 John E. / TDM :
> On 12/8/2014 11:29 PM, Greg Jung wrote:
> > Hi John,
> > If you would indulge my questions, I am intrigued by the advice re:
> > "-fno-keep-inline-dllexport" flag
> > because it mentions wxWidgets which I am trying to incorporate into an
> > already-l
Hi Corinna,
With fear of my life I stick my head in a hornet's nest, with some remarks:
Archlinux solved this issue some years ago, and the bug report is cause for
an interesting read with some pointers on how to solve this for the MSYS2
folks: https://bugs.archlinux.org/task/5355
Any GPLv3 proje
2014-11-26 13:04 GMT+01:00 Erik de Castro Lopo :
> jose...@rocketmail.com wrote:
>
> >
> > Did you try adding just -static to the link command?
>
> Just now. With -static it makes everything static, including the
> library I'm trying to build as a DLL.
>
That's because you typically link DLLs to
2014-11-23 17:19 GMT+01:00 K. Frank :
> Hi Adrian!
>
> (Note, I haven't copied this response to the Wt list as it doesn't
> really concern Wt.)
>
> I would like to follow up on gcc 4.9.0 vs. 4.9.2.
>
> On Sun, Nov 23, 2014 at 6:22 AM, Adrien Nader wrote:
> > Hi,
> >
> > On Sat, Nov 22, 2014, K.
2014-11-07 14:45 GMT+01:00 Dongsheng Song :
> On Fri, Nov 7, 2014 at 4:44 PM, lh_mouse wrote:
> > Minor suggestion: use the word `DECLARED` instead `DEFINED` please.
> >
>
> I don't known which is better:-)
> Here is some stats:
>
> $ grep -r "_DEFINED[^A-Z0-9]" . | wc -l
> 26145
>
> $ grep -r "_
2014-11-07 9:25 GMT+01:00 Ozkan Sezer :
> On 11/7/14, Dongsheng Song wrote:
> > If we define _POSIX_, then getpid (process.h) was hidden.
> > Is it correct ?
> >
> > PS: MSVC 2012 is the last compiler which use _POSIX_, MSVC 2013 do not
> > use _POSIX_ anymore.
> > MSVC 2012/2013 guard getpid wit
2014-11-03 16:45 GMT+01:00 Baruch Burstein :
> On Mon, Nov 3, 2014 at 2:37 PM, Ruben Van Boxem
> wrote:
>
>> 2014-11-03 10:30 GMT+01:00 Baruch Burstein :
>>
>>> I am curious why only a few of the executables get prefixed versions? I
>>> just tried r
2014-11-03 10:30 GMT+01:00 Baruch Burstein :
> I am curious why only a few of the executables get prefixed versions? I
> just tried running a certain makefile with prefixed versions of the
> toolchain, and it failed looking for the prefixed versions of 'ar' and
> 'windres'. Easily solvable (make a
1 - 100 of 1058 matches
Mail list logo
