Re: [Mingw-w64-public] runtime difference between code compiled with VS and gcc

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

Re: [Mingw-w64-public] cmake not creating directories on mingw64, works fine on linux.

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

Re: [Mingw-w64-public] requirements to use a mingw dll with python

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

Re: [Mingw-w64-public] libxml2 2.9.7 built a year ago, not now

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

Re: [Mingw-w64-public] GMP compile error with GCC 9.2.0

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.

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

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

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

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).

Re: [Mingw-w64-public] [PATCH] crt/misc/imaxdiv.c: Fix prototype of `lldiv()`.

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

Re: [Mingw-w64-public] Crash with Windows 7

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.

Re: [Mingw-w64-public] no WIN32 predefined macro with -std=c++{98, 11, 14}, only with gnu++{98, 11, 14}

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 <vanboxem.ru...@gmail.com> wrote: > Op 12 okt. 2017 11:15 a.m.

Re: [Mingw-w64-public] no WIN32 predefined macro with -std=c++{98, 11, 14}, only with gnu++{98, 11, 14}

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

Re: [Mingw-w64-public] no WIN32 predefined macro with -std=c++{98, 11, 14}, only with gnu++{98, 11, 14}

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

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

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

Re: [Mingw-w64-public] Various std::experimental::filesystem errata

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: \"" <<

Re: [Mingw-w64-public] Default _WIN32_WINNT version too low?

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

[Mingw-w64-public] implicit-fallthrough GCC warning as error in gendef/genpeimg

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

Re: [Mingw-w64-public] C++ cout executable size

Op 2 jun. 2017 9:54 p.m. schreef "bob by" <blaoiwn4920...@gmail.com>: 2017-06-02 22:24 GMT+04:00 Ruben Van Boxem <vanboxem.ru...@gmail.com>: > Be sure to check the final program code size in case of using such a > utility library vs just the C++ standard lib

Re: [Mingw-w64-public] C++ cout executable size

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

Re: [Mingw-w64-public] Duplicate symbols definition in between uuid.c and extra-uuid.c

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

Re: [Mingw-w64-public] [PATCH] Add DBG_PRINTEXCEPTION_WIDE_C exception

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

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

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, > > Op 14 mrt. 2017 9:26 p.m.

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

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

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

Hello again, Op 14 mrt. 2017 9:26 p.m. schreef "Riot" <rain.back...@gmail.com>: On 14 March 2017 at 18:53, Ruben Van Boxem <vanboxem.ru...@gmail.com> wrote: > These options look quite... inefficient... and frankly suboptimal. I hope > you do regular benchmarking to s

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

tations. > 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 can do - just let me kno

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

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

Re: [Mingw-w64-public] DirectWrite additions

Friendly ping! 2016-10-04 21:50 GMT+02:00 Ruben Van Boxem <vanboxem.ru...@gmail.com>: > 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 n

Re: [Mingw-w64-public] DirectWrite additions

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 <vanboxem.ru...@gmail.

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

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

[Mingw-w64-public] Compiling skia, part 2: xpsobjectmodel.h

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

[Mingw-w64-public] Exceptions broken on vanilla GCC build, why?

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

Re: [Mingw-w64-public] Autotools & git

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

Re: [Mingw-w64-public] Adding a new thread model to GCC

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

Re: [Mingw-w64-public] improper errors on what should be valid code syntax

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

Re: [Mingw-w64-public] problem compiling QT: where to report?

package 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

Re: [Mingw-w64-public] problem compiling QT: where to report?

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

Re: [Mingw-w64-public] Order of -ladvapi32 versus -lkernel32

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

Re: [Mingw-w64-public] Differentiate on MinGW-w64 and TDM-gcc

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

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

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

Re: [Mingw-w64-public] Fix mkstemp implementation

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

Re: [Mingw-w64-public] Should i686 compilers allow the -m64 switch ?

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

Re: [Mingw-w64-public] i686-posix-sjlj and gmp

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

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

