You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(55) |
Oct
(59) |
Nov
(3) |
Dec
(30) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(59) |
Feb
(22) |
Mar
(55) |
Apr
(4) |
May
(15) |
Jun
(29) |
Jul
(6) |
Aug
(17) |
Sep
|
Oct
(27) |
Nov
(8) |
Dec
(14) |
2009 |
Jan
(6) |
Feb
(26) |
Mar
(48) |
Apr
(11) |
May
(3) |
Jun
(20) |
Jul
(28) |
Aug
(48) |
Sep
(85) |
Oct
(34) |
Nov
(23) |
Dec
(65) |
2010 |
Jan
(68) |
Feb
(46) |
Mar
(105) |
Apr
(74) |
May
(185) |
Jun
(118) |
Jul
(179) |
Aug
(170) |
Sep
(513) |
Oct
(113) |
Nov
(41) |
Dec
(52) |
2011 |
Jan
(59) |
Feb
(102) |
Mar
(110) |
Apr
(197) |
May
(123) |
Jun
(91) |
Jul
(195) |
Aug
(209) |
Sep
(233) |
Oct
(112) |
Nov
(241) |
Dec
(86) |
2012 |
Jan
(138) |
Feb
(151) |
Mar
(326) |
Apr
(154) |
May
(278) |
Jun
(230) |
Jul
(311) |
Aug
(327) |
Sep
(194) |
Oct
(139) |
Nov
(243) |
Dec
(141) |
2013 |
Jan
(169) |
Feb
(90) |
Mar
(187) |
Apr
(228) |
May
(150) |
Jun
(328) |
Jul
(287) |
Aug
(199) |
Sep
(288) |
Oct
(199) |
Nov
(310) |
Dec
(214) |
2014 |
Jan
(166) |
Feb
(66) |
Mar
(90) |
Apr
(166) |
May
(166) |
Jun
(99) |
Jul
(120) |
Aug
(139) |
Sep
(107) |
Oct
(142) |
Nov
(171) |
Dec
(170) |
2015 |
Jan
(138) |
Feb
(100) |
Mar
(101) |
Apr
(83) |
May
(143) |
Jun
(148) |
Jul
(139) |
Aug
(174) |
Sep
(60) |
Oct
(52) |
Nov
(41) |
Dec
(59) |
2016 |
Jan
(40) |
Feb
(86) |
Mar
(121) |
Apr
(154) |
May
(78) |
Jun
(46) |
Jul
(71) |
Aug
(191) |
Sep
(96) |
Oct
(44) |
Nov
(85) |
Dec
(52) |
2017 |
Jan
(80) |
Feb
(65) |
Mar
(91) |
Apr
(66) |
May
(144) |
Jun
(115) |
Jul
(61) |
Aug
(301) |
Sep
(78) |
Oct
(96) |
Nov
(309) |
Dec
(59) |
2018 |
Jan
(99) |
Feb
(41) |
Mar
(88) |
Apr
(52) |
May
(62) |
Jun
(95) |
Jul
(49) |
Aug
(133) |
Sep
(79) |
Oct
(86) |
Nov
(145) |
Dec
(72) |
2019 |
Jan
(138) |
Feb
(68) |
Mar
(145) |
Apr
(203) |
May
(115) |
Jun
(70) |
Jul
(85) |
Aug
(55) |
Sep
(79) |
Oct
(50) |
Nov
(95) |
Dec
(155) |
2020 |
Jan
(63) |
Feb
(59) |
Mar
(135) |
Apr
(397) |
May
(180) |
Jun
(141) |
Jul
(36) |
Aug
(62) |
Sep
(92) |
Oct
(86) |
Nov
(86) |
Dec
(144) |
2021 |
Jan
(112) |
Feb
(44) |
Mar
(117) |
Apr
(112) |
May
(234) |
Jun
(86) |
Jul
(88) |
Aug
(113) |
Sep
(88) |
Oct
(109) |
Nov
(46) |
Dec
(54) |
2022 |
Jan
(104) |
Feb
(90) |
Mar
(95) |
Apr
(70) |
May
(51) |
Jun
(96) |
Jul
(76) |
Aug
(91) |
Sep
(101) |
Oct
(95) |
Nov
(126) |
Dec
(125) |
2023 |
Jan
(39) |
Feb
(64) |
Mar
(103) |
Apr
(107) |
May
(77) |
Jun
(162) |
Jul
(59) |
Aug
(59) |
Sep
(91) |
Oct
(273) |
Nov
(101) |
Dec
(183) |
2024 |
Jan
(148) |
Feb
(50) |
Mar
(35) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Luis L. <lui...@gm...> - 2013-08-01 00:59:04
|
Hello folks, As maintainer of RubyInstaller (binary distribution of Ruby on Windows), we opted to use Ruben's mingw-w64 binary packages as compiler toolchain and also as part of our DevKit, to allow users install and compile extensions to the language. A few days ago, a user reported an interesting case that shows issues with snprintf: https://github.com/oneclick/rubyinstaller/issues/186 The test case is simple, the following script: #include <stdio.h> #include <string.h> #include <assert.h> char small_buffer[10]; char *small_text = "123"; char *big_text = "12345678901234567890"; int main(int argc, char *argv[]) { int rc; // Text fits into buffer: snprintf returns length. rc = snprintf(small_buffer, sizeof(small_buffer), small_text); printf("small_text rc = %d\n", rc); assert(rc == strlen(small_text)); // Text too big for buffer: ANSI C99 snprintf should return required length. // Gnu/Linux follows ANSI C99. // MinGW is supposed to follow ANSI C99. // Windows is broken and fails this test. rc = snprintf(small_buffer, sizeof(small_buffer), big_text); printf("big_text rc = %d\n", rc); assert(rc > 0); return(0); } Compiled with mingw 4.7.2 (std=c99 or ANSI), this is the output: C:\Users\Luis\Code\_sandbox\scripts>gcc --version gcc (GCC) 4.7.2 C:\Users\Luis\Code\_sandbox\scripts>test-472-mingw.exe small_text rc = 3 big_text rc = 20 While either Ruben's or mingw-builds resulted in: C:\Users\Luis\Code\_sandbox\scripts>test-472-32.exe small_text rc = 3 big_text rc = -1 Assertion failed! Program: C:\Users\Luis\Code\_sandbox\scripts\test-472-32.exe File: test.snprintf.c, Line 24 Expression: rc > 0 Tested against: Ruben's 4.7.2 (packages): i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb.7z i686_64-w64-mingw32-mingw-w64-update-v2.0.7_rubenvb.7z mingw-builds 4.7.3 (packages): x32-4.7.3-release-win32-sjlj-rev1.7z Definitely I'm missing something here, so will appreciate any hint and suggestion. Thank you in advance. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry |
From: JonY <jo...@us...> - 2013-07-31 22:41:55
|
Hi, Cygwin should not be using the MS C runtime. Patch removes msvcr* msvcp60 and crtdll import library from w32api mode. Patch OK? |
From: Earnie B. <ea...@us...> - 2013-07-31 21:08:51
|
On Wed, Jul 31, 2013 at 3:47 PM, Kai Tietz <kti...@go...> wrote: > 2013/7/31 Baruch Burstein <bmb...@gm...>: >> On Wed, Jul 31, 2013 at 9:49 PM, Kai Tietz <kti...@go...> wrote: >>> >>> 2013/7/31 Earnie Boyd <ea...@us...>: >>> > On Wed, Jul 31, 2013 at 8:21 AM, Kai Tietz wrote: >>> >> >>> >> As there never was, and won't be in next future a target with ending >>> >> ...mingw64 in triplet. >>> >> >>> > >>> > That statement maybe here but not at MinGW.org. The x86_64-pc-mingw64 >>> > triplet is contained in the config master repository. >>> >>> That you added this triplet to this file doesn't make it right. Just >>> mingw.org (as venture) want to support that triplet at some day, but >>> no upstream toolchain-part (gcc, binutils, gdb, and dependent >>> libraries) supports it. >> >> >> I understood from JonY's answer that these triplets are arbitrary and don't >> really mean anything other then helping keep cross-compilers organized. So >> what do you mean that no upstream toolchain-part (gcc, binutils, gdb, and >> dependent libraries) supports it? > > What I am referring to is the 'x86_64-pc-mingw64' triplet used in this > config.guess file. Actual there is no support for the mingw64 triplet > part. Neither in binutils, nor in gcc. So this 64 is bogus and > should be replaced by 32. That doesn't mean they cannot in the future and one must start with the config master. This also supports MSYSTEM=MINGW64 and config.guess getting the build system correct for x86_64-pc-mingw64 with a 64 bit MSYS. > Longterm this mingw32 and mingw64 should be replaced simply by mingw. > this 32/64 is just bogus and is already covered by the architecture > part of triplet (i?86/x86_64). See the discussion beginning with https://sourceforge.net/p/mingw/mailman/message/31095908/ Synopsis is we want to retain mingw32 and mingw64 even though I wanted to drop 32 and 64. Secondarily I would like to see the default of i386 be changed to i686 in config.sub. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Kai T. <kti...@go...> - 2013-07-31 20:13:44
|
2013/7/31 Baruch Burstein <bmb...@gm...>: > On Wed, Jul 31, 2013 at 10:47 PM, Kai Tietz <kti...@go...> wrote: >> >> 2013/7/31 Baruch Burstein <bmb...@gm...>: >> > On Wed, Jul 31, 2013 at 9:49 PM, Kai Tietz <kti...@go...> >> > wrote: >> >> >> >> 2013/7/31 Earnie Boyd <ea...@us...>: >> >> > On Wed, Jul 31, 2013 at 8:21 AM, Kai Tietz wrote: >> >> >> >> >> >> As there never was, and won't be in next future a target with ending >> >> >> ...mingw64 in triplet. >> >> >> >> >> > >> >> > That statement maybe here but not at MinGW.org. The >> >> > x86_64-pc-mingw64 >> >> > triplet is contained in the config master repository. >> >> >> >> That you added this triplet to this file doesn't make it right. Just >> >> mingw.org (as venture) want to support that triplet at some day, but >> >> no upstream toolchain-part (gcc, binutils, gdb, and dependent >> >> libraries) supports it. >> > >> > >> > I understood from JonY's answer that these triplets are arbitrary and >> > don't >> > really mean anything other then helping keep cross-compilers organized. >> > So >> > what do you mean that no upstream toolchain-part (gcc, binutils, gdb, >> > and >> > dependent libraries) supports it? >> >> What I am referring to is the 'x86_64-pc-mingw64' triplet used in this >> config.guess file. Actual there is no support for the mingw64 triplet >> part. Neither in binutils, nor in gcc. > > > What do you mean "there is no support for this triplet"? As I said the triplet 'x86_64-pc-mingw64' isn't usable to configure a working toolchain. > What does it mean that they "support" it? I said "... there is no support ...". And as I said, it isn't supported as there is no such triplet. > > -- > ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı Kai |
From: Baruch B. <bmb...@gm...> - 2013-07-31 19:53:20
|
On Wed, Jul 31, 2013 at 10:47 PM, Kai Tietz <kti...@go...> wrote: > 2013/7/31 Baruch Burstein <bmb...@gm...>: > > On Wed, Jul 31, 2013 at 9:49 PM, Kai Tietz <kti...@go...> > wrote: > >> > >> 2013/7/31 Earnie Boyd <ea...@us...>: > >> > On Wed, Jul 31, 2013 at 8:21 AM, Kai Tietz wrote: > >> >> > >> >> As there never was, and won't be in next future a target with ending > >> >> ...mingw64 in triplet. > >> >> > >> > > >> > That statement maybe here but not at MinGW.org. The x86_64-pc-mingw64 > >> > triplet is contained in the config master repository. > >> > >> That you added this triplet to this file doesn't make it right. Just > >> mingw.org (as venture) want to support that triplet at some day, but > >> no upstream toolchain-part (gcc, binutils, gdb, and dependent > >> libraries) supports it. > > > > > > I understood from JonY's answer that these triplets are arbitrary and > don't > > really mean anything other then helping keep cross-compilers organized. > So > > what do you mean that no upstream toolchain-part (gcc, binutils, gdb, and > > dependent libraries) supports it? > > What I am referring to is the 'x86_64-pc-mingw64' triplet used in this > config.guess file. Actual there is no support for the mingw64 triplet > part. Neither in binutils, nor in gcc. > What do you mean "there is no support for this triplet"? What does it mean that they "support" it? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı |
From: Kai T. <kti...@go...> - 2013-07-31 19:47:20
|
2013/7/31 Baruch Burstein <bmb...@gm...>: > On Wed, Jul 31, 2013 at 9:49 PM, Kai Tietz <kti...@go...> wrote: >> >> 2013/7/31 Earnie Boyd <ea...@us...>: >> > On Wed, Jul 31, 2013 at 8:21 AM, Kai Tietz wrote: >> >> >> >> As there never was, and won't be in next future a target with ending >> >> ...mingw64 in triplet. >> >> >> > >> > That statement maybe here but not at MinGW.org. The x86_64-pc-mingw64 >> > triplet is contained in the config master repository. >> >> That you added this triplet to this file doesn't make it right. Just >> mingw.org (as venture) want to support that triplet at some day, but >> no upstream toolchain-part (gcc, binutils, gdb, and dependent >> libraries) supports it. > > > I understood from JonY's answer that these triplets are arbitrary and don't > really mean anything other then helping keep cross-compilers organized. So > what do you mean that no upstream toolchain-part (gcc, binutils, gdb, and > dependent libraries) supports it? What I am referring to is the 'x86_64-pc-mingw64' triplet used in this config.guess file. Actual there is no support for the mingw64 triplet part. Neither in binutils, nor in gcc. So this 64 is bogus and should be replaced by 32. Longterm this mingw32 and mingw64 should be replaced simply by mingw. this 32/64 is just bogus and is already covered by the architecture part of triplet (i?86/x86_64). > -- > ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı Kai |
From: Baruch B. <bmb...@gm...> - 2013-07-31 19:40:44
|
On Wed, Jul 31, 2013 at 9:49 PM, Kai Tietz <kti...@go...> wrote: > 2013/7/31 Earnie Boyd <ea...@us...>: > > On Wed, Jul 31, 2013 at 8:21 AM, Kai Tietz wrote: > >> > >> As there never was, and won't be in next future a target with ending > >> ...mingw64 in triplet. > >> > > > > That statement maybe here but not at MinGW.org. The x86_64-pc-mingw64 > > triplet is contained in the config master repository. > > That you added this triplet to this file doesn't make it right. Just > mingw.org (as venture) want to support that triplet at some day, but > no upstream toolchain-part (gcc, binutils, gdb, and dependent > libraries) supports it. > I understood from JonY's answer that these triplets are arbitrary and don't really mean anything other then helping keep cross-compilers organized. So what do you mean that no upstream toolchain-part (gcc, binutils, gdb, and dependent libraries) supports it? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı |
From: Kai T. <kti...@go...> - 2013-07-31 18:49:09
|
2013/7/31 Earnie Boyd <ea...@us...>: > On Wed, Jul 31, 2013 at 8:21 AM, Kai Tietz wrote: >> >> As there never was, and won't be in next future a target with ending >> ...mingw64 in triplet. >> > > That statement maybe here but not at MinGW.org. The x86_64-pc-mingw64 > triplet is contained in the config master repository. That you added this triplet to this file doesn't make it right. Just mingw.org (as venture) want to support that triplet at some day, but no upstream toolchain-part (gcc, binutils, gdb, and dependent libraries) supports it. So what you try to tell me? Something nobody supports is of some interest to anybody? > -- > Earnie > -- https://sites.google.com/site/earnieboyd Kai |
From: Earnie B. <ea...@us...> - 2013-07-31 18:36:15
|
On Wed, Jul 31, 2013 at 8:21 AM, Kai Tietz wrote: > > As there never was, and won't be in next future a target with ending > ...mingw64 in triplet. > That statement maybe here but not at MinGW.org. The x86_64-pc-mingw64 triplet is contained in the config master repository. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Baruch B. <bmb...@gm...> - 2013-07-31 13:49:52
|
Shouldn't it be updated to change x86_64-*pc*-mingw* to x86_64-*w64*-mingw*? On Wed, Jul 31, 2013 at 3:39 PM, JonY <jo...@us...> wrote: > On 7/31/2013 19:56, Earnie Boyd wrote: > > On Wed, Jul 31, 2013 at 5:52 AM, JonY wrote: > >> On 7/31/2013 17:21, Baruch Burstein wrote: > >>> The latest version of config.guess, when run on MSYS2 64bit (posted > >>> elsewhere on this list) with ruben's 64bit native compilers reports: > >>> x86_64-pc-mingw32 > >>> > >>> I recall somewhere that the correct triplet should be: > >>> x86_64-w64-mingw32 > >>> > >>> The relevant part of config.guess seems to be this: > >>> *:MINGW64*:*) > >>> echo ${UNAME_MACHINE}-pc-mingw64 > >>> exit ;; > >>> *:MINGW*:*) > >>> echo ${UNAME_MACHINE}-pc-mingw32 > >>> exit ;; > >>> i*:MSYS*:*) > >>> echo ${UNAME_MACHINE}-pc-msys > >>> exit ;; > >>> i*:windows32*:*) > >>> # uname -m includes "-pc" on this system. > >>> echo ${UNAME_MACHINE}-mingw32 > >>> exit ;; > >>> > > --8<-- > >> > >> Also, the MSYS bit should not be there. > >> > > > > Why not? It is in the master config.guess as updated by Chuck > > sometime last year. > > > > I was told several years earlier that not adding msys upstream was a > deliberate choice so it doesn't become another Cygwin. > > I guess things changed. > > > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı |
From: JonY <jo...@us...> - 2013-07-31 12:39:43
|
On 7/31/2013 19:56, Earnie Boyd wrote: > On Wed, Jul 31, 2013 at 5:52 AM, JonY wrote: >> On 7/31/2013 17:21, Baruch Burstein wrote: >>> The latest version of config.guess, when run on MSYS2 64bit (posted >>> elsewhere on this list) with ruben's 64bit native compilers reports: >>> x86_64-pc-mingw32 >>> >>> I recall somewhere that the correct triplet should be: >>> x86_64-w64-mingw32 >>> >>> The relevant part of config.guess seems to be this: >>> *:MINGW64*:*) >>> echo ${UNAME_MACHINE}-pc-mingw64 >>> exit ;; >>> *:MINGW*:*) >>> echo ${UNAME_MACHINE}-pc-mingw32 >>> exit ;; >>> i*:MSYS*:*) >>> echo ${UNAME_MACHINE}-pc-msys >>> exit ;; >>> i*:windows32*:*) >>> # uname -m includes "-pc" on this system. >>> echo ${UNAME_MACHINE}-mingw32 >>> exit ;; >>> > --8<-- >> >> Also, the MSYS bit should not be there. >> > > Why not? It is in the master config.guess as updated by Chuck > sometime last year. > I was told several years earlier that not adding msys upstream was a deliberate choice so it doesn't become another Cygwin. I guess things changed. |
From: Kai T. <kti...@go...> - 2013-07-31 12:21:31
|
2013/7/31 Earnie Boyd <ea...@us...>: > On Wed, Jul 31, 2013 at 5:52 AM, JonY wrote: >> On 7/31/2013 17:21, Baruch Burstein wrote: >>> The latest version of config.guess, when run on MSYS2 64bit (posted >>> elsewhere on this list) with ruben's 64bit native compilers reports: >>> x86_64-pc-mingw32 >>> >>> I recall somewhere that the correct triplet should be: >>> x86_64-w64-mingw32 >>> >>> The relevant part of config.guess seems to be this: >>> *:MINGW64*:*) >>> echo ${UNAME_MACHINE}-pc-mingw64 >>> exit ;; >>> *:MINGW*:*) >>> echo ${UNAME_MACHINE}-pc-mingw32 >>> exit ;; >>> i*:MSYS*:*) >>> echo ${UNAME_MACHINE}-pc-msys >>> exit ;; >>> i*:windows32*:*) >>> # uname -m includes "-pc" on this system. >>> echo ${UNAME_MACHINE}-mingw32 >>> exit ;; >>> > --8<-- >> >> Also, the MSYS bit should not be there. >> > > Why not? It is in the master config.guess as updated by Chuck > sometime last year. As there never was, and won't be in next future a target with ending ...mingw64 in triplet. > -- > Earnie > -- https://sites.google.com/site/earnieboyd Kai |
From: Earnie B. <ea...@us...> - 2013-07-31 11:56:33
|
On Wed, Jul 31, 2013 at 5:52 AM, JonY wrote: > On 7/31/2013 17:21, Baruch Burstein wrote: >> The latest version of config.guess, when run on MSYS2 64bit (posted >> elsewhere on this list) with ruben's 64bit native compilers reports: >> x86_64-pc-mingw32 >> >> I recall somewhere that the correct triplet should be: >> x86_64-w64-mingw32 >> >> The relevant part of config.guess seems to be this: >> *:MINGW64*:*) >> echo ${UNAME_MACHINE}-pc-mingw64 >> exit ;; >> *:MINGW*:*) >> echo ${UNAME_MACHINE}-pc-mingw32 >> exit ;; >> i*:MSYS*:*) >> echo ${UNAME_MACHINE}-pc-msys >> exit ;; >> i*:windows32*:*) >> # uname -m includes "-pc" on this system. >> echo ${UNAME_MACHINE}-mingw32 >> exit ;; >> --8<-- > > Also, the MSYS bit should not be there. > Why not? It is in the master config.guess as updated by Chuck sometime last year. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: JonY <jo...@us...> - 2013-07-31 09:53:19
|
On 7/31/2013 17:21, Baruch Burstein wrote: > The latest version of config.guess, when run on MSYS2 64bit (posted > elsewhere on this list) with ruben's 64bit native compilers reports: > x86_64-pc-mingw32 > > I recall somewhere that the correct triplet should be: > x86_64-w64-mingw32 > > The relevant part of config.guess seems to be this: > *:MINGW64*:*) > echo ${UNAME_MACHINE}-pc-mingw64 > exit ;; > *:MINGW*:*) > echo ${UNAME_MACHINE}-pc-mingw32 > exit ;; > i*:MSYS*:*) > echo ${UNAME_MACHINE}-pc-msys > exit ;; > i*:windows32*:*) > # uname -m includes "-pc" on this system. > echo ${UNAME_MACHINE}-mingw32 > exit ;; > > I don't understand how this triplet thingy works, but would like to know > what the correct host triplet is for each of the following, and if a change > is needed in the config.guess script: > "regular" windows executables (32bit) e.g. WinXP > "regular" windows executables (64bit) e.g. Win7(x64) > Windows is a bit special in this regard, just because it is Windows doesn't mean that there is only one way to target it, as you have noticed that there is more than a single triplet that work on Windows. Also, the MSYS bit should not be there. > Does mingw* at the end of the triplet mean "regular" windows programs? What > is msys at the end of the triplet? What is the difference between mingw32and > mingw64 at the end of the triplet? > No, the names don't have any special meaning, it is a more specific way to select a compiler toolchain. This makes cross compilation possible, eg build on Linux for Windows. It is hard to do this if all compilers were just called "gcc". > And finally, can someone explain/point me to an explanation of how these > triplets actually work? Do they really make any difference, or are they > just used as the prefix for the compiler chosen? If I rename my compiler > and tools to "a-silly-long-prefix-gcc", "a-silly-long-prefix-g++", > "a-silly-long-prefix-ar" etc, would I have a problem compiling like this: > > ./configure --host=a-silly-long-prefix > make See https://sourceforge.net/apps/trac/mingw-w64/wiki/TypeTriplets |
From: Baruch B. <bmb...@gm...> - 2013-07-31 09:21:53
|
The latest version of config.guess, when run on MSYS2 64bit (posted elsewhere on this list) with ruben's 64bit native compilers reports: x86_64-pc-mingw32 I recall somewhere that the correct triplet should be: x86_64-w64-mingw32 The relevant part of config.guess seems to be this: *:MINGW64*:*) echo ${UNAME_MACHINE}-pc-mingw64 exit ;; *:MINGW*:*) echo ${UNAME_MACHINE}-pc-mingw32 exit ;; i*:MSYS*:*) echo ${UNAME_MACHINE}-pc-msys exit ;; i*:windows32*:*) # uname -m includes "-pc" on this system. echo ${UNAME_MACHINE}-mingw32 exit ;; I don't understand how this triplet thingy works, but would like to know what the correct host triplet is for each of the following, and if a change is needed in the config.guess script: "regular" windows executables (32bit) e.g. WinXP "regular" windows executables (64bit) e.g. Win7(x64) Does mingw* at the end of the triplet mean "regular" windows programs? What is msys at the end of the triplet? What is the difference between mingw32and mingw64 at the end of the triplet? And finally, can someone explain/point me to an explanation of how these triplets actually work? Do they really make any difference, or are they just used as the prefix for the compiler chosen? If I rename my compiler and tools to "a-silly-long-prefix-gcc", "a-silly-long-prefix-g++", "a-silly-long-prefix-ar" etc, would I have a problem compiling like this: ./configure --host=a-silly-long-prefix make ? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı |
From: Roland S. <rol...@on...> - 2013-07-30 17:25:49
|
Hi... Presently I am migrating a big codebase from GCC 4.4.3 to 4.8.2 using the current trunk mingw-w64 crt and headers. I am using a self built toolchain with SEH for 64bit windows and sjlj on 32bit windows. Everything appears to be fine when compiling for 32bit. But I am/was facing some trouble when running ObjectiveC code on 64 bit windows when using ObjectiveC (GNUStep) exceptions. We are still using traditional ObjC exceptions. NS_DURING <code which can throw an excpetion> NS_HANDLER <exception handling code> NS_ENDHANDLER All these 3 NS_ constructs are macros wrapping around setjmp(). With resolved macros it looks like this: {NSHandler NSLocalHandler; _NSAddHandler(&NSLocalHandler); if (!setjmp(NSLocalHandler.jumpState)) { <code which can throw an excpetion> _NSRemoveHandler(&NSLocalHandler); } else { NSException *localException = NSLocalHandler.exception <exception handling code> } } The exception is "thrown" always from within an instance of the NSException class, which code is located in the gnustep-base dll. There the longjmp(jumpState,1) is performed. With our version of gcc 4.4.3 (which Kai knows very well ;-)) everything is fine. Not so with gcc 4.8.2 in "release" mode (without symbols). Here the resulting binary crashes (most of the times) when an exception is raised (exactly when the longjmp() is performed). After nearly loosing all of my remaining hairs in the last 3 days I found a workaround. As far as I can see in setjmp.h setjmp()/longjmp() wraps around _setjmp(jmp_buf,__builtin_frame_adress(0)) and longjmp() from msvcrt.dll. When I use gcc's __builtin_setjmp() / __builtin_longjmp() instead of the msvcrt supplied versions it works again. Has anyone seen something mad like that before? Just 2 more informations: 1. When I do a normal setjmp()/longjmp() combo manually inside of an ObjC method everything is fine too. Works as expected. I assume when I cross dll borders (setjmp() in one dll and longjmp() in another) something is going mad. I would like to understand what is going on here. 2. When I dump out the jmp_buf supplied to setjmp() and look at it it looks perfectly ok. Frameadress/Rip are correct. Even all other registers look ok. jmp_buf is also not corrupted in between of setjmp() and longjmp(). And only win64 bit is affected not 32bit. Presently I am compiling with optimization completely turned off and nearly no other gcc options enabled beside of -fno-omit-frame-pointer. Thanks for your help, Roland |
From: LRN <lr...@gm...> - 2013-07-30 03:22:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30.07.2013 07:00, LRN wrote: > On 30.07.2013 05:54, Thomas Sharpless wrote: >> WTF does that mean? > >> And more to the point, how can I build things like libtiff on MinGW-w64 >> without libtool telling me it? > I've grepped libtool and libtiff source code for "plugin support", came > up with nothing. > > There is, however, such string in binutils. "ar" and "nm" will say that > if you give them OPTION_PLUGIN (--plugin), and they were built without > plugin support (BFD_SUPPORTS_PLUGINS is undefined). > BFD_SUPPORTS_PLUGINS is defined in bfd.h, its value depends on the > @supports_plugin@ autoconf variable. > The value of that variable depends on the value of the $plugins variable > set by AC_PLUGINS. > AC_PLUGINS sets $plugins to "yes" if --enable-plugins was passed to > configure, "no" otherwise. Defaults to "no". > > You should start by rebuild binutils with --enable-plugins, or getting a > pre-compiled version of binutils that was built with --enable-plugins. > > Also, neither libtool nor libtiff have --plugin mentioned anywhere in their source code. If you haven't been adding it yourself somewhere, or asking for plugin support, then your best course would be to find who adds --plugin, where and why. Do note that --plugin requires one argument. Its value might give you a clue too. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJR9zFNAAoJEOs4Jb6SI2CwUk4IAMzMUJO9/ykkz5sy2bxKizI9 QEwLworLAjNvhrbhOwkNESXtUPxLmzNm02TVcT+cwU8NwOq+CdYCkWELdMaAqwGd Io+c8LsJjAF2lHaw+DYFdH3btqe7a83X3OBtUCak022pin4xDitGQgJbJ8mMQcf9 nur8c27G40FhqmFjtEsj4xRtG7JJx99juctjAPwKiRIcgmSJwA/Qg/1a6TDRYGhH Nv2dPeprOiaA+GVRdfy53aRL9gtHgmnygaFAvRpWDBbaVFOSc53XWPIbqUtnNrKy 8t4Y1J3O9LYxEEENGSUWfxydh/5hUKs1+b8iHyKVHw0Yk4Y8+WtkR121eRflgmE= =K+x0 -----END PGP SIGNATURE----- |
From: LRN <lr...@gm...> - 2013-07-30 03:00:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30.07.2013 05:54, Thomas Sharpless wrote: > WTF does that mean? > > And more to the point, how can I build things like libtiff on MinGW-w64 > without libtool telling me it? I've grepped libtool and libtiff source code for "plugin support", came up with nothing. There is, however, such string in binutils. "ar" and "nm" will say that if you give them OPTION_PLUGIN (--plugin), and they were built without plugin support (BFD_SUPPORTS_PLUGINS is undefined). BFD_SUPPORTS_PLUGINS is defined in bfd.h, its value depends on the @supports_plugin@ autoconf variable. The value of that variable depends on the value of the $plugins variable set by AC_PLUGINS. AC_PLUGINS sets $plugins to "yes" if --enable-plugins was passed to configure, "no" otherwise. Defaults to "no". You should start by rebuild binutils with --enable-plugins, or getting a pre-compiled version of binutils that was built with --enable-plugins. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJR9yxGAAoJEOs4Jb6SI2CwCbUIAKgl6wyf97FUbqu2vumPiSg2 +6NuL7wR2FeV6UPoKfEvbAU9AzTZNjn8mCs3AGkxWMz9ZZBowq2hmJ6K09EOZ5RH swmNAmfFEd1FXwjg7QnybBTa8rnIfJRU6NujIlkSL/NKZOoV7EhY5EkTkJMfPToO zCPiX/GXtAGN6MvJ9XVt3NiBLv4w7tKyTxFni9HVfriMgwgKM4Cj27KT33tIgtwk Cu6nUpqt5MFN001gy0vOaZ+EvTgfP6Qc3DZgrvxMWVYo4matLqg+EZnGsC7Q9ra3 i79PX/iB6L4N+m/m9TgkDNQTx0yEaxGBA6E7NL/MtrMqdX693k6w0zisyCozAf8= =b9Z4 -----END PGP SIGNATURE----- |
From: Thomas S. <tks...@gm...> - 2013-07-30 01:54:42
|
WTF does that mean? And more to the point, how can I build things like libtiff on MinGW-w64 without libtool telling me it? Please don't reply unless you know a workaround, I don't care what a plugin is or does. thanks, Tom |
From: Eric B. <eb...@re...> - 2013-07-29 22:25:30
|
On 07/25/2013 03:23 PM, Erik van Pienbroek wrote: >> mingw-libvirt-1.0.5-2 >> Package owner: berrange >> Time to build: 5 minutes, 12 seconds >> Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130724/mingw-libvirt-1.0.5-2 > > This one was also already known. The issue is already fixed in upstream > gnulib. The package maintainer needs to backport the specific commit > manually or update its bundled gnulib copy This has now been done in libvirt.git's v1.0.5-maint branch; I imagine Cole will be cutting v1.0.5.5 soon for fixing other outstanding Fedora 19 bugs, at which point Dan should rebase mingw-libvirt to the same version and it should rebuild without issues. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org |
From: Ray D. <min...@gm...> - 2013-07-28 21:24:53
|
Great work Alexey. Many thanks for the /dev/null fix; I can build llvm with it successfully now. |
From: Alexey P. <al...@gm...> - 2013-07-28 20:52:07
|
New MSYS2 snapshots: 32-bit: x32-msys2-alpha-20130728.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130728.tar.xz/download> 64-bit: x64-msys2-alpha-20130728.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130728.tar.xz/download> Changes: MSYS core: - sync with Cygwin sources; - convert /dev/null to nul for non-MSYS applications Software changes: - update git to 1.8.3.3 - update coreutils to 8.21 - update wget to 1.14 - update gzip to 1.6 - update serf to 1.3.0 - update Python2 to 2.7.5 - update swig to 2.0.10 - update libgcrypt to 1.5.3 - update mercurial to 2.6.3 - add Python3 3.2.5 - add dejagnu 1.5.1 - add autogen 5.17.4 - add guile-2.0.9 - add sshpass-1.05 - add intltool-0.50.2 - add yaml-0.1.4 - add SCons-2.3.0 Perl modules: Pod-Escapes-1.04 Pod-Simple-3.28 Test-Pod-1.48 Devel-Symdump-2.10 Pod-Coverage-0.23 Test-Pod-Coverage-1.08 Compress-Bzip2-2.16 IO-String-1.08 Archive-Zip-1.31_04 TermReadKey-2.30 Term-ReadLine-Perl-1.0303 Term-ReadLine-Gnu-1.20 XML-NamespaceSupport-1.11 XML-SAX-Base-1.08 XML-SAX-0.99 XML-LibXML-2.0019 XML-Parser-2.42_01 Proc-ProcessTable-0.48 YAML-0.84 Config-Tiny-2.14 File-Copy-Recursive-0.38 IPC-Run3-0.046 Probe-Perl-0.02 Tee-0.14 IO-CaptureOutput-1.1102 File-pushd-1.005 File-Which-1.09 File-HomeDir-1.00 Digest-SHA-5.85 IPC-Run-0.92 URI-1.60 HTML-Tagset-3.20 HTML-Parser-3.71 HTTP-Date-6.02 Encode-Locale-1.03 LWP-MediaTypes-6.02 IO-HTML-1.00 HTTP-Message-6.06 File-Listing-6.04 HTTP-Daemon-6.01 WWW-RobotRules-6.02 HTTP-Negotiate-6.01 HTTP-Cookies-6.01 Net-HTTP-6.06 libwww-perl-6.05 Net-IP-1.26 Digest-HMAC-1.03 Net-DNS-0.72 Test-Reporter-1.59 Crypt-SSLeay-0.65_02 common-sense-3.6 JSON-XS-2.34 JSON-2.59 Metabase-Client-Simple-0.009 Sub-Install-0.926 Data-UUID-1.219 Params-Util-1.07 Data-OptList-0.108 Sub-Exporter-0.986 Data-GUID-0.047 CPAN-DistnameInfo-0.12 Metabase-Fact-0.021 Test-Tester-0.109 Test-NoWarnings-1.04 Config-Perl-V-0.18 CPAN-Testers-Report-1.999001 Test-Reporter-Transport-Metabase-1.999008 Capture-Tiny-0.22 Devel-Autoflush-0.05 IPC-Cmd-0.82 CPAN-Reporter-1.2010 Module-ScanDeps-1.10 PAR-Dist-0.49 Socket6-0.23 IO-Socket-INET6-2.71 B-Generate-1.47 PadWalker-1.96 Data-Alias-1.16 DBI-1.627_94 Clone-0.34 Error-0.17020 ExtUtils-Depends-0.304 ExtUtils-PkgConfig-1.14 ExtUtils-MakeMaker-6.69_08 IO-Tty-1.10 Text-CSV_XS-1.01 Text-CSV-1.32 XML-SAX-Expat-0.50 XML-Simple-2.20 Regards, Alexey. |
From: Tony T. <ton...@gm...> - 2013-07-27 08:30:25
|
The MXE team is pleased to announce the new release 2.23 after a thorough testing phase[1]. MXE is a makefile based cross-compiling environment that provides a sane, repeatable way to build many open source libraries[2]. Designed to run on *nix like systems, it currently targets static libraries for Windows using the mingw.org and mingw-w64 runtimes. Highlights of this release: - over 70 new packages including major releases such as Qt5 and VTK6 (total package count now ~270) - GCC updated to 4.8.1 and most packages updated to their latest versions - added support for mingw-w64 based toolchains targeting 32 & 64-bit architectures See the changelog for further details and update notes for Qt and FreeBSD users: http://mxe.cc/#history Download instructions: http://mxe.cc/#download Many thanks to everyone who contributed to the testing and development[3] of this release. Regards, Tony [1] https://lists.nongnu.org/archive/html/mingw-cross-env-list/2013-07/msg00021.html [2] http://mxe.cc/#packages [3] https://github.com/mxe/mxe/graphs/contributors?from=2012-04-12&to=2013-07-26&type=c |
From: Kai T. <kti...@go...> - 2013-07-26 15:59:37
|
Well, the point is documenting the change in ML, too. Not only in SVN repository. Additiinally it shows what patch will change and nobody gets surprised by it. Kai Am 26.07.2013 01:22 schrieb "LRN" <lr...@gm...>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 26.07.2013 09:33, Ozkan Sezer wrote: > > On Fri, Jul 26, 2013 at 3:18 AM, LRN <lr...@gm...> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 24.07.2013 00:22, Kai Tietz wrote: > >>> thank you for the heads up. Sure, it would me vety appreachiated if > you > >>> would take care for this update. > >>> You should have commit rights. So please sent mail with attached > patch, > >>> get approval for it, and then apply. > >>> JonY, Jacek, Ozkan, or dw can give you assistance, if you require. > >> > >> OK, one question though: > >> When previous generation of these headers was committed, what changes > >> did the committer do to the original headers from the GL registry? > >> Because newer version are quite different from the ones that are > >> currently committed (this may be OK, since headers are generated from > >> XML definitions, so they probably are not expected to produce small > >> diffs when switching revisions, but still). > >> > > > > They are some older version before opengl.org switched to using xml > > registry instead of old .spec files. The last version of the old > > headers are these: > > > > http://www.opengl.org/registry/oldspecs/glext.h > > http://www.opengl.org/registry/oldspecs/glxext.h > > http://www.opengl.org/registry/oldspecs/wglext.h > > http://www.opengl.org/registry/oldspecs/glcorearb.h > > > > Now, I dont know which versions were the ones added to our repo, > > because the ones from opengl.org as linked above do produce a diff: > > see attached gl.diff to see. > > > > The latest official headers though, will indeed produce a large diff > > because they are generated the new way. > > OK, so, i've looked briefly at the trunk vs oldspecheaders diff, it > seems that no mingw-w64-specific changes were made, headers were > committed verbatim. > > Anyway, for new 4.4 headers the diff is huge, and there's no adjustments > are (presumably) necessary, which begs the question: what's the point of > attaching a patch and getting approval for it? > > P.S. "presumably" means that i haven't tested these new headers with the > few GL-using packages that i do build. But i will. > > - -- > O< ascii ribbon - stop html email! - www.asciiribbon.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (MingW32) > > iQEcBAEBAgAGBQJR8lvhAAoJEOs4Jb6SI2CwqnsH/jo40E7oNZA4Z6TYUuQ03W0Y > qkVi3qlHxJds0Un6gM66lGwO92P123PlExsG07j0o/5A0/UIbsA/6ShGMBxj05CL > I1pXyw5rKlB/nylREtquuME3mg7j20aehZr5tpDgQ9UCBuU5tYVJy6HpHNRrAv+l > 7PL5yMCmESsMgE+Jrx0RujzWBV9nfg9IfcxPxfG9OwJf0WTVPiy6eyajO/WpeaiR > E1y6qfdJX9UtzHi+iwqdCEzRFzzejr81TpmAs8N/OWACp9IvXZMQ2E9uGve6k0ho > 94hr49pc8OCy3fBTlSQkZDxTTaCXqN+AIFkWpDMfmx6KNvd0F0P/Uvmd09Elw4w= > =82D1 > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: LRN <lr...@gm...> - 2013-07-26 11:22:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26.07.2013 09:33, Ozkan Sezer wrote: > On Fri, Jul 26, 2013 at 3:18 AM, LRN <lr...@gm...> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 24.07.2013 00:22, Kai Tietz wrote: >>> thank you for the heads up. Sure, it would me vety appreachiated if you >>> would take care for this update. >>> You should have commit rights. So please sent mail with attached patch, >>> get approval for it, and then apply. >>> JonY, Jacek, Ozkan, or dw can give you assistance, if you require. >> >> OK, one question though: >> When previous generation of these headers was committed, what changes >> did the committer do to the original headers from the GL registry? >> Because newer version are quite different from the ones that are >> currently committed (this may be OK, since headers are generated from >> XML definitions, so they probably are not expected to produce small >> diffs when switching revisions, but still). >> > > They are some older version before opengl.org switched to using xml > registry instead of old .spec files. The last version of the old > headers are these: > > http://www.opengl.org/registry/oldspecs/glext.h > http://www.opengl.org/registry/oldspecs/glxext.h > http://www.opengl.org/registry/oldspecs/wglext.h > http://www.opengl.org/registry/oldspecs/glcorearb.h > > Now, I dont know which versions were the ones added to our repo, > because the ones from opengl.org as linked above do produce a diff: > see attached gl.diff to see. > > The latest official headers though, will indeed produce a large diff > because they are generated the new way. OK, so, i've looked briefly at the trunk vs oldspecheaders diff, it seems that no mingw-w64-specific changes were made, headers were committed verbatim. Anyway, for new 4.4 headers the diff is huge, and there's no adjustments are (presumably) necessary, which begs the question: what's the point of attaching a patch and getting approval for it? P.S. "presumably" means that i haven't tested these new headers with the few GL-using packages that i do build. But i will. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJR8lvhAAoJEOs4Jb6SI2CwqnsH/jo40E7oNZA4Z6TYUuQ03W0Y qkVi3qlHxJds0Un6gM66lGwO92P123PlExsG07j0o/5A0/UIbsA/6ShGMBxj05CL I1pXyw5rKlB/nylREtquuME3mg7j20aehZr5tpDgQ9UCBuU5tYVJy6HpHNRrAv+l 7PL5yMCmESsMgE+Jrx0RujzWBV9nfg9IfcxPxfG9OwJf0WTVPiy6eyajO/WpeaiR E1y6qfdJX9UtzHi+iwqdCEzRFzzejr81TpmAs8N/OWACp9IvXZMQ2E9uGve6k0ho 94hr49pc8OCy3fBTlSQkZDxTTaCXqN+AIFkWpDMfmx6KNvd0F0P/Uvmd09Elw4w= =82D1 -----END PGP SIGNATURE----- |