[Mingw-w64-public] Inconsistency between stdio.h and wchar.h re: _iob

Hello, stdio.h:82-96 #ifndef _STDIO_DEFINED #ifdef _WIN64 _CRTIMP FILE *__cdecl __iob_func(void); #define _iob __iob_func() #else #ifdef _MSVCRT_ extern FILE _iob[]; /* A pointer to an array of FILE */ #define __iob_func() (_iob) #else extern FILE (* __MINGW_IMP_SYMBOL(_iob))[]; /* A pointer

[Mingw-w64-public] _iob in wchar.h vs. stdio.h

Hello. As of v3.1.0 _iob is defined slightly different on the two locations, whcar.h:46-61 and stdio.h:82-96. The two definitions should probably be factored out to an internal shared header or at least be identical. Thanks, Yaron

Re: [Mingw-w64-public] Inconsistency between stdio.h and wchar.h re: _iob

Hello. As of v3.1.0 _iob* is defined slightly different on the two locations, whcar.h:46-61 and stdio.h:82-96. The two definitions should probably be factored out to an internal shared header between the two above or at least be identical. Thanks, Yaron 2013-12-11 15:02 GMT+02:00 Yaron

[Mingw-w64-public] exceptions weirdness

Using i686-4.9.1-release-win32-dwarf-rt_v3-rev0.7z on Windows 7 64 bit, with this simple code: #include stdio.h struct stype { ~stype() {} }; void t() { stype s; throw 1; } int main() { try { t(); } catch (...) { puts(Caught); } } When compiling with: gcc a.cpp -lstdc++ a the

Re: [Mingw-w64-public] exceptions weirdness

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 force g++ to static link libgcc, the exception is still uncaught: g++

Re: [Mingw-w64-public] exceptions weirdness

around. Yaron 2014-08-25 11:23 GMT+03:00 Ruben Van Boxem vanboxem.ru...@gmail.com: 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

Re: [Mingw-w64-public] Debug application built with mingw64

The mingw-w64 distribution includes gdb, in the same bin dir gcc is. Yaron 2014-08-28 23:59 GMT+03:00 Edward Diener eldlistmaili...@tropicsoft.com: How do I debug a command line application built with Mingw64 on Windows ? Is there a gdb debugger that works natively under Windows or do I need

[Mingw-w64-public] Different libstdc++ debug info in MinGW vs Linux causes missing type debug info

Hi, Compile and debug #include fstream int main() { std::ofstream f(foo.txt); } g++ a.cpp -g gdb b main r n print f with MinGW 4.82 (and 4.91) on Windows 7 I get: $1 = incomplete type whereas with gcc 4.82 on Ubuntu 14 I get the full type: (gdb) print f $1 = {std::basic_ostreamchar,

Re: [Mingw-w64-public] Different libstdc++ debug info in MinGW vs Linux causes missing type debug info

-mingw_i686-dbg. From where can I download this library? Yaron 2014-09-08 14:20 GMT+03:00 LRN lrn1...@gmail.com: On 08.09.2014 13:36, Yaron Keren wrote: with MinGW 4.82 (and 4.91) on Windows 7 I get: $1 = incomplete type whereas with gcc 4.82 on Ubuntu 14 I get the full type: (gdb) print

[Mingw-w64-public] Trying to build mingw, gcc misses include path

Hi, I am trying to build mingw-w64. I followed all steps from the README and git clone https://github.com/niXman/mingw-builds/ --branch develop ./build --mode=gcc-4.9.1 --buildroot=/c/mingw491 --rt-version=v3 --rev=1 --bootstrap --jobs=2 --threads=posix --exceptions=dwarf --arch=i686

Re: [Mingw-w64-public] Trying to build mingw, gcc misses include path

. 2014-10-02 18:00 GMT+03:00 Yaron Keren yaron.ke...@gmail.com: Hi, I am trying to build mingw-w64. I followed all steps from the README and git clone https://github.com/niXman/mingw-builds/ --branch develop ./build --mode=gcc-4.9.1 --buildroot=/c/mingw491 --rt-version=v3 --rev=1

Re: [Mingw-w64-public] Trying to build mingw, gcc misses include path

:59 PM, Yaron Keren yaron.ke...@gmail.com wrote: Well, something went wrong with MSYS2. I uninstalled MSYS2 and reinstalled, now libmangle compiles and build goes on. Odd. I did encounter a problem before with MSYS2 while doing pacman -Syu, there were errors and the upgrade wasn't complete

Re: [Mingw-w64-public] Trying to build mingw, gcc misses include path

Thanks! 2014-10-03 11:01 GMT+03:00 niXman i.nix...@autistici.org: Yaron Keren 2014-10-03 10:26: Hi, 1 The develop branch should be checked out to get the gcc-4.9.1 script. (checking out non master is not the default). done. 2 gettext-devel is required in the build. I'll fix it soon

Re: [Mingw-w64-public] Installer nonfunctional

