Re: [Mingw-w64-public] build cross compiler mingw w64 gcc 4.8.2 on linux with winpthreads

2014-02-20 Thread Koehne Kai
> -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

Re: [Mingw-w64-public] Cross compiling the compiler on Linux

2014-02-20 Thread Stephen Kitt
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

Re: [Mingw-w64-public] build cross compiler mingw w64 gcc 4.8.2 on linux with winpthreads

2014-02-20 Thread JonY
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

[Mingw-w64-public] New builds of GCC-trunk

2014-02-20 Thread niXman
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_

[Mingw-w64-public] build cross compiler mingw w64 gcc 4.8.2 on linux with winpthreads

2014-02-20 Thread Guo, Gcwenken
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

Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler

2014-02-20 Thread Kai Tietz
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

Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler

2014-02-20 Thread 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 for just building a simple > hello-world-application

Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler

2014-02-20 Thread Adrien Nader
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

Re: [Mingw-w64-public] Undefined symbol: __mingw_set_output_format using MinGW-w64 3.1.0

2014-02-20 Thread Sebastian Wolff
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

Re: [Mingw-w64-public] Undefined symbol: __mingw_set_output_format using MinGW-w64 3.1.0

2014-02-20 Thread Jacek Caban
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

Re: [Mingw-w64-public] Undefined symbol: __mingw_set_output_format using MinGW-w64 3.1.0

2014-02-20 Thread LRN
-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

Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler

2014-02-20 Thread Kai Tietz
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

Re: [Mingw-w64-public] Undefined symbol: __mingw_set_output_format using MinGW-w64 3.1.0

2014-02-20 Thread Sebastian Wolff
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

Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler

2014-02-20 Thread LRN
-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

Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler

2014-02-20 Thread Kai Tietz
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

[Mingw-w64-public] Sigh! Back To Microsoft Compiler

2014-02-20 Thread Ciro Cornejo
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