2011/8/7 Farkas Levente :
> On 08/07/2011 09:40 PM, Kai Tietz wrote:
>> Hello everybody,
>>
>> We proudly announce that we released the new version 2.0 of the
>> mingw-w64 runtime and header-set today.
>> We have to thank many people for contributions to mingw-w64 that
>> made this new release to h
On 08/08/2011 09:01 AM, Kai Tietz wrote:
> 2011/8/7 Farkas Levente :
>> On 08/07/2011 09:40 PM, Kai Tietz wrote:
>>> Hello everybody,
>>>
>>> We proudly announce that we released the new version 2.0 of the
>>> mingw-w64 runtime and header-set today.
>>> We have to thank many people for contribution
On Mon, Aug 8, 2011 at 9:59 AM, Farkas Levente wrote:
> On 08/08/2011 09:01 AM, Kai Tietz wrote:
> > 2011/8/7 Farkas Levente :
> >> On 08/07/2011 09:40 PM, Kai Tietz wrote:
> >>> Hello everybody,
> >>>
> >>> We proudly announce that we released the new version 2.0 of the
> >>> mingw-w64 runtime a
2011/8/8 Vincent Torri :
>
>
> On Mon, Aug 8, 2011 at 9:59 AM, Farkas Levente wrote:
>>
>> On 08/08/2011 09:01 AM, Kai Tietz wrote:
>> > 2011/8/7 Farkas Levente :
>> >> On 08/07/2011 09:40 PM, Kai Tietz wrote:
>> >>> Hello everybody,
>> >>>
>> >>> We proudly announce that we released the new versi
On Mon, Aug 8, 2011 at 10:43 AM, Ruben Van Boxem
wrote:
> 2011/8/8 Vincent Torri :
> >
> >
> > On Mon, Aug 8, 2011 at 9:59 AM, Farkas Levente
> wrote:
> >>
> >> On 08/08/2011 09:01 AM, Kai Tietz wrote:
> >> > 2011/8/7 Farkas Levente :
> >> >> On 08/07/2011 09:40 PM, Kai Tietz wrote:
> >> >>> Hell
Hi all,
although I appreciate the hard work on the mingw-w64 project, I must agree
here with the voices calling for more transparent release policies. Now
it's really a pain.
I think mingw-w64 forum and mailing lists already presented a frustration
of community about this.
Consider for example t
2011/8/8 :
> Hi all,
>
> although I appreciate the hard work on the mingw-w64 project, I must agree
> here with the voices calling for more transparent release policies. Now
> it's really a pain.
>
> I think mingw-w64 forum and mailing lists already presented a frustration
> of community about thi
On Mon, Aug 8, 2011 at 2:24 AM, Vincent Torri wrote:
>
>
> On Mon, Aug 8, 2011 at 4:29 AM, NightStrike wrote:
>>
>> On Fri, Aug 5, 2011 at 3:36 PM, Jon wrote:
>> > 1) Strip -s on all exes. I maintain a build recipe at
>> > https://github.com/oneclick/rubyinstaller which aggregates MSys and the
>
On Mon, Aug 8, 2011 at 4:43 AM, Ruben Van Boxem
wrote:
> Perhaps a release-buildbot should fire up an "official release" every
> two weeks, be tested quickly before upload, and put in a nice seperate
> "releases" directory. Somewhat a Personal Build, but automated. This
> would take some time and
On Mon, Aug 8, 2011 at 3:59 AM, Farkas Levente wrote:
> and some kind of wiki which describe the recommended binutils and gcc
> and other toolchains. it's also missing.
There are a number of wiki pages, such as:
http://sourceforge.net/apps/trac/mingw-w64/wiki/download%20filename%20structure
On 08/08/2011 12:49 PM, Kai Tietz wrote:
> I agree that we need to setup a fixed way how releases need to be
> done. I think a time-based schedule for this could be a good
> approach. As in general our runtime isn't necessarly strict bound to
> a specific gcc or binutils version. Most dependenci
> I wrote up some base information on our Wiki to describe things in
> more detail. Especially the download-section looks on the first
> glance a bit weird,
>
> Please read in our Wiki
> https://sourceforge.net/apps/trac/mingw-w64/wiki/Structure%20on%20SF%20download%20page
> for some more details
2011/8/8 :
>> I wrote up some base information on our Wiki to describe things in
>> more detail. Especially the download-section looks on the first
>> glance a bit weird,
>>
>> Please read in our Wiki
>> https://sourceforge.net/apps/trac/mingw-w64/wiki/Structure%20on%20SF%20download%20page
>> for
2011/8/8 :
>> I wrote up some base information on our Wiki to describe things in
>> more detail. Especially the download-section looks on the first
>> glance a bit weird,
>>
>> Please read in our Wiki
>> https://sourceforge.net/apps/trac/mingw-w64/wiki/Structure%20on%20SF%20download%20page
>> for
On Mon, Aug 8, 2011 at 3:02 PM, Farkas Levente wrote:
> On 08/08/2011 12:49 PM, Kai Tietz wrote:
>> I agree that we need to setup a fixed way how releases need to be
>> done. I think a time-based schedule for this could be a good
>> approach. As in general our runtime isn't necessarly strict bou
On 08/08/2011 02:56 PM, Ozkan Sezer wrote:
> On Mon, Aug 8, 2011 at 3:02 PM, Farkas Levente wrote:
>> On 08/08/2011 12:49 PM, Kai Tietz wrote:
>>> I agree that we need to setup a fixed way how releases need to be
>>> done. I think a time-based schedule for this could be a good
>>> approach. As i
On Mon, Aug 1, 2011 at 11:54 PM, Alen Skondro wrote:
> possible break for me is r4279.
>
>
> On Mon, Aug 1, 2011 at 11:45 PM, Alen Skondro wrote:
>
>> Hello guys,
>>
>> I have this strange error. It didn't happen a month ago.
>>
>> In file included from
>> d:\pwgcc-native\bin\../lib/gcc/i686-w64
> > Where's the source for this automated build recipe? I'd like to look it
> > over to determine if I've got enough time to work up patch series for your
> > review that does the following:
>
> Hi; sorry about the delay. The automated builds are done via this makefile:
>
> http://mingw-w64.sv
Hello everybody,
I am pleased to be able to tell you, that we could convience Ruben to
become our new packager-maintainer for pre-build toolchains for
releases. Please give him a warm welcome and support him in his new
role.
Regards,
Kai
On Mon, Aug 8, 2011 at 5:40 PM, Kai Tietz wrote:
> Hello everybody,
>
> I am pleased to be able to tell you, that we could convience Ruben to
> become our new packager-maintainer for pre-build toolchains for
> releases. Please give him a warm welcome and support him in his new
> role.
Good luck
On 8/8/2011 21:54, Jon wrote:
>>> 2) Add prefix-stripped (eg - gcc) exes to the download to accompany the
>>> prefixed (eg - i686-w64-mingw32-gcc) exes.
>>
>> Why?
>
> Not all downstream packages or users play well with the prefixing
>
>
> http://hg.python.org/cpython/file/4feb889d3bed/Lib/di
On 8/8/2011 22:43, Ozkan Sezer wrote:
> On Mon, Aug 8, 2011 at 5:40 PM, Kai Tietz wrote:
>> Hello everybody,
>>
>> I am pleased to be able to tell you, that we could convience Ruben to
>> become our new packager-maintainer for pre-build toolchains for
>> releases. Please give him a warm welcome
Dear mingw-w64 developers,
You guys rock, let that be clear ;-)
Kai and me have been discussing a proper release build setup for
mingw-w64. I would become the release packager dude that makes sure
proper releases are... released.
I would like to make some things clear first:
- Linux binary rel
On 8/8/2011 22:43, Ozkan Sezer wrote:
> On Mon, Aug 8, 2011 at 5:40 PM, Kai Tietz wrote:
>> Hello everybody,
>>
>> I am pleased to be able to tell you, that we could convience Ruben to
>> become our new packager-maintainer for pre-build toolchains for
>> releases. Please give him a warm welcome
On Mon, Aug 8, 2011 at 6:02 PM, Ruben Van Boxem
wrote:
> Dear mingw-w64 developers,
>
> You guys rock, let that be clear ;-)
>
> Kai and me have been discussing a proper release build setup for
> mingw-w64. I would become the release packager dude that makes sure
> proper releases are... released.
2011/8/8 JonY :
> On 8/8/2011 21:54, Jon wrote:
2) Add prefix-stripped (eg - gcc) exes to the download to accompany the
prefixed (eg - i686-w64-mingw32-gcc) exes.
>>>
>>> Why?
>>
>> Not all downstream packages or users play well with the prefixing
>>
>>
>> http://hg.python.org/cpython
>>
>> This is nice, but far from enough. There should be clear policy who from
>> the team is responsible for release management, how often (approx.) you
>> plan to release (e.g. 2 times a year or every month), if there is any
>> public RC (and for how long before the planned final release), so
>>
2011/8/8 Ozkan Sezer :
> On Mon, Aug 8, 2011 at 6:02 PM, Ruben Van Boxem
> wrote:
>> Dear mingw-w64 developers,
>>
>> You guys rock, let that be clear ;-)
>>
>> Kai and me have been discussing a proper release build setup for
>> mingw-w64. I would become the release packager dude that makes sure
>
On 8/8/2011 23:14, Ruben Van Boxem wrote:
> 2011/8/8 JonY :
>> On 8/8/2011 21:54, Jon wrote:
> 2) Add prefix-stripped (eg - gcc) exes to the download to accompany the
> prefixed (eg - i686-w64-mingw32-gcc) exes.
Why?
>>>
>>> Not all downstream packages or users play well with the
On Mon, Aug 8, 2011 at 9:54 AM, Jon wrote:
>> This is what the install-strip make target is for. Don't do it
>> manually. Just call make install-strip instead of make install.
>
> For the automated mingw downloads, I believe the exes should be stripped
> either as part of a deployment target or
On Mon, Aug 8, 2011 at 6:31 PM, Ruben Van Boxem
wrote:
> 2011/8/8 Ozkan Sezer :
>> On Mon, Aug 8, 2011 at 6:02 PM, Ruben Van Boxem
>> wrote:
>>> Dear mingw-w64 developers,
>>>
>>> You guys rock, let that be clear ;-)
>>>
>>> Kai and me have been discussing a proper release build setup for
>>> min
On 8/8/2011 23:11, Ozkan Sezer wrote:
>> --> Sums up to 14 binary packages.
>> - Details:
>> --> I plan to build all prerequisites statically, prevents missing
>> dependencies on Linux etc... (which often do not have tha latest
>> cloog/ppl/gmp/mpfr/mpc)
>
> Only glibc then. What glibc versi
On Mon, Aug 8, 2011 at 6:40 PM, JonY wrote:
> On 8/8/2011 23:11, Ozkan Sezer wrote:
>>> --> Sums up to 14 binary packages.
>>> - Details:
>>> --> I plan to build all prerequisites statically, prevents missing
>>> dependencies on Linux etc... (which often do not have tha latest
>>> cloog/ppl/g
On Mon, Aug 8, 2011 at 11:40 AM, Kai Tietz wrote:
> Hello everybody,
>
> I am pleased to be able to tell you, that we could convience Ruben to
> become our new packager-maintainer for pre-build toolchains for
> releases. Please give him a warm welcome and support him in his new
> role.
>
Great
On Mon, Aug 8, 2011 at 12:20 AM, Mook wrote:
>
>>> 3) Compress the final download using LZMA2 to a *.7z similar to what Ruben
>>> provides. Given the robustness and availability of the 7-Zip project, I
>>> don't believe there's a good reason to stick with zip's for Windows users.
>>
>> zip on wi
On Mon, Aug 8, 2011 at 12:40 PM, Ozkan Sezer wrote:
>>
>> Yeah, a 7z .exe sfx thingie. If you have 7zip, you can open it as an
>> archive, if not, you can double-click it and it will extract.
>
> Umm, I meant a real zip-sfx (self extracting zip which you can
> actually run through unzip.) Howver,
于 2011/8/8 23:07, Ruben Van Boxem 写道:
> do build winpthreads instead of including the ancient pthreads-win32.
>
> Let's hope this isn't harder than I anticipate:)
>
> Ruben
Er, the winpthreads is not usable in my here, see the mail list between
Kai and I about winpthreads...
pthreads-w32 is very
2011/8/8 Ozkan Sezer :
> On Mon, Aug 8, 2011 at 6:40 PM, JonY wrote:
>> On 8/8/2011 23:11, Ozkan Sezer wrote:
--> Sums up to 14 binary packages.
- Details:
--> I plan to build all prerequisites statically, prevents missing
dependencies on Linux etc... (which often do not h
> >> Yeah, a 7z .exe sfx thingie. If you have 7zip, you can open it as an
> >> archive, if not, you can double-click it and it will extract.
> >
> > Umm, I meant a real zip-sfx (self extracting zip which you can
> > actually run through unzip.) Howver, 7z should be acceptable
> > too.
> >
> > My
2011/8/8 PcX :
> 于 2011/8/8 23:07, Ruben Van Boxem 写道:
>> do build winpthreads instead of including the ancient pthreads-win32.
>>
>> Let's hope this isn't harder than I anticipate:)
>>
>> Ruben
> Er, the winpthreads is not usable in my here, see the mail list between
> Kai and I about winpthreads.
于 2011/8/9 0:53, Ruben Van Boxem 写道:
GCC's --enable-threads=posix is unusable with winpthread, but it is
equally so for pthreads-win32 I would say. The library itself is very
usable (I just ran the test suite on MSYS, after copying all the libs
to have the expected names.
I never uploaded a posi
2011/8/8 PcX :
> 于 2011/8/9 0:53, Ruben Van Boxem 写道:
>
> GCC's --enable-threads=posix is unusable with winpthread, but it is
> equally so for pthreads-win32 I would say. The library itself is very
> usable (I just ran the test suite on MSYS, after copying all the libs
> to have the expected names.
于 2011/8/9 1:06, Ruben Van Boxem 写道:
> Ah, right, it was a libgomp thing. Hmm... can't help there:(
So I am only able to use pthreads-w32 :-[ , and the pthreads-w32 cvs is
very new, and improve many 64bit compatibilities.:-)
--
Best Regards,
PcX
Hi all!
I succes build with posix threads.
I add the nanosleep function in the include/c++/4.x.x/thread file.
And all works ;)
http://code.google.com/p/mingw-builds/downloads/list
p.s.
кто-то говорит на Русском?
--
BlackB
On 08/08/2011 05:02 PM, Ruben Van Boxem wrote:
> - What we agreed on about versioning:
>--> mingw-w64 should adopt a semi-rolling release model. It's
> source only, so (Linux) packagers should just pick a (release) branch
> and use its latest revision.
it's a support nightmare! how can one kn
any way you choose, you are going to be making a lot of directories with a few
files in each if you choose to structure it.
another option is
-
Linux
/Release
+- 2.0.0
+- 2.0.1
/Snapshots
/Personal Builds
Toolchains Targeting Win3
46 matches
Mail list logo