2015-07-28 14:44 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com: 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

Re: [Mingw-w64-public] Linker problem with i686-5.1.0-posix-dwarf-rt_v4-rev0 version

2015-07-27 8:54 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com: On 7/24/2015 11:13 AM, Ruben Van Boxem wrote: 2015-07-24 17:03 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com mailto:eldlistmaili...@tropicsoft.com: On 7/24/2015 8:54 AM, Riot wrote: Where are you

Re: [Mingw-w64-public] Linker problem with i686-5.1.0-posix-dwarf-rt_v4-rev0 version

2015-07-24 17:03 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com: 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

Re: [Mingw-w64-public] std::locale

2015-07-01 12:15 GMT+02:00 p...@arbolone.ca: In this web page: http://en.cppreference.com/w/cpp/locale/toupper I got this code: #include iostream #include cwctype #include locale int main() { wchar_t c = L'\u017f'; // Latin small letter Long S ('ſ') std::cout std::hex

Re: [Mingw-w64-public] no function forstd::ifstreamwchar_t::open(const wchar_t*)?

predicament *From:* Ruben Van Boxem vanboxem.ru...@gmail.com *Sent:* Monday, June 29, 2015 4:10 AM *To:* mingw-w64-public@lists.sourceforge.net *Subject:* Re: [Mingw-w64-public] throw(...) in MinGW 2015-06-29 9:54 GMT+02:00 p...@arbolone.ca: Thanks Ruben for the help. To answer your

Re: [Mingw-w64-public] Include and lib search paths for mingw-64

2015-06-23 2:17 GMT+02:00 Óscar Fuentes o...@wanadoo.es: 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

Re: [Mingw-w64-public] Include and lib search paths for mingw-64

