Hi,
On Sat, Sep 14, 2013, Kai Tietz wrote:
> 2013/9/14 JonY :
> > Trunk is already the devel branch, /stable/* is for stable users. what
> > we could do is make a new "/testing" that constantly have safe and
> > proven changes merged from /trunk, kind of like debian-testing, where
> > trunk is Sid
2013/9/14 JonY :
> On 9/14/2013 02:45, Ozkan Sezer wrote:
>> On 9/13/13, Kai Tietz wrote:
>>> Well, I consider, if we might want to define _FORCENAMELESSUNION in
>>> _mingw.h for 3.0, and remove it on our trunk. By this we reduce
>>> fallout right now, provide a version check later on for changed
On 9/14/2013 02:45, Ozkan Sezer wrote:
> On 9/13/13, Kai Tietz wrote:
>> Well, I consider, if we might want to define _FORCENAMELESSUNION in
>> _mingw.h for 3.0, and remove it on our trunk. By this we reduce
>> fallout right now, provide a version check later on for changed
>> behavior.
>
> I don
Vadim writes:
> To me, LGPL and GPL w/exception look substantially the same.
It depends on what the exception is. The exception used for the GCC
libraries avoids GPL infection for the programs that use those libraries
*and* discharges the user from the obligation of distributing source
code. LGP
To me, LGPL and GPL w/exception look substantially the same. So I don't
see how pthreads-win32 would add much to the burden that users already have
because of libgcc.
Anyhow. I don't suppose I'll convince you guys to change your mind at this
juncture...
I opened a bug about this issue:
https://s
2013/9/13 dw :
>
>> Hmm, as more as I look on this change in winnt.h, as more I
>> see that removing of the intrin.h header include is a failure.
> It is hard for me to respond to this since you provide no details or
> examples of situations that might cause problems.
>
> I can only point out that
Well, I consider, if we might want to define _FORCENAMELESSUNION in
_mingw.h for 3.0, and remove it on our trunk. By this we reduce
fallout right now, provide a version check later on for changed
behavior.
By this experience - as it must be possible to modify things on our
trunk and our release c
On 9/13/13, Kai Tietz wrote:
> Well, I consider, if we might want to define _FORCENAMELESSUNION in
> _mingw.h for 3.0, and remove it on our trunk. By this we reduce
> fallout right now, provide a version check later on for changed
> behavior.
I don't know the specifics about that fallout, but is
> Hmm, as more as I look on this change in winnt.h, as more I
> see that removing of the intrin.h header include is a failure.
It is hard for me to respond to this since you provide no details or
examples of situations that might cause problems.
I can only point out that MS does not include intr
On 9/6/2013 18:43, JonY wrote:
> Hello all,
>
> We will be releasing v3 from trunk soon. Testers, please check with the
> latest trunk version if any of the changes break your applications!
>
> Some of the new changes since v2 include:
>
> * Improved floating point math performance
> * Improved
On Fri, Sep 13, 2013 at 8:49 AM, John E. / TDM wrote:
> On 9/13/2013 1:28 AM, Adrien Nader wrote:
>> On Thu, Sep 12, 2013, John E. / TDM wrote:
>>> This is absolutely the case. The pthreads-win32 library is LGPL, forcing
>>> the distribution of its source code along with all binary distributions
>
On 9/13/2013 1:28 AM, Adrien Nader wrote:
> On Thu, Sep 12, 2013, John E. / TDM wrote:
>> This is absolutely the case. The pthreads-win32 library is LGPL, forcing
>> the distribution of its source code along with all binary distributions
>> -- and since all binaries compiled by a pthreads-enabled G
--
Kai Köhne, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
Koehne Kai schreef op vr 13-09-2013 om 09:21 [+]:
> > The above toolchains work just fine with the patches ... However, with the
> >
> > http://sourceforge.net/projects/mingw-
> > w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-
> > builds/4.8.1/threads-win32/dwarf/x32-4.8.1
Kai Tietz schreef op vr 13-09-2013 om 11:24 [+0200]:
> HI,
>
> we had in the past already the idea to add svn-revision-number to
> identify version proper. See for this in the mingw-w64-crt/ folder
> the header revstamp.h (a side-note ... actual the place should be
> IMHO instead the mingw-w64-i
HI,
we had in the past already the idea to add svn-revision-number to
identify version proper. See for this in the mingw-w64-crt/ folder
the header revstamp.h (a side-note ... actual the place should be
IMHO instead the mingw-w64-include folder ). We would need a
server for doing this stamp
> > -Original Message-
> > From: Erik van Pienbroek [mailto:e...@vanpienbroek.nl]
> > Sent: Thursday, September 12, 2013 1:00 PM
> > To: mingw-w64-public@lists.sourceforge.net
> > Subject: Re: [Mingw-w64-public] mingw-w64 v3 release calling for
> > testers
> >
> > Koehne Kai schreef op do 1
> -Original Message-
> From: Erik van Pienbroek [mailto:e...@vanpienbroek.nl]
> Sent: Thursday, September 12, 2013 1:00 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers
>
> Koehne Kai schreef op do 12-09-2013 om 06
On Thu, Sep 12, 2013, Vadim wrote:
> But aren't gcc compiled binaries already dependent on libgcc?
libgcc has a license exception which I don't know very well but which
should answer your questions. Look at its license.
--
Adrien Nader
---
On Thu, Sep 12, 2013, John E. / TDM wrote:
> This is absolutely the case. The pthreads-win32 library is LGPL, forcing
> the distribution of its source code along with all binary distributions
> -- and since all binaries compiled by a pthreads-enabled GCC depend on
> the pthreads library, everyon
20 matches
Mail list logo
