> -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? Cau
Hi Ingo,
On Tue, 04 Feb 2014 21:40:28 +0100, Ingo Maindorfer
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 available
on http://www.sk2
On 2/21/2014 04:04, Guo, Gcwenken wrote:
> 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. Ho
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:
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/Experimental_
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 c
2014-02-20 12:47 GMT+01:00 Hannes Domani :
> Hello
>
> Kai Tietz 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 other licenses you are using
Hello
Kai Tietz 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 other licenses you are using for just building a simple
> hello-world-application
Hi,
On Thu, Feb 20, 2014, Ciro Cornejo wrote:
> 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?
I think we will all skip the "toy" q
Interesting. Well that is even more good news if the issue is already fixed in
trunk!
Best regards!
Sebastian
> From: LRN
> Subject: Re: [Mingw-w64-public] Undefined symbol:
> __mingw_set_output_format using MinGW-w64 3.1.0
> To: mingw-w64-public@lists.sourceforge.net
>
>
> Glad to hear
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
-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 open
2014-02-20 10:19 GMT+01:00 LRN :
> -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]
> https://programmers.stackexchange.com/questions/178486/what-exact
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 __USE_M
-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
2014-02-20 1:16 GMT+01:00 Ciro Cornejo :
> 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 a compiler
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 loo
16 matches
Mail list logo