2015-06-23 9:31 GMT+02:00 Alexpux alex...@gmail.com: 23 июня 2015 г., в 10:22, Ruben Van Boxem vanboxem.ru...@gmail.com написал(а): 2015-06-23 2:17 GMT+02:00 Óscar Fuentes o...@wanadoo.es: So moving cc1plus.exe to `bin' makes the toolchain self contained, but it is no solution as soon

Re: [Mingw-w64-public] Opening unicode filenames with MinGW-w64

Op 22-jun.-2015 19:48 schreef LRN lrn1...@gmail.com: 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

Re: [Mingw-w64-public] Opening unicode filenames with MinGW-w64

2015-06-22 13:21 GMT+02:00 Etienne Sandré-Chardonnal etienne.san...@m4x.org : Hi, I have tried to open the file with _wfopen(), pass it to __gnu_cxx:: stdio_filebufchar, 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

Re: [Mingw-w64-public] finding the data file

2015-06-19 0:32 GMT+02:00 Jose Alf. jose...@rocketmail.com: 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,

Re: [Mingw-w64-public] Opening unicode filenames with MinGW-w64

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 Is this available in recent mingw releases? I cannot find any of these extensions in 4.9.2 headers

Re: [Mingw-w64-public] Opening unicode filenames with MinGW-w64

2015-06-19 16:56 GMT+02:00 Ruben Van Boxem vanboxem.ru...@gmail.com: 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 Is this available in recent

Re: [Mingw-w64-public] Mingw-64 and MSVC x64 ABI

2015-06-17 18:21 GMT+02:00 lh_mouse lh_mo...@126.com: 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

Re: [Mingw-w64-public] Mingw-64 and MSVC x64 ABI

2015-06-17 17:44 GMT+02:00 Etienne Sandré-Chardonnal etienne.san...@m4x.org : 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.

Re: [Mingw-w64-public] About the recent sourceforge events

2015-06-10 23:24 GMT+02:00 Adrien Nader adr...@notk.org: 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

Re: [Mingw-w64-public] Set a larger pch file size limit? was : can anyone supply a debug version of cc1plus.exe?

2015-06-02 7:26 GMT+02:00 asmwarrior asmwarr...@gmail.com: 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 -

Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1

2015-05-29 13:36 GMT+02:00 Riot rain.back...@gmail.com: 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

Re: [Mingw-w64-public] Contributing a package

2015-05-26 9:05 GMT+02:00 Pavel Fedin p.fe...@samsung.com: 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

Re: [Mingw-w64-public] Contributing a package

2015-05-26 10:57 GMT+02:00 Pavel Fedin p.fe...@samsung.com: 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

Re: [Mingw-w64-public] Universal CRT and Python support

2015-05-19 9:22 GMT+02:00 Alexpux alex...@gmail.com: 19 мая 2015 г., в 10:09, Ruben Van Boxem vanboxem.ru...@gmail.com написал(а): 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

[Mingw-w64-public] Universal CRT and Python support

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

Re: [Mingw-w64-public] Universal CRT and Python support

Now without zip... 015-05-19 10:17 GMT+02:00 Ruben Van Boxem vanboxem.ru...@gmail.com: 2015-05-19 10:03 GMT+02:00 LRN lrn1...@gmail.com: 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 mingw-python camp

Re: [Mingw-w64-public] fork: can't reserve memory for stack 0xA0000 - 0x2A0000, Win32

2015-05-08 2:19 GMT+02:00 James Franco mjfranc...@gmail.com: Just FYI after i hit continue the installation does go on. On Thu, May 7, 2015 at 5:11 PM, David Macek david.mace...@gmail.com wrote: On 7. 5. 2015 22:03, James Franco wrote: When I attempt to install Msys2 from the download

[Mingw-w64-public] repository.txt not found

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

Re: [Mingw-w64-public] cc1plus.exe with SHIFS-JIS encoding

2015-04-23 23:07 GMT+02:00 James Franco mjfranc...@gmail.com: 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

Re: [Mingw-w64-public] Is there a way to figure out why - cc1plus.exe has stopped working

2015-04-14 19:13 GMT+02:00 James Franco mjfranc...@gmail.com: 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

Re: [Mingw-w64-public] [ANN] Website changes

2015-03-24 21:20 GMT+01:00 Adrien Nader adr...@notk.org: 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.

Re: [Mingw-w64-public] x64 MSVC import librries

2015-03-18 16:28 GMT+01:00 Derek Buitenhuis derek.buitenh...@gmail.com: 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

Re: [Mingw-w64-public] 1MiB variable size limit in dongsheng daily gcc-5.0-win64_5.0.0-20141105

2015-02-12 7:41 GMT+01:00 Jim Michaels jmich...@yahoo.com: 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

Re: [Mingw-w64-public] RFE: New stable release

2015-01-03 20:44 GMT+01:00 Kai Tietz ktiet...@googlemail.com: 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

Re: [Mingw-w64-public] DWORD_PTR implemented as long long unsigned int

2014-12-16 9:56 GMT+01:00 Jim Michaels jmich...@yahoo.com: 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]

Re: [Mingw-w64-public] TDM-GCC 4.9.2 released

2014-12-12 16:04 GMT+01:00 John E. / TDM tdra...@tdragon.net: 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

[Mingw-w64-public] MinGW LGPL licensed, header-only std::thread implementation

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++

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

2014-12-08 19:32 GMT+01:00 Jim Michaels jmich...@yahoo.com: 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

Re: [Mingw-w64-public] TDM-GCC 4.9.2 released

2014-12-09 14:24 GMT+01:00 John E. / TDM tdra...@tdragon.net: 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

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

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

Re: [Mingw-w64-public] i686-w64-mingw32-gcc-4.9 and -static-libgcc not working as advertise

2014-11-26 13:04 GMT+01:00 Erik de Castro Lopo mle+...@mega-nerd.com: 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

Re: [Mingw-w64-public] getpid issue

2014-11-07 9:25 GMT+01:00 Ozkan Sezer seze...@gmail.com: On 11/7/14, Dongsheng Song dongsheng.s...@gmail.com 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.

Re: [Mingw-w64-public] [PATCH] Copy getpid declaration in process.h to unistd.h

2014-11-07 14:45 GMT+01:00 Dongsheng Song dongsheng.s...@gmail.com: On Fri, Nov 7, 2014 at 4:44 PM, lh_mouse lh_mo...@126.com 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] . |

Re: [Mingw-w64-public] [Project News | New Builds]

2014-11-03 10:30 GMT+01:00 Baruch Burstein bmburst...@gmail.com: 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

Re: [Mingw-w64-public] [Project News | New Builds]

2014-11-03 16:45 GMT+01:00 Baruch Burstein bmburst...@gmail.com: On Mon, Nov 3, 2014 at 2:37 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2014-11-03 10:30 GMT+01:00 Baruch Burstein bmburst...@gmail.com: I am curious why only a few of the executables get prefixed versions? I just

Re: [Mingw-w64-public] CMake Toolcahin for linux/clang 3.6

2014-10-20 15:25 GMT+02:00 Richard Shaw hobbes1...@gmail.com: On Mon, Oct 20, 2014 at 8:03 AM, Barnaby Jones simba@schrödingerskatze.de wrote: SET( CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -target=--target=i686-w64-mingw32 ) SET( CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS}

Re: [Mingw-w64-public] CMake Toolcahin for linux/clang 3.6

2014-10-20 16:19 GMT+02:00 Óscar Fuentes o...@wanadoo.es: Barnaby Jones si...@xn--schrdingerskatze-pwb.de writes: The problems are self-evident: and CMakeError.log -- Determining if the C compiler works failed with the following output: Change Dir:

Re: [Mingw-w64-public] Debugging with GDB

2014-10-15 10:05 GMT+02:00 Alexander Shukaev haroo...@gmail.com: When the application crashes it shows the following: Fault Module Name: StackHash_e7de Fault Module Version: 0.0.0.0 Fault Module Timestamp: Exception Offset: PCH_E1_FROM_ntdll+0x0009B13A Exception

Re: [Mingw-w64-public] MinGW-W64 installation fails with 'ERROR res'

2014-10-14 14:22 GMT+02:00 niXman i.nix...@autistici.org: John Threepwood 2014-10-14 16:11: Hello, Hi, Please read this: https://sourceforge.net/p/mingw-w64/bugs/413/?page=0 Just a thought: why use a paid-for installer instead of something freely available like NSIS? Ruben --

Re: [Mingw-w64-public] MinGW-W64 installation fails with 'ERROR res'

2014-10-14 14:37 GMT+02:00 niXman i.nix...@autistici.org: Just a thought: why use a paid-for installer instead of something freely available like NSIS? Hi, Because I use this installer in a few of my commercial projects. Why do I need to learn yet another installer? Well, I honestly

Re: [Mingw-w64-public] Where is x86_64-w64-mingw32-gcc in Debian 7?

2014-09-14 17:23 GMT+02:00 Ralph Gossamer zaza4...@yandex.com: So I have installed mingw-w64 components targetting only w64 architecture on Debian 7. After installation, I couldn't locate x86_64-w64-mingw32-gcc. Or could it be called by another name? When you install the mingw-w64

Re: [Mingw-w64-public] exceptions weirdness

2014-08-24 23:48 GMT+02:00 Yaron Keren yaron.ke...@gmail.com: Hi Tai, Thanks for looking into this. You are correct the right frontend should be used, however this isn't the root of the problem. It works since g++ defaults to -shared-libgcc while gcc defaults to -static-libgcc. If you

Re: [Mingw-w64-public] OpenCL, crosscompiling, rubenvb builds

2014-08-03 11:56 GMT+02:00 Asiga Nael asigan...@yahoo.com: Hi! Is there any easy way of adding OpenCL support to rubenvb builds? I'm still in an older release (4.6.x) (because I built it myself from source and has worked great all these years), but I just downloaded the latest 4.8 release

Re: [Mingw-w64-public] internal segfault, errors using basic_ostringstringstream with u16string, u32string

2014-07-26 1:54 GMT+02:00 Jim Michaels jmich...@yahoo.com: this blast of errors is telling me that in 4.9.0 posix sjlj rev2, I have no operator+ on my basic_string for std::u16string and std::u32string, which are defined in the class. sort of. part of the reason may be because

Re: [Mingw-w64-public] possible use seh for 32 bit migw-w63 GCC-4.9.1 :

2014-07-29 11:47 GMT+02:00 massimo massimo.belgr...@gmail.com: Ruben Van Boxem vanboxem.ruben@... writes: 2014-07-22 20:01 GMT+02:00 niXman i.nixman- gaufno9rbhfsroww+9z...@public.gmane.org:Does anybody know is SEH-32bit support already implemented in GCC? It's not. Thanks for info

[Mingw-w64-public] Frame pointer and Win32 API functions

Hi guys, I stumbled upon a strange question on Stackoverflow.com: http://stackoverflow.com/q/24962205/256138 Is he right to think the generated code is suboptimal? Or is this an ABI requirement? Can GCC be improved in this regard? I can point him to this mailing list and ask him to supply

Re: [Mingw-w64-public] __int128 literals don't work

2014-07-25 13:16 GMT+02:00 Jim Michaels jmich...@yahoo.com: __int128.cpp:4:16: warning: integer constant is too large for its type __int128 i=170141183460469231731687303715884105727LL; ^ __int128.cpp:5:25: warning: integer constant is too large for its type unsigned

Re: [Mingw-w64-public] problem using printf with __int128 in 4.9.0

2014-07-25 13:10 GMT+02:00 Jim Michaels jmich...@yahoo.com: #include stdio.h #include _mingw.h int main(void) { __int128 i=170141183460469231731687303715884105727LLL; unsigned __int128 u=340282366920938463463374607431768211455ULLL; //printf(i=%I128d\n, i); printf(%*d,

Re: [Mingw-w64-public] problem using printf with __int128 in 4.9.0

2014-07-25 17:06 GMT+02:00 JonY jo...@users.sourceforge.net: On 7/25/2014 19:40, Ruben Van Boxem wrote: The fact that the compiler has a type does not mean the C library can handle it. Rebuild mingw-w64-crt with --enable-experimental=printf128 to enable experimental integer handling

Re: [Mingw-w64-public] fork is an inbuilt function?

2014-07-22 23:37 GMT+02:00 Ray Donnelly mingw.andr...@gmail.com: Hello, While porting msysGit to MSYS2/MinGW-w64 we ran into this: $ PATH=/mingw64/bin:$PATH gcc --version gcc.exe (Rev1, Built by MSYS2 project) 4.9.1 $ cat test.c #include unistd.h static inline pid_t fork(void); void

Re: [Mingw-w64-public] MSYS2 issues

2014-07-23 11:21 GMT+02:00 Jim Michaels jmich...@yahoo.com: you can rename the compiler's make.exe to make.ex, that will make it go away without deleting it, if you need it back, you can always rename it. another option is to simply change your PATH environment variable so that the compiler

Re: [Mingw-w64-public] fork is an inbuilt function?

2014-07-23 13:32 GMT+02:00 Óscar Fuentes o...@wanadoo.es: Ray Donnelly mingw.andr...@gmail.com writes: Hi Ruben, Please take this in the friendly/jokey manner it is intended. This isn't the first time you corrected me on the return value from main when I'm making a test-case to

Re: [Mingw-w64-public] r212448 - in /trunk: gcc/ChangeLog gcc/Makefile...

2014-07-16 11:44 GMT+02:00 Dongsheng Song dongsheng.s...@gmail.com: On Wed, Jul 16, 2014 at 12:37 AM, Rong Xu x...@google.com wrote: On Mon, Jul 14, 2014 at 11:02 PM, Dongsheng Song dongsheng.s...@gmail.com wrote: Hi Rong, Your commit r212448 broken Windows target 4 days. Since

  1   2   3   4   5   6   7   8   9   >