Seriously? !!!
Come on guys, this makes the compiler unusable.
...but as long as you're making a toy compiler, would you consider making one
that does not support pthreads and so avoids this problem?
Thanks.
Hi! Sorry for the interruption, but you may want to take at least a few seconds
to
2014-02-20 1:16 GMT+01:00 Ciro Cornejo ciro.corn...@wdc.com:
Seriously? !!!
Come on guys, this makes the compiler unusable.
What?
...but as long as you're making a toy compiler, would you consider making
one that does not support pthreads and so avoids this problem?
Why we should make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20.02.2014 13:14, Kai Tietz wrote:
On 2014-02-20 1:16 GMT+01:00 Ciro Cornejo wrote:
Seriously? !!!
Come on guys, this makes the compiler unusable.
What?
...but as long as you're making a toy compiler, would you
consider making
Dear list,
I finally found a solution.
The dirty fix is to add an additional define in each compiler call. A better
way is to modify the spec file of GCC. Therein you need to add the following
define at an appropriate place:
-D__USE_MINGW_OUTPUT_FORMAT_EMU=0
By default, MinGW assumes
2014-02-20 10:19 GMT+01:00 LRN lrn1...@gmail.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
To be precise, it's a MIT license[1]. The text OP is referring to is
explained in [2].
[1] https://en.wikipedia.org/wiki/MIT_License
[2]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20.02.2014 13:20, Sebastian Wolff wrote:
On 19 Feb 2014, at 17:05, Sebastian Wolff wrote:
today I upgraded from a SVN revision from March 2013 of the
MinGW-w64 runtime to version 3.1.0. I use the open build service
provided by the openSUSE
Hi,
On the trunk, we no longer need __USE_MINGW_OUTPUT_FORMAT_EMU nor
__mingw_set_output_format. We use linker tricks to do the work without
any user action:
http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/53e6165916a0cdc4d096bff13ce60cb825def2f2
Note that the change affected both headers and
Interesting. Well that is even more good news if the issue is already fixed in
trunk!
Best regards!
Sebastian
From: LRN lrn1...@gmail.com
Subject: Re: [Mingw-w64-public] Undefined symbol:
__mingw_set_output_format using MinGW-w64 3.1.0
To: mingw-w64-public@lists.sourceforge.net
2014-02-20 12:47 GMT+01:00 Hannes Domani ssb...@yahoo.de:
Hello
Kai Tietz ktiet...@googlemail.com schrieb am 10:14 Donnerstag, 20.Februar
2014:
I would advice you to look in more detail to license issues. MS
compiler has them, and gcc mingw(-w64) do so too. You will be
wondering what
Hi:
I want to build a cross compiler mingw-w64 gcc in x86_64-unknown-linux-gnu to
i686-w64-mingw32 with winphreads. From the document in the source package
mingw-w64-v3.1.0/mingw-w64-doc, I know how to build cross gcc with win32
thread. However, I need to use c++11 thread, so I need to build
Hi guys!
Just now I finished build GCC-trunk only with C/C++ support.
I can't build DWARF builds because this bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60244
i686 builds here:
Hi Ingo,
On Tue, 04 Feb 2014 21:40:28 +0100, Ingo Maindorfer i...@liquidcooling.de
wrote:
how was the talk? Is there a way to get your talk online?
I'm not really the right person to ask, but the audience seemed interested
enough and I discovered a few more MinGW-w64 users. My slides are
-Original Message-
From: JonY [mailto:jo...@users.sourceforge.net]
[...]
FYI dwarf2 exception is known to be broken for Windows.
The only defect I know of is that it doesn't support throwing exceptions
through native stacks (i.e. Windows handlers). Or is there anything else? Cause
13 matches
Mail list logo
