Why?
2015-09-19 20:16 GMT+03:00 Pecan :
> Please change the winpthreads license or get rid
> of GCC's winpthreads requirement.
>
>
>
>
> --
> ___
> Mingw-w64-public mailing lis
There are files in [1], if you browse into two more directories deeper.
2015-08-23 9:02 GMT+03:00 Martin Mitáš :
> Hello list,
>
> what's the status of the mingw-builds? I've noticed that [1] and [2] are
> just empty
> directories tries, there are actually no files offered for downloading.
>
> [
As Ruben wrote, winpthreads is not GPL at all.
Do you mean the "thread" include header? it uses GPL3 with GCC Runtime
Library Exception license, same as all other gcc include files. If not,
which files exactly do you refer to?
2015-08-19 12:03 GMT+03:00 Ruben Van Boxem :
> 2015-08-12 13:26 GMT+
>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 b
>I still get errors because libwinpthread-1.dll cannot be found even
The system PATH needs to include the directory where these DLLs are or you
can copy them to the directory where the compiled application resides.
2015-06-21 18:28 GMT+03:00 Edward Diener :
> On 6/21/2015 2:28 AM, Yaron
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 b
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 :
> Dear all,
>
> I have a small multithreaded application which keeps crashing after
> working for 7-10 days and
creveu:
>
>> 2015-06-08 10:07 GMT-03:00 Yaron Keren :
>>
>>> 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.
>>>
>>&g
C as well. 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
> escreveu:
>
>> This is a great idea.
>>
>> Regarding the license, isn&#x
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,
>
Anything to reduce mingw fragmentation would be good for new users. For
example, see
http://stackoverflow.com/questions/24581842/mingw-w64-vs-tdm-gcc-vs-othes-minor-distros-e-g-mingw-distro-nuwen-net
2015-05-29 7:39 GMT+03:00 Prasanna V. Loganathar :
> Hi,
>
> I had been using the builds as a p
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 :
> On 22.04.2015 14:02, Óscar Fuentes wrote:
> > LRN wri
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
dy
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 :
> Hello,
>
to 64 bits."
>
> That is 80-bit double extended 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
>
>
>
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 F
; !defined( __MWERKS__ ) &&
> !defined(__SALFORDC__) && !defined(__WXWINCE__) && !defined(__CYGWIN__)
> #include
> #include
> #include
> #endif // __WINDOWS__
> #endif // native Win compiler
>
>
> On Wed, Oct 29, 2014 at 10:23 PM, Yaro
Hi,
These _functions are in same as Visual C++.
Maybe filefn.cpp does not #include it?
Yaron
2014-10-30 0:51 GMT+02:00 Greg Jung :
> 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, win32):
>
> ../src/common/fi
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 :
> On 2014-10-10 10:12, Kai Tietz wrote:
> > Hi Ruben,
> >
> > this issue was reported
Thanks!
2014-10-03 11:01 GMT+03:00 niXman :
> 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 th
s not the default).
2 gettext-devel is required in the build.
3 If packages are missing, the script may suggest to run 'pacman -S p7zip
base-devel gettext-devel' to install all required packages at once.
Yaron
2014-10-03 2:29 GMT+03:00 Ray Donnelly :
> On Thu, Oct 2, 2014 at 10:
acman
-Syu.
2014-10-02 18:00 GMT+03:00 Yaron Keren :
> 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
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
--bin-compr
-mingw_i686-dbg.
>From where can I download this library?
Yaron
2014-09-08 14:20 GMT+03:00 LRN :
> On 08.09.2014 13:36, Yaron Keren wrote:
> > with MinGW 4.82 (and 4.91) on Windows 7 I get:
> >
> > $1 =
> >
> > whereas with gcc 4.82 on Ubuntu 14 I get the ful
Hi,
Compile and debug
#include
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 =
whereas with gcc 4.82 on Ubuntu 14 I get the full type:
(gdb) print f
$1 = { >> =
{ >> = { = {
_vptr.ios_base = 0x7fff
The mingw-w64 distribution includes gdb, in the same bin dir gcc is.
Yaron
2014-08-28 23:59 GMT+03:00 Edward Diener :
> 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
> something else ?
>
>
>
> -
s
of ligcc around.
Yaron
2014-08-25 11:23 GMT+03:00 Ruben Van Boxem :
> 2014-08-24 23:48 GMT+02:00 Yaron Keren :
>
> 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.
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++ -
Using i686-4.9.1-release-win32-dwarf-rt_v3-rev0.7z on Windows 7 64 bit,
with this simple code:
#include
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 exception is
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
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
-
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 t
32 matches
Mail list logo