AVG antivirus delays running of new EXE files until it analyzes them for the first time but this shouldn't break anything. I have never seen MSE cause such trouble. Yaron 2014-10-10 11:41 GMT+03:00 Ivo Doko ivo.d...@gmail.com: On 2014-10-10 10:12, Kai Tietz wrote: Hi Ruben, this issue

Re: [Mingw-w64-public] undefined references

Hi, These _functions are in direct.h same as Visual C++. Maybe filefn.cpp does not #include it? Yaron 2014-10-30 0:51 GMT+02:00 Greg Jung gvj...@gmail.com: Hi all, Just as a matter of example, I run into the following error compiling wxMSW-2.8.12 using mingw/msys- gcc-4.8.2 (sjlj,

Re: [Mingw-w64-public] undefined references

) !defined(__SALFORDC__) !defined(__WXWINCE__) !defined(__CYGWIN__) #include direct.h #include dos.h #include io.h #endif // __WINDOWS__ #endif // native Win compiler On Wed, Oct 29, 2014 at 10:23 PM, Yaron Keren yaron.ke...@gmail.com wrote: Hi, These _functions are in direct.h

Re: [Mingw-w64-public] FPU control word on startup

http://msdn.microsoft.com/en-us/library/e9b52ceh.aspx I think three issues are conflated: 1 long double size is 80 bits in mingw and 64 bits in VC. 2 The mask 0x27F will set the 80-bit extended computation precision, _PC_64 (64/80) and not _PC_53 (53/64) computation precision. This is internal

Re: [Mingw-w64-public] FPU control word on startup

computation precision as default and definitly not the expected double computation precision. See also: http://sourceforge.net/p/mingw/bugs/904/ https://ghc.haskell.org/trac/ghc/ticket/7289 Carl 2014-11-23 10:52 GMT+01:00 Yaron Keren yaron.ke...@gmail.com: http://msdn.microsoft.com/en-us

Re: [Mingw-w64-public] windows 32 bit memory address space

You are probably using gcc to link the application. If so, add -Wl,--large-address-aware to gcc flags when building it and the exe would be able to use 3GB of memory instead of 2. That option worked for my gcc-compiled app on Windows 7 64 bit. 2014-12-16 1:37 GMT+02:00 Rashad M

Re: [Mingw-w64-public] static libgcc in multiple shared libraries

Hi, Having different libgcc copies used from different parts of your program may be a big problem or not, depending upon how it is used in your program. Different libgccs do not share data, so C++ exceptions will not work between different libgccs. Your C program may not care for exceptions but

Re: [Mingw-w64-public] std::thread and memory leaks

stderr is not likely to show up anywhere with a GUI program. The standard practice in Windows is to use OutputDebugString. https://msdn.microsoft.com/en-us/library/windows/desktop/aa363362%28v=vs.85%29.aspx 2015-04-22 14:15 GMT+03:00 LRN lrn1...@gmail.com: On 22.04.2015 14:02, Óscar Fuentes

Re: [Mingw-w64-public] Native TLS support

This is a great idea. Regarding the license, isn't mingw-w64 released under a public domain or CC0 license? http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/5238f91b.7010...@tdragon.net/ 2015-06-08 15:41 GMT+03:00 Alexandre Pereira Nunes alexandre.nu...@gmail.com: Hi, I

Re: [Mingw-w64-public] Native TLS support

. The bureaucracies are regarding the Free Software Foundation Copyright claims on it, they need a copyright transfer or waiver. Em seg, 8 de jun de 2015 às 09:52, Yaron Keren yaron.ke...@gmail.com escreveu: This is a great idea. Regarding the license, isn't mingw-w64 released under a public domain

Re: [Mingw-w64-public] Native TLS support

escreveu: 2015-06-08 10:07 GMT-03:00 Yaron Keren yaron.ke...@gmail.com: Ah yes, for gcc it is required. Have you looked at clang implementation? it support native TLS, it would be really nice if the implementation would be compatible. Yeah it would be nice indeed. Few days ago a tried to build

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

/21/2015 2:28 AM, Yaron Keren wrote: The mingw-builds distro uses relative paths had worked well in any install location for the past two years at least. http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/ It also includes

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

Why in the world should I have to put anything in my PATH if these releases are self-enclosed ? I am executing gcc from the exact same directory where the libwinpthread-1.dll exists. I misunderstood you, thought you refer to running compiled apps not gcc. It's very convenient to have the gcc bin

Re: [Mingw-w64-public] win64 random crash

This is the likely the result of out of memory, maybe the app is leaking memory. Watch its memory usage over the days and see if it's growing. 2015-06-20 16:43 GMT+03:00 Ragnar Rüütel ragnar.ruu...@gmail.com: Dear all, I have a small multithreaded application which keeps crashing after

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

The mingw-builds distro uses relative paths had worked well in any install location for the past two years at least. http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/ It also includes the absolute path of the build original location

Re: [Mingw-w64-public] change the winpthreads license

Why? 2015-09-19 20:16 GMT+03:00 Pecan : > Please change the winpthreads license or get rid > of GCC's winpthreads requirement. > > > > > -- > ___ >