This list is closed, nobody may subscribe to it.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(58) |
Oct
(128) |
Nov
(200) |
Dec
(67) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(75) |
Feb
(78) |
Mar
(24) |
Apr
(15) |
May
(31) |
Jun
(118) |
Jul
(34) |
Aug
(74) |
Sep
(52) |
Oct
(27) |
Nov
(33) |
Dec
(27) |
2002 |
Jan
(40) |
Feb
(75) |
Mar
(48) |
Apr
(63) |
May
(123) |
Jun
(140) |
Jul
(39) |
Aug
(89) |
Sep
(90) |
Oct
(98) |
Nov
(132) |
Dec
(98) |
2003 |
Jan
(74) |
Feb
(70) |
Mar
(71) |
Apr
(13) |
May
(47) |
Jun
(25) |
Jul
(74) |
Aug
(29) |
Sep
(46) |
Oct
(25) |
Nov
(36) |
Dec
(17) |
2004 |
Jan
(9) |
Feb
(45) |
Mar
(32) |
Apr
(19) |
May
(56) |
Jun
(20) |
Jul
(27) |
Aug
(3) |
Sep
(28) |
Oct
(5) |
Nov
(60) |
Dec
(22) |
2005 |
Jan
(29) |
Feb
(24) |
Mar
(10) |
Apr
(20) |
May
(14) |
Jun
(112) |
Jul
(22) |
Aug
(30) |
Sep
(16) |
Oct
(16) |
Nov
(14) |
Dec
(21) |
2006 |
Jan
(40) |
Feb
(6) |
Mar
(51) |
Apr
(62) |
May
(131) |
Jun
(39) |
Jul
(8) |
Aug
(30) |
Sep
(62) |
Oct
(31) |
Nov
(55) |
Dec
(21) |
2007 |
Jan
(111) |
Feb
(56) |
Mar
(123) |
Apr
(50) |
May
(111) |
Jun
(6) |
Jul
(35) |
Aug
(53) |
Sep
(20) |
Oct
(6) |
Nov
(68) |
Dec
(13) |
2008 |
Jan
(17) |
Feb
(24) |
Mar
(65) |
Apr
(153) |
May
(20) |
Jun
(58) |
Jul
(8) |
Aug
(3) |
Sep
(99) |
Oct
(32) |
Nov
(5) |
Dec
(20) |
2009 |
Jan
(9) |
Feb
(2) |
Mar
(18) |
Apr
(73) |
May
(10) |
Jun
(32) |
Jul
(108) |
Aug
(14) |
Sep
(23) |
Oct
(50) |
Nov
(33) |
Dec
(4) |
2010 |
Jan
(79) |
Feb
(63) |
Mar
(48) |
Apr
(35) |
May
(72) |
Jun
(132) |
Jul
(77) |
Aug
(58) |
Sep
(27) |
Oct
(18) |
Nov
(3) |
Dec
(5) |
2011 |
Jan
(24) |
Feb
(14) |
Mar
(25) |
Apr
(10) |
May
(75) |
Jun
(19) |
Jul
(9) |
Aug
(29) |
Sep
(2) |
Oct
(76) |
Nov
(104) |
Dec
(43) |
2012 |
Jan
(38) |
Feb
(42) |
Mar
(8) |
Apr
(55) |
May
(14) |
Jun
(33) |
Jul
(47) |
Aug
(58) |
Sep
(66) |
Oct
(33) |
Nov
(1) |
Dec
|
2013 |
Jan
(58) |
Feb
(65) |
Mar
(112) |
Apr
(71) |
May
(6) |
Jun
(3) |
Jul
(12) |
Aug
(14) |
Sep
(11) |
Oct
(14) |
Nov
(1) |
Dec
(7) |
2014 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(3) |
Sep
(2) |
Oct
(5) |
Nov
(11) |
Dec
(2) |
2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
(7) |
2016 |
Jan
(22) |
Feb
|
Mar
(5) |
Apr
|
May
(9) |
Jun
(9) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(10) |
2017 |
Jan
(14) |
Feb
(6) |
Mar
(7) |
Apr
(12) |
May
(16) |
Jun
(7) |
Jul
(5) |
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Keith M. <kei...@us...> - 2018-01-07 14:06:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Team, Due to changes to the administrative infrastructure for SourceForge hosted mailing lists, introduced by SourceForge during 2017, we, the Project Administrators, have concluded that this list no longer offers a satisfactory mechanism for communication among contributors to the MinGW.org Project. Consequently, we have decided to adopt an alternative service for such communication, in the future. Participation in this new communications service will be strictly by invitation only. If you are a MinGW.org Project contributor, and you wish to continue to participate in project development, you MUST also participate in this new communications service. Please send an e-mail to min...@li..., giving us your own e-mail address, (not a SourceForge redirecting alias), so that we may invite your continued participation. Additionally, if you have not actively contributed to the project, during the 2017 calendar year, please indicate the extent to which you plan to contribute in future, as this may influence our inclination to invite your continued participation in project activity. Do please note that simply replying to this message will NOT earn you an invitation to participate in the new service; you MUST provide the requested information in a private message to mingw-users-owner. - -- Cesar, Earnie, and Keith MinGW.org Project Administrators. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJaUilJAAoJEMCtNsY0flo/VlkQAIV0vJ1/0EY0AZMZOQ0nKWoH 7HWgI3gv7uFHmmnijLwFN6e4Q+6C6ConrLCoYkoWFuH2Bb7eXVXkawNlzy21V4Lo 9qSZI0I8Ymjr4uoZ8B5Zxt427+fw7AfH91oOa004BX+P7UoMZ3u/uBQcl0VEhAun E5S3nYkzOvlNZJn34vhSO3J9XRbkVov+mMywiQad93WCm/AsU0+w6VolFH/n8EK1 L440NIRRmFuuPL28izls8xDFpYdwmPaiWsPRbW5eSytFgT0eNpH7FhYqaXz2aXY6 9lt58XD5fjXEmWFCs+sQAgQOW1AnIoGD/EhkrRqljpPX7yGYUYijrf0TLTGwyhRo OPXKQGt9wg81z2ofAVmGpJ2C64c030yEU1VbQm+xlxLgUmgZOZDfR2AmOid86LdF +pgob34XT/W3QEL6YoZEtXQuSKU8FfdpViz7dgqX/NABlPhm2M31ysmWfnbzmdXy s5mxKrVqoWS1GciP6qoNo9staOg1RQQgktC5HtOdcxGN7lPVb7QLYNlpbQqtmXuo gY01uemVsNEJN+4MByoVU9Ki3TiBI2KmWMfImwhqQ8Dpj+/jdC3U0YCCdIR5hJg/ SpwbC0OlJJHmowR4v7PYaRLwEkX+XgrsOB2uiq5k6YkYPpkjPbITm6QvIejCfbc+ TUNh5gJu5dN2UgZ4OVZk =cbOm -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2017-08-21 22:54:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/08/17 13:52, Earnie via MinGW-dvlpr wrote: >> Unless anyone can offer a convincing argument, within the next seven >> days, as to why we should faithfully reproduce other projects' bugs, >> I propose to correct both of these issues. > > Why wait? The MS documentation doesn't propose this issue so just do > it. There is some refactoring I'd like to do first; I likely won't get to this for about a week, anyway, but I'll take your agreement as read. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZm2SVAAoJEMCtNsY0flo/pi8QAMqlZ/vfwJF6YUpTmraL0lLe 8hu2YjKij/RMkrzG6uK+XaDyqeSVq6fPjeGXlmsS597xItiEcryuOrB5sBvsLbgS T8T8TS5qh2NRI67q7OBD8frUhft0wlIs6s5sLE+ZBdZdf1llVMDTq4MB227u/VjZ 8n1XRZPm4GKflQR5paVnHksiTCsOH51/N412R1/Dhzf9GOWMk12L6M0HuCcUreDQ mRDjAxkaD9mmOxa3rGBoFQSXuGVP27pKUQxTC18qflN8SJCSxh4Arue9S21QTEmZ K0DGivkQ5sz8VqjPIHgBcsxJzQTYFT7V/11VbjrK71+1d7WI6B+69ijVWss6qet4 Q7APGhJrhmFhxDRkXs6zNaj0e1W/gxMYu4wOmd97nb75wLaejjoU1fSjoMOHsFnA OZWOsQ5REF54ljDpfjs6xOFZwFYl9bgOrnKYYZrcwbq8WAHh4BURYhyKEaykI6PH voUAeHToEL2YO3GtsyHxD9/c/NCC3KFxuEHqj1sZfuGHCx02VdAQZTvV4RpGc4jM toDL5DC4riWBbmRtWIKEjVKM2eU/cchLnQvNAVwe7TKZ+jZ9TL6CJ5VpemgZUp6y Rd8H6jOC75p6L9ztBqmIR+1Vor5DTu+zD4uOCKzXW/5/mb+1WlZCiKaSX6V1WPRJ F0nyIANz8/ZMl/MX5NQP =o0T4 -----END PGP SIGNATURE----- |
From: Earnie <ea...@us...> - 2017-08-21 12:52:35
|
On 8/21/2017 7:54 AM, Keith Marshall via MinGW-dvlpr wrote: > On 08/08/17 21:57, Keith Marshall via MinGW-dvlpr wrote: >> 3) The definitions of the FD_SET macro differ between the two headers; >> this appears to be intentional, in spite of the <winsock.h> version >> being utterly broken. I don't know what Microsoft do, in *their* >> <winsock.h>, but similar breakage does appear to be perpetuated in >> other open source implementations; should we fix it, or should we >> continue to mimic the broken behaviour perpetuated by others? > >> 4) Although the same in both cases, the FD_CLR macro is detrimentally >> affected by the broken FD_SET in <winsock.h>; it's actually not >> robust in either case, because it doesn't account for any possible >> duplication of socket descriptors in the managed descriptor set; >> should we seek a more robust formulation? > > I've now created an autotest module which demonstrates these two issues: > https://sourceforge.net/p/mingw/mingw-org-wsl/ci/a5f7717aa34744b4bb18bf287d9a9920de0f4c30/ > > As may be seen, from the attached testsuite output, issue (3) is > apparent in the <winsock.h>, but not in the <winsock2.h> implementation, > of FD_SET, (although the latter implementation is an utterly ghastly > mess). Issue (4) remains (identically) in both implementations, in the > particular case of an fd_set which may be malformed, (perhaps as a > result of using FD_SET to add a duplicate fd, in a translation unit > which includes <winsock.h> rather than <winsock2.h>). > > Unless anyone can offer a convincing argument, within the next seven > days, as to why we should faithfully reproduce other projects' bugs, I > propose to correct both of these issues. Why wait? The MS documentation doesn't propose this issue so just do it. -- Earnie |
From: Keith M. <kei...@us...> - 2017-08-21 11:54:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/08/17 21:57, Keith Marshall via MinGW-dvlpr wrote: > 3) The definitions of the FD_SET macro differ between the two headers; > this appears to be intentional, in spite of the <winsock.h> version > being utterly broken. I don't know what Microsoft do, in *their* > <winsock.h>, but similar breakage does appear to be perpetuated in > other open source implementations; should we fix it, or should we > continue to mimic the broken behaviour perpetuated by others? > > 4) Although the same in both cases, the FD_CLR macro is detrimentally > affected by the broken FD_SET in <winsock.h>; it's actually not > robust in either case, because it doesn't account for any possible > duplication of socket descriptors in the managed descriptor set; > should we seek a more robust formulation? I've now created an autotest module which demonstrates these two issues: https://sourceforge.net/p/mingw/mingw-org-wsl/ci/a5f7717aa34744b4bb18bf287d9a9920de0f4c30/ As may be seen, from the attached testsuite output, issue (3) is apparent in the <winsock.h>, but not in the <winsock2.h> implementation, of FD_SET, (although the latter implementation is an utterly ghastly mess). Issue (4) remains (identically) in both implementations, in the particular case of an fd_set which may be malformed, (perhaps as a result of using FD_SET to add a duplicate fd, in a translation unit which includes <winsock.h> rather than <winsock2.h>). Unless anyone can offer a convincing argument, within the next seven days, as to why we should faithfully reproduce other projects' bugs, I propose to correct both of these issues. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZmsnuAAoJEMCtNsY0flo/Bw4QAL29MSNP4gCKVMKHAKF6izRR nQFZwNVGlj1Qcp/bWNZYNgx7PwL6o9fXuukjI5P8CDDkQR4pwf5FzMKyfFz/YeP3 UHAOdMKXpOAYM2gro2viO4wWIKoElqFO2iXiANjMnEeoXBct2eWpycJW+1C86is4 UzIIE2G2CDLL0rE6oo+L3n/XBFAXOLKq8qcjPYqH8dG4q8MV3NLdinRwykxIQyAg BmqHdR3VNTXimyo170/BsslEmvMd9QwBMUMxj3q/pFmngoWtyz8zh9GIO2rUoD/T rJ4R2Iiy59fMLmdWDixPKahhx3sJw1gLZk76XLkCqq+L1RYIL3rsqJjyNVwuANs6 UIy8XbU0dNgYc01IOEbnPugzVqU2YBy7KeJAv89lLvHW9wv3c1obIGM2MY7KY4wF CS6OL+hHYxt/MYtlPXNw4HvxyOKj5VSMTapiBXb8D3BxHAMMkQ1H8PGsB11F2qFO bWHmcyyFXdKd9VUTqFfbww1ZPrDM5hm78a1VRp05V98SETThHgxucqPbLu2jgSVA 3Qk/D7hQm8/UnnyThd7FMpnMbSZ6CAgzPH3hagbCNr0KJT14aN8Jvn+6N1pCpM/3 5HwCb2VLbs+xV3q96D2vKmH3VZa0Ql+roX5yuH93HlWj7btc6Mg/0HLGSJmKDqJH JeE/gHxCvtJlKDScTp/p =pcO7 -----END PGP SIGNATURE----- |
From: Earnie <ea...@us...> - 2017-08-11 13:25:51
|
Trying for the 3rd time to respond. On 8/10/2017 2:50 PM, Keith Marshall via MinGW-dvlpr wrote: > On 08/08/17 23:03, Keith Marshall via MinGW-dvlpr wrote: >> On 08/08/17 21:57, Keith Marshall via MinGW-dvlpr wrote: >>> 3) The definitions of the FD_SET macro differ between the two headers; > >> In addition, in both headers, I see the FD_SET function style macro >> definition followed by: > >> typedef struct fd_set FD_SET; > >> which is utterly broken. Had FD_SET been declared as a function, (as >> POSIX.1 permits, but doesn't require), GCC would have caught this; as >> it stands, the anomaly isn't caught until someone tries to use FD_SET >> as a data type, in which case GCC emits a less than helpful message. > >> Since the typedef isn't even usable, I propose to remove it; perhaps >> the corresponding: > >> typedef struct fd_set *PFD_SET, *LPFD_SET; > >> should also go? (I can find no formal MSDN references to support >> their inclusion). > > Earnie replied, (bounced due to SF shenanigans): >> Can't get rid of them. See >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).aspx >> for where they're defined by MSDN. > > Thanks, I'd already seen that reference. Perhaps I'm missing something, > but I can see no mention whatsoever, (and Firefox cannot find a single > mention either), of data types FD_SET, PFD_SET, or LPFD_SET, anywhere on > that page; neither does a google search on site:msdn.microsoft.com find > anything pertinent, (ignoring dodgy postings of the entire content of > their <winsock.h> header, on their social forum). > > To be absolutely clear, the FD_SET typedef to which I refer is *not* the > FD_SET macro definition, which is approximately equivalent to function: > > void FD_SET (unsigned int, fd_set *); > > This macro, (or an equivalent function implementation), *must* remain, > (although the existing formulation in <winsock.h> isn't quite correct, > and the alternative formulation in <winsock2.h>, while correcting the > <winsock.h> deficiency, is unnecessarily complex, and just an utterly > disgusting mess). I propose streamlining this implementation, such > that it is simplified, consistent, and correct in both headers. > > However, the questionable typedef appears later in the header files, and > this conflicts with the earlier macro definition: > > typedef struct fd_set FD_SET; > I agree these need to go. The macros should be defined. It could be that the MSDN documentation at one time suggested these data types but we don't have a historical reference for it. -- Earnie |
From: Keith M. <kei...@us...> - 2017-08-10 18:50:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/08/17 23:03, Keith Marshall via MinGW-dvlpr wrote: > On 08/08/17 21:57, Keith Marshall via MinGW-dvlpr wrote: >> 3) The definitions of the FD_SET macro differ between the two headers; > > In addition, in both headers, I see the FD_SET function style macro > definition followed by: > > typedef struct fd_set FD_SET; > > which is utterly broken. Had FD_SET been declared as a function, (as > POSIX.1 permits, but doesn't require), GCC would have caught this; as > it stands, the anomaly isn't caught until someone tries to use FD_SET > as a data type, in which case GCC emits a less than helpful message. > > Since the typedef isn't even usable, I propose to remove it; perhaps > the corresponding: > > typedef struct fd_set *PFD_SET, *LPFD_SET; > > should also go? (I can find no formal MSDN references to support > their inclusion). Earnie replied, (bounced due to SF shenanigans): > Can't get rid of them. See > https://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).aspx > for where they're defined by MSDN. Thanks, I'd already seen that reference. Perhaps I'm missing something, but I can see no mention whatsoever, (and Firefox cannot find a single mention either), of data types FD_SET, PFD_SET, or LPFD_SET, anywhere on that page; neither does a google search on site:msdn.microsoft.com find anything pertinent, (ignoring dodgy postings of the entire content of their <winsock.h> header, on their social forum). To be absolutely clear, the FD_SET typedef to which I refer is *not* the FD_SET macro definition, which is approximately equivalent to function: void FD_SET (unsigned int, fd_set *); This macro, (or an equivalent function implementation), *must* remain, (although the existing formulation in <winsock.h> isn't quite correct, and the alternative formulation in <winsock2.h>, while correcting the <winsock.h> deficiency, is unnecessarily complex, and just an utterly disgusting mess). I propose streamlining this implementation, such that it is simplified, consistent, and correct in both headers. However, the questionable typedef appears later in the header files, and this conflicts with the earlier macro definition: typedef struct fd_set FD_SET; Although GCC doesn't catch this anomaly, (unless function prototypes are provided for FD_ZERO, FD_ISSET, FD_SET, and FD_CLR), this is confusing, and since MSDN doesn't appear to document this typedef anomaly, IMO, it really does need to go away. Ditto for PFD_SET and LPFD_SET; the real underlying data type is fd_set, and any well written software should refer to it as such, or as "fd_set *", in the case of pointer types ... and anyone who writes code which is obfuscated by any of Microsoft's hideous "PFOO" types, instead of transparently writing "FOO *", should be taken out and summarily executed by firing squad, IMO. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZjKrbAAoJEMCtNsY0flo/JpEP/R0Sc1pDOLCXsqVE5HY8P3Z1 fs+6dxKjfovtsFhpk0ooW4FQF1lNYy/9EzFLQ4tgxUq/S+7xM6ADTrmQ61CI9h9x LoAJ9l1vWFJ8q3lRBILL5BG4oS1bWH0jvYEetfQFlnD8GKBFrTXZ+wB7de5w/qAA 1+Hn7B+H/ITagJdFVjWohK+XH4ZI5+XuCHGNLo4vNf8ej06hIlWh2vzmhaYSrXwW +MNi3nWfMxc6yM9XQflaKRtBxIQ+j/ssOOJgpP8+s17Bt9qS7Woaul0MFpCvlRpN FL/4IZeNM9yz3MPprqFeLY9AklwppyHKx7rzwJzsOAaPfiQLT/BAionP1UejeZQa /l6XvHoP6Y+4iyPpDXcSOjsulFzXKpFLyFTZIE/Y0HC/cYssHCUm+1qFQBhU8asU gFJQ/1ZnnNoj/jHcvrdGJTW/oFW7r/a3zKzsmM2ENYttZIq3y90h/owiYLAQyTKA ypa6UnnNsGbeH5vRzw7x5tds/ZmQpFGFidn8VylssEi9fs8JonGPOy6UJusz0oJB dUoXglhDFxTkaVaShoadJ+GhhO8QIqmzOOE57j7Lp0l31Y7cIRZ5xAAh0Wto6L3V CqRTyG+nqch8yX+glkDlkYEJEpKakG2+I0EwbmI2NlFGjehMv4oU5vfa04uwktVW jnmNJ7gT/6SwkyPDEd8h =Rmfi -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2017-08-08 22:03:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/08/17 21:57, Keith Marshall via MinGW-dvlpr wrote: > 3) The definitions of the FD_SET macro differ between the two headers; In addition, in both headers, I see the FD_SET function style macro definition followed by: typedef struct fd_set FD_SET; which is utterly broken. Had FD_SET been declared as a function, (as POSIX.1 permits, but doesn't require), GCC would have caught this; as it stands, the anomaly isn't caught until someone tries to use FD_SET as a data type, in which case GCC emits a less than helpful message. Since the typedef isn't even usable, I propose to remove it; perhaps the corresponding: typedef struct fd_set *PFD_SET, *LPFD_SET; should also go? (I can find no formal MSDN references to support their inclusion). - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZijUmAAoJEMCtNsY0flo/iaIQAJGMtSQlIfg0XxsrA3pWKzpI WYvXhxojCvxd1pF8QcAg1bRZJZ7yyUE9wlTcWFkEVQMTSzw6XQ8FJxtCrMn6qO2d yt2T7De3SuCUsYD8ODMJShkNgf7nwx/foYkoAzDV25YmwCY8wprd+JL6X9malUsG ruQh1Il1O3VvM7Dr404Gq+r2EkBNvuFvaf3Y34jhi4p5LaoV/Q4BZGRSQ3/hmARK ttThtS1TSMG5mhRpb1N1ZJY93uQtOWXiXj7+0N/UX/BdlMryP4sf4OYKGSvu42V3 uvDrFSjWaXVZFhYS+HEHyxiJbX7mbr3zKwusfI7WqEkGz78yokV8lQXy4DdW8r+L ZEkuvhkR9b/k1QuiyzbAULje9xs5dH2WC3KAZYZjBtGAIJQixghmod3chTJgaW3G NUOtX8G1jyQyFg5QTP+tRXG3UAN+IsXFao1IZZ1efXgQ2gjkgO3vcR6uzseLshg9 odA3EQj6jvFQR+RCkV+95jUaX1cHLLUczU6wLCQ4D3w38MVpnOpXSbJ8xYyFsg3Z jjXp7vbuuIJJStEQwvZW5oJlVqZ/q++rOkWJ9/On18qyWnnWa0Wpxq1d++EyAbdh tR6RpEfidIj/tWvakCUyYzmrIVwaHSe35yoT4hOzv6Mh+7ZjEO1tH9H7qHgJcgwZ VPas67zQB57xWRiZuR7x =PNMe -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2017-08-08 20:57:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Guys, I've been reviewing this pair of headers, with a view to factoring the common elements into a single, shared resource. While, for the most part, the differences are additions for <winsock2.h>, there are a few areas, in which we might expect agreement, yet the two conflict; e.g.: 1) Code guards for __INSIDE_CYGWIN__ or __INSIDE_MSYS__ are formulated differently: mostly, the __INSIDE_CYGWIN__ guard is expressed with the defined operator; the __INSIDE_MSYS__ guard sometimes omits it, but for consistency, I'm assuming that it should always be present? 2) In <winsock.h>, the __INSIDE_MSYS__ guard is normally accompanied by (logical OR with) the __INSIDE_CYGWIN__ guard; in <winsock2.h>, the __INSIDE_MSYS__ guard sometimes appears alone, conflicting with usage in <winsock.h> in the same context; again, I'm assuming that this is an oversight, and that both should be tested in all cases? 3) The definitions of the FD_SET macro differ between the two headers; this appears to be intentional, in spite of the <winsock.h> version being utterly broken. I don't know what Microsoft do, in *their* <winsock.h>, but similar breakage does appear to be perpetuated in other open source implementations; should we fix it, or should we continue to mimic the broken behaviour perpetuated by others? 4) Although the same in both cases, the FD_CLR macro is detrimentally affected by the broken FD_SET in <winsock.h>; (it's actually not robust in either case, because it doesn't account for any possible duplication of socket descriptors in the managed descriptor set; should we seek a more robust formulation? - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZiiXGAAoJEMCtNsY0flo/ZysQALeyw28aMOWXuUbjIHoKmQls q8l1+VOz3nx5Can2SMsjKsVvLiBFsfAzFZd0shG8+hCBHTKkM6sPamohf96Lp6+N MSMGab0a0RPPfyPwzPDQ1y0q9LQ8hrmp94Z4GK8uv6g0k0XDt5ub07ija3axdUpy ua8KGcYLyclPt0yMwf0sairEEM+c62M63DpAPLiDvTFLASsUzfhH3BvekHuEFpk/ 16OXZz6wD9q21LNWZHC4Z9Tf4hs4+e+xWTkS6Uh0fc4gZTjMWRFODE92ojL/jTMZ Rrhs6vqMcrR3K9pouGmpGEGEj1abMDyALU3N/taTMfm72ettuhzJhm7GhSglzQcS DO7WZdmCwNo+IgAKVnMg5lMfJJzLHqYLAlKXWpNuTVVAp0tHjqnuH4cvEUQRgH+E nj9Qd9p0xPfY1zH3752YZp75owMhmeJa29HORnHODVEayzu040zE5hKuOWvtRea3 Fg9kVuRh6+/Ch3bdQabfSY5hr13kXyoFeyBa6g9Ow51h0ER4BJfsclrTt2xD64z7 d+F/sQgKGfq4ve0Ikz8cGRfLRIAoLL/PWbgb3ulxaqrPbaDlXf8RJrp5rClDE/tk uGtLX/FBVurEugcuZ13wAPjPq4U0Hfaq3XN1IUJC84yO3l8QhCQiIe4bYMx8jGXz 5mU5L7dSfGOqeWOMaozq =S8jx -----END PGP SIGNATURE----- |
From: Earnie <ea...@us...> - 2017-07-25 12:14:35
|
On 7/25/2017 7:56 AM, Keith Marshall via MinGW-dvlpr wrote: > Guys, > > The issue arose as an unintentionally introduced dependency, when I > published GCC-6.3.0; I rebuilt the gcc-core-bin component, to correct > an mpc-1.0.2 header vs. mpc-1.0.3 library dependency inconsistency, > after I'd added libmingwex.dll.a to my cross-compiler tools. > > Unintentional, it may have been, but entirely undesirable? I'm not > sure. Now that this dynamic linking option is available, would it not > be a worthwhile deployment choice to have *all* MinGW.org tools linked > thus? (After all, dynamic linking does have its advantages, in spite > of the aversion shown by many Windows users). > > What do you think? Yes, it sounds like the correct thing to do. The aversion comes from mostly like of knowledge on managing DLL. The users need to learn how to store the DLL for the package so that the package uses the DLL for their applications rather than some DLL on PATH. -- Earnie |
From: Keith M. <kei...@us...> - 2017-07-25 11:56:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Guys, The issue arose as an unintentionally introduced dependency, when I published GCC-6.3.0; I rebuilt the gcc-core-bin component, to correct an mpc-1.0.2 header vs. mpc-1.0.3 library dependency inconsistency, after I'd added libmingwex.dll.a to my cross-compiler tools. Unintentional, it may have been, but entirely undesirable? I'm not sure. Now that this dynamic linking option is available, would it not be a worthwhile deployment choice to have *all* MinGW.org tools linked thus? (After all, dynamic linking does have its advantages, in spite of the aversion shown by many Windows users). What do you think? - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZdzHdAAoJEMCtNsY0flo/jvMQAKfIfniiSQKC0c4Xy6h7OCuC hpwUolJ2DAbw3Dd5fOWgRfahcC6OTYtrXqk1UpwVbz/iFTSc+SmULUdSg8xSz9pR 9nSyt/RlM537AEvpgcKgbDDHWOsG5mvbIp9W1lIQbhIIr/JqK4iiLnzWmc84ClGz wSb8otcdBtsrCZi3hxi/JmvoUy1yRN3m5XuaIEtOoSkQqfV3GvZyva2o63GhjuL5 +ygEwB1B05ONDK3vt78n4L4T61JD0bXBHnPhov30K4OM/43YkHCWqhhM7FMTnsRh mBXi1BhEaGw+L4TlvRNg7eTpbM3fRRiD7WeNXj2rj9OPv2m3piqgCtT/fs1a99fl Hpch8mLLwakhUqaKZ3UNZoFlbrV3m2L6McVhQgYjH+hFwp8I7kE16sVzkAHoaj4P ubTHOLdDj6Mc4+760p4TbDE7ECGoNeNzoowLn5k+hEVNL5aqFfKmuiH5NQIkJUxz ExQNxMMkWTzwwRKkTbMCMFRp8m8eL5dL/KZuDdgqO/Xb3ecDJdllAJtOpVzt6qC4 k+lVMV+Pg/nvYluLdwGIDHGMFhINjS4BQFkEqLadW90z/C8YPBIoCUndvFbFNud6 jTNaMIuh5ZjzX61scKDRpntu8kUgYeVC/TgSoarXHbrEgsJxqQqAVQG+ZsuIg17h KCSxNvtzrXP7pFM9oF3g =oCqf -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2017-07-19 14:20:51
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/07/17 20:13, Earnie via MinGW-dvlpr wrote: > On 7/18/2017 12:34 PM, Keith Marshall via MinGW-dvlpr wrote: >> I'm trying to tidy up the mingw-get package specifications for GCC-4+. >> Throughout the XML "requires" specifications for the "gcc-core" package, >> (specifically for its "bin" component), I'm seeing references to the >> development headers and libraries for pthreads-win32. Why? I can >> understand why each "libgomp-dll" component package release must specify >> dependencies for the specific pthreads-win32 DLL, against which it may >> have been linked, but why on earth are the associated pthreads-win32 >> development headers and static libraries required to run GCC? >> >> Am I missing something? > > It's been so long since I've even used it to comment. I'm thinking > maybe C++ drags them in but that is just a frog's hair chance of > possibility. That could be plausible, if we specified "--enable-threads=posix" when building the compiler. We don't normally do that -- my GCC-5.3.0-2 is an experimental exception; does anyone know of any other of our builds using a thread model which is not "win32"? More likely, the libgomp-1.dll build-time dependency on pthreads has been mistakenly propagated as a GCC run-time dependency, which I don't believe it to be unless the user's own source is pthreads dependent. Surely, in the latter case, the onus should be on the user to satisfy the dependency, in a manner which is compatible with the pthreads implementation he (or she) chooses to adopt? - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZb2q4AAoJEMCtNsY0flo/zGEP/15JgFYzdvc+5YuDL/cNe5iR 06mr+n969JcRf5Ole8piEO8oPLAI8A59nAMgNajcffoYN0qvrRP8jXUSpbLAzn4X rglQS6MM72V78k9FUTtguhWsaTNZJRbnB2CeCCD+lDoG9/oT6v/TdzcKLVmp9G/O JarCozveYf9RaLTAqx4vvioRINVcLm3wqyp+oHUe3ROjKsluNipSBvYc3j/3rCAG rcVnD1JsfkLdBbo6lP3zpRjcl6HvC0Kd53CjRlw+rIxsjjtaOzKtC06QoWdFe1aQ eMjMYrsQOR4eB/3V2Hb9/CsE1nW3YO1reF+LubhPMZlJWelunIWdI/vfzFobXZCl dLpETO80yqGDRBmQQEHEZKWnAPCTiXhGIKKFngCIHVQLV8Vjilg+d3M+j30RzbWh fAHXvzWUNLRghU580ZT4KV6xOUoIKKOQUhhxp+/f/we8aSajmTttASt5LN7zgVdm hkK7i6bBcXtpt1cw40e7WsdJ9ZVgtrquzLP16Fw0Bb1R8BxzWXJ8RZ/7sWYDVRMv jxvuBLQn9ceqYFFtZUNDf/mGmeUvwtrGb7UkUIrXOn2IzHiPEesIPkzv8H1agfHQ ocqUOAxgwNjUyfDRE7sXnNvIHdf3txbta9JQb+jF7RBoooBXAH2vy/xkGFo4GCc3 2ZobuXyo6bwwz4uyBqWJ =nDKD -----END PGP SIGNATURE----- |
From: Earnie <ea...@us...> - 2017-07-18 19:13:21
|
On 7/18/2017 12:34 PM, Keith Marshall via MinGW-dvlpr wrote: > Folks, > > I'm trying to tidy up the mingw-get package specifications for GCC-4+. > Throughout the XML "requires" specifications for the "gcc-core" package, > (specifically for its "bin" component), I'm seeing references to the > development headers and libraries for pthreads-win32. Why? I can > understand why each "libgomp-dll" component package release must specify > dependencies for the specific pthreads-win32 DLL, against which it may > have been linked, but why on earth are the associated pthreads-win32 > development headers and static libraries required to run GCC? > > Am I missing something? It's been so long since I've even used it to comment. I'm thinking maybe C++ drags them in but that is just a frog's hair chance of possibility. -- Earnie |
From: Keith M. <kei...@us...> - 2017-07-18 16:34:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, I'm trying to tidy up the mingw-get package specifications for GCC-4+. Throughout the XML "requires" specifications for the "gcc-core" package, (specifically for its "bin" component), I'm seeing references to the development headers and libraries for pthreads-win32. Why? I can understand why each "libgomp-dll" component package release must specify dependencies for the specific pthreads-win32 DLL, against which it may have been linked, but why on earth are the associated pthreads-win32 development headers and static libraries required to run GCC? Am I missing something? - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZbjh+AAoJEMCtNsY0flo/S00QAIQyFSQ1/fEzRnD8Tz2Dct3W pFr5L2UnnvZBPA5JD2iZqg0aic+GxU0Cc7AP/kYmUvAYXpx9xrhdjXtcF5H8qie+ jdA6xgUXG+YHcyrcvfmF0AL4UviMgqis4XXO8QoGD7x+mDg9IfeklSfVvyXvKUiR CU+GiDTM+upoMx70gSNcI2VwbrrjNViHyJCPEvU1f9ieIQMWQ7P++fhaMgPlu0oJ JbYlw/trjQrQpkh8+NMuCF+HyGJF7/YZRho4f3FF/ZXBEUabl7Gml1h4uGY/J5ch ull+5JWRsh9mtSqdqbbtuU5da08LTuFEnXF3nhJc6QoOa1L790z585s8cKSotZp5 yeSjVEzjMZ+PlhDuKniBBeuGr6fAHwNcbo08v4yW2HuiKJKpSuiAnyCgCfs2OeZu Gw74H8SoqDuWxydipkMg6pVqYwRne287/77+tlD0rwhbS4bbRT3cMePeILzKRGvr 1o1DgAgmbf8b0oQb2v+21sOn6bXCenoW+/exwOJM+dYRSme3sgtpic+H+f++SYQh rQVqmIka32URihRw1oXaS09/O2KhgMdgifxuRULiWKJ1yeWu3tcMygpxJ5ZDZqjO /cGmDKvsDuGywmDTjNqPnMn9GEI+USlcZB+btfXBneEQ5vB/gP5b8dggUxn5hfxf pIpnMdyurzokTtupXBLT =2HtG -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2017-06-04 12:19:49
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/06/17 16:47, David Gressett wrote: > Static linking is the default. I never do dynamic linking, ... I wonder how many MinGW users actually use Ada? Of those who do, I wonder if *any* link the gnat runtime dynamically? > The libgnat and libgnarl DLL's should be left where "make install" > puts them. Looking back to the previous releases, which are still visible on our FRS download pages[1], it was done thus up to v4.3.0, with just one Ada package for each release; thereafter, the DLLs were moved their own separate package, and in the process they were relocated from their default $prefix/lib/gcc/mingw32/[version]/adalib installation path, to $prefix/bin. That relocation would have moved them away from where the gnattools would have expected to link them, making it even less likely that any Ada application would have been linked to depend on them; no existing distribution has provided corresponding import libs, which might have mitigated the effect of relocation. > stripping an Ada DLL will cause it to lose its relocatability. FWIW, I haven't checked them all, but the distributed libgnat-4.7.dll *was* stripped; did that create problems for users of that release? I don't remember any having been reported, but maybe that's simply because no one ever used them. [1]: Those which actually included gnatlib DLLs; GCC-3.x appears not to have done so; neither did any of my cross-compiled releases, from GCC-4.8.2 onwards. Furthermore, while GCC-3.x *did* include the gnatdll.exe tool, that appears to be missing from the GCC-4.x and later releases. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZM/rcAAoJEMCtNsY0flo/E4MQALnKFy1yNkzzXEXgfC1Zu+xL xUtjc5E+VF1hWpLzgl7cAhyRFX8N6Wr8jd1HyYMBrSgA4ZJvtJQMKjTpAKULD/Lw 5hQ6B4dd2d+bTmON/DGxpHW5ggluBwzMlZEaVCgHWzObhF2k7hrSxrW8vmO6Q5rE Ob42oY+A+bPyX58HE9p1YD7QVhYPfk7fqosPWIfdrNLmpxZHrhXbQtr2lPFjqW51 qJOsF0dcy+1iM3glnNt5arkCJ/KiRL/NDFf7mJGDPJY2PacboCqSWOo+fndhNW40 8bmZ0P+RJtd/ruu3xjeYMCNguwADPnJRj+Idg8M5ERogdCtZ4iyxveko5udBC1KH rt5dQgEbVwaDL+b3GaQ3e98I7JvS9OupSlq74QebS5jGYby42qmHKoXNaT0b74lG Qf9Kc5O21d6AOzs/Hf+oeN4yrRu6VZKaq4sLHJhIEmNesq5G5Rq08SvxHe0jiKRr zmEv/5zIetTfdNb/KFFZIyo6+4RaluLsQmWK/KLTaAQQDBElaTZDD/B5iqaGvz35 xWWK7UIaVkoWa6srW6HoJp9fmshUrgOYZqgF0jKj6IS4kGstCl78dLh7cZXv7Q3r jhnTwxUoQfi5izJZxkhfog+jHtr4HrWOU8QZvoFPAn0VDryZh+kSspD+YE7NPG8T Y/y4d/M1SkMeorJBUrTP =DVeX -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2017-06-03 23:10:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/06/17 23:37, David Gressett wrote: > In section 9.3.5.12 of the Gnat user's guide: > > "Note that a relocatable DLL stripped using the strip binutils > tool will not be relocatable anymore." As a professional engineer, I'm conditioned to treat such claims with suspicion; it's inconsistent with the behaviour I see for every other regular DLL built for Windows, so I'd like to see concrete evidence in support of the claim. > "To build a DLL without debug information pass -largs -s to gnatdll. > This restriction does not apply to a DLL built using a Library > Project." What does that mean? The makefile rules to build libgnat-6.dll, and libgnarl-6.dll, don't use gnatdll; they use "gcc -shared ...", just as any C language (or indeed any other language) DLL is built, and such DLLs don't cease to be relocatable when stripped. > I have no idea at present as to whether the part of the makefile > that builds the gnat runtime invokes a library project or not; > I would have to dig through the build log to find out, and I have > not done that yet. Viewing my build.log in "less", and searching with "/libgna[tr]l*-6", is sufficient to show me those "gcc -shared ..." commands, and takes only a few seconds. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZM0HzAAoJEMCtNsY0flo/2pQP+gJ589yhEvCBxNZQTv83hlLA qiCwcu6MZ/v9d1ENZPk+ZM/eZrWbVoXa+jmjvV3341ZbqTPJRwZ036+gGHupSnqg BZ0Gp1Nm7Aoe1KyxOvwkuQYIE6Fd+w95FXriAbIWcmM3ab0jYCngeBwcUO//3pyT TrnRZJmORke7Ihz/r7vRVvDwxvbc/W2rrkABZDaXia516PtQyzn5Eb2+24i3JGt5 vx5wPAGpgd4ZQ+c1z8Y00JLI1bT/FOjBrlHjUsmD3PtN+0K/+aAcN/UZuZVcYHI2 C4OVql8VnNLTabEmRP8MO2ImnlpM1F/usrSMVqYHHzhMui1QlJULZV51fI8mvVzU Gl9e4+7MdNxwemzIIddGUvXwlO3dBsxaWrUj1mnL+MJNnGfu6N9BfrVNQGZZ7nZw UFUD0e1S33RVytYrh8JCU4/U2dL5R2cOTIOBH5lc17EjKJ2UQB/ZYu4+MaeMl3me wlRO0S4JmAVJlRA/wRAmntu8S+J6kUC26r2fF1g79niNE25mzJJsqOfGasyQsSw3 CbgmQkYjwbbgPbyhGgdNm9vgJvGmN133fn/9ScpBXoPYmwZlQtym3MXK9Powkm65 SgfpWdYAOyFnf3cm25BEXSBw4PqXySLX0a+gBS5xN22GKAAU9+Bmh5Ch4CEn3Yya Zvpk1hY49Qd25U8CXkPo =SaP7 -----END PGP SIGNATURE----- |
From: David G. <jdg...@ho...> - 2017-06-03 22:37:49
|
On Saturday, June 3, 2017 2:21 PM, Keith Marshall wrote: 1 >On 03/06/17 16:47, David Gressett wrote: >>> I note that "make install-strip" does not strip these DLLs; should >>> it? (Ditto, for libgcc_s_dw2-1.dll). >> >> No, stripping an Ada DLL will cause it to lose its relocatability. >Why? I don't understand. Surely all Windows DLLs are inherently >relocatable? Stripping doesn't modify the relocation tables, so why >would it have any such effect? It has been several years since I looked at the Gnat user's guide, so I went back to it to double-check my memory. It is indeed documented in the Gnat user's guide that stripping will cause problems. In section 9.3.5.12 of the Gnat user's guide: "Note that a relocatable DLL stripped using the strip binutils tool will not be relocatable anymore. To build a DLL without debug information pass -largs -s to gnatdll. This restriction does not apply to a DLL built using a Library Project." I have no idea at present as to whether the part of the makefile that builds the gnat runtime invokes a library project or not; I would have to dig through the build log to find out, and I have not done that yet. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZMwwjAAoJEMCtNsY0flo/SgwQAI0hgM1656xjqZqIKwWRgzET W/ZEralDrzXIEzAAOb9+C068LeXs32fBcQMqglIC61E1+lVAqHva3JZn4X9GZJwI y/Yas9rsEQF7tn8/WLUQBTpgCfGdvQwGvmnMCBBJChGbUaLGIlvtq4+ct9cI0ou6 obt8ZEjH5xfs9AiudkrWdP18TuoeLwykNb9mAYL4le/LZM6fqSeLj1C2X++21ZpT TnTKSR7ins8GfBaMBg9J/NVZqM5pR3ijSFRKb4tnukCKOJCEzeQ90hKqoTFefc51 9PtG1s8/BCbSsANc0HeNoQUfZDvTV/p4mnPhvIeNaz9HxCVDEx50ws3Hfh9v7gZu DazxySF0nJdEYLgkyQsEpRNOakMwUwT7OsFkfCIfq0FAKOaonGt0sc63RNfPWnOf RqcWQ5JKNbuujawduowKULe6b3FUrTsE+145CHu/7WaWH0q3MsDf1aZh4ag9pj6k F67agvebZ7VHBJbb/xW7P70w+FDtQZM+Mn9nr1B8aNmUFx+JLCMyiSX8umNlIpFv 1XVfFzN1M7MxN1kEHNC7ZGWcU39yXHPajsF91E91W0u/zFg3P4z8FiH6/YI2X+To SpF0jReAGtU4H59yhaDia/qHcNubkAlwWfT775GP2rpIN/WNEERhd0rM2AslhB2m 7txpPhSUwAZJ04KARSLn =kuw4 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ MinGW-dvlpr mailing list Min...@li... https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Keith M. <kei...@us...> - 2017-06-03 19:21:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/06/17 16:47, David Gressett wrote: >> I note that "make install-strip" does not strip these DLLs; should >> it? (Ditto, for libgcc_s_dw2-1.dll). > > No, stripping an Ada DLL will cause it to lose its relocatability. Why? I don't understand. Surely all Windows DLLs are inherently relocatable? Stripping doesn't modify the relocation tables, so why would it have any such effect? - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZMwwjAAoJEMCtNsY0flo/SgwQAI0hgM1656xjqZqIKwWRgzET W/ZEralDrzXIEzAAOb9+C068LeXs32fBcQMqglIC61E1+lVAqHva3JZn4X9GZJwI y/Yas9rsEQF7tn8/WLUQBTpgCfGdvQwGvmnMCBBJChGbUaLGIlvtq4+ct9cI0ou6 obt8ZEjH5xfs9AiudkrWdP18TuoeLwykNb9mAYL4le/LZM6fqSeLj1C2X++21ZpT TnTKSR7ins8GfBaMBg9J/NVZqM5pR3ijSFRKb4tnukCKOJCEzeQ90hKqoTFefc51 9PtG1s8/BCbSsANc0HeNoQUfZDvTV/p4mnPhvIeNaz9HxCVDEx50ws3Hfh9v7gZu DazxySF0nJdEYLgkyQsEpRNOakMwUwT7OsFkfCIfq0FAKOaonGt0sc63RNfPWnOf RqcWQ5JKNbuujawduowKULe6b3FUrTsE+145CHu/7WaWH0q3MsDf1aZh4ag9pj6k F67agvebZ7VHBJbb/xW7P70w+FDtQZM+Mn9nr1B8aNmUFx+JLCMyiSX8umNlIpFv 1XVfFzN1M7MxN1kEHNC7ZGWcU39yXHPajsF91E91W0u/zFg3P4z8FiH6/YI2X+To SpF0jReAGtU4H59yhaDia/qHcNubkAlwWfT775GP2rpIN/WNEERhd0rM2AslhB2m 7txpPhSUwAZJ04KARSLn =kuw4 -----END PGP SIGNATURE----- |
From: David G. <jdg...@ho...> - 2017-06-03 16:14:13
|
On Friday, June 2, 2017 3:58 PM, Keith Marshall wrote: >David, >On 01/06/17 19:03, Keith Marshall wrote: >> I do get libgnat-6.dll and libgnarl-6.dll, (but corresponding >> import libraries are not built, because there is nothing in the >> corresponding Makefile to build them). >I note that "make install-strip" does not strip these DLLs; should it? >(Ditto, for libgcc_s_dw2-1.dll). No, stripping an Ada DLL will cause it to lose its relocatability. >I can hack the Makefile.in to create import libs. Do we need them? >(The upstream maintainer says we don't). It wouldn't hurt to have them, but I expect that any use of them would be very , very infrequent. >I also note that "make install", (or "make install-strip"), sequesters >all gnat libraries, whether static, import, or DLL, in: > $prefix/lib/gcc/mingw32/6.3.0/adalib/ >I assume that the gnat tools expect to find them there, but surely any >dynamically linked application, built with them, will need the DLLs in >a runtime path? Where should mingw-get install them? Come to that, how >do the gnat tools select between static and dynamic linking? (The GNU >linker will not associate, say, libgnat-6.dll with -lgnat, so if we do >not provide libgnat.dll.a, surely it will pick libgnat.a, which is a >static library). Does this imply that gnat applications always default >to static linking? Static linking is the default. I never do dynamic linking, so I don't remember the gnat tool syntax needed; there is a specific command-line option used to dynamically link the runtime, but you would have to find it in the Ada user guide. The libgnat and libgnarl DLL's should be left where "make install" puts them. You could put copies in some place easier to find for people who need to distribute them, but documentation that shows where they are to be found would be adequate. |
From: Keith M. <kei...@us...> - 2017-06-02 20:58:51
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David, On 01/06/17 19:03, Keith Marshall wrote: > I do get libgnat-6.dll and libgnarl-6.dll, (but corresponding > import libraries are not built, because there is nothing in the > corresponding Makefile to build them). I note that "make install-strip" does not strip these DLLs; should it? (Ditto, for libgcc_s_dw2-1.dll). I can hack the Makefile.in to create import libs. Do we need them? (The upstream maintainer says we don't). I also note that "make install", (or "make install-strip"), sequesters all gnat libraries, whether static, import, or DLL, in: $prefix/lib/gcc/mingw32/6.3.0/adalib/ I assume that the gnat tools expect to find them there, but surely any dynamically linked application, built with them, will need the DLLs in a runtime path? Where should mingw-get install them? Come to that, how do the gnat tools select between static and dynamic linking? (The GNU linker will not associate, say, libgnat-6.dll with -lgnat, so if we do not provide libgnat.dll.a, surely it will pick libgnat.a, which is a static library). Does this imply that gnat applications always default to static linking? - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZMdGBAAoJEMCtNsY0flo/enIQAL3jdoxNpO7t0/6DOaKEij3Z nL35JavMBOcbFeBIz6/sibZCmZPXI/hXXU5dfzAx2TtKjzl/U7+9hfLWYfeaFvgC 9fEPh/TCoyQzQY2mAW6XI++jFbLyQC84K3KTcWPnL2xX130vnpRv69pyqurQvE+M HtvKym3lcvdRJZeBh5Iis8oP2aWMVDM4TaYVOya9TO26ATtpFTsSOAYRaOOVbk/I bBY6mlh5jsAQO+fVnV+ppYLvasADC5oNuGC8xmSH1HobX2n7Iu9d2PbfEjmBXz7M gfrLy2kulBWITBYz5OcHOVaqYZyYF52y+6SQhIyqgTlL0tzQHsEKr2Yu2uWS0SOq 92uEpuqQjfRPVz+ADUI9X4dSzrPD8Sjh3hzVbnvl22EreIJi4fCYJtS8gPzIfU8U gGkmXpGOh3sLOYlsRvV2y5BlhBpH/PGxyTjhLuBSbNE3NUqw8ntm85F6+vFgt9yy qHaEjgjSvmRSdVqNh/agaVRqe7YL5FY7Oee8bD8L3+dUIS26ZvYr9d03oJEaBt1x vLh1p6jGWyh9CxR7I2c0H2YX9tcxdr5tcl+SEwL6zetlBZ07c8SnurjCEPdNeIo6 CbD7tdD9Zr97zSeoGUqLr0ROF242LBmaT4arv/OyR3d59Rt/JJdOwiAkr6CMGGym Inf1qlKi1u3Kc3xmApEM =eGoB -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2017-06-01 18:03:47
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/05/17 00:58, David Gressett wrote: > This leads me to believe that your failure to get the Ada DLLs > is the result of the cross build system looking for mingw32-gnatdll > and not finding it in the compile part of the build, ... No; although incorrectly installed as gnatdll, I linked that (by file system hard link) to the correctly named mingw32-gnatdll, so it should be found. In any case, there's no evidence in any config.log, nor in my build.log, that there was any attempt to find it. The real cause of the problem is a bogus (utterly nonsensical) test in libada/configure, (requiring $build == $target), which effectively disables building of shared Ada libraries[1]; once I remove that test, I do get libgnat-6.dll and libgnarl-6.dll, (but corresponding import libraries are not built, because there is nothing in the corresponding Makefile to build them). [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921 - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZMFb+AAoJEMCtNsY0flo/IjsQALFQfcPIiVGPcWySnhCRZFdk KxWiKblq+phJJ5s5dWqDSiiMqYgxLJvPsEHDh8Kw2bYqv9ANIuPSOXmPuZYzAL/I gVFjZR0ulH8GIM3DJKfo/mGFDC860O0eFK20uF4475OJ33wWmMA3CeojVrjs86nd NOsmSy6GQgjFN6AXZRoZZ5gMhqIQEpe7Kzl2PcR4Wd1s1Q/3BBI5cAKv0xM33kb5 tBgzP5/h9UfIVuX3vZAMMg9v+lRTX0wSs3OtRr2qxrBjOSsX2dlGWOAJOKdg5LyH dNfAqI7wiL0r7gEhobEut8/qbqzpZuekpsRloqTrMBOSBKkO7Jm0k68IMXcdM18U niSh4tqfVJB0Hlc0UpnPeIeRyggp1y59CizzRjgobLskl1CvmamonrggI9OziWMw 3sbWIuWAJFqDAxs33yoOFa18zaO+L5IptjzN36G+hZFsvxGzf/YupTy7Y+dWuCDh 27YuYTGcA2ME/piyI5J9xx8YiqbzUgyAuTfzVMvf6QiWUO1LKPsBYqPLOhwyQWSb 4ErqrzK0aoc3gZ9QanyjHyFCLqf/t7qmHI6w+1AXLwbg8zqbn3Vhz33Hr4GXCt5y HVM81HtZaT7svG8FTisfAuufCdCULuoEQiwI7kGoBR6MmA6zrnkjd3ndFbXvJKgv PxWvbPFC9LDdRmN8mngo =zNv9 -----END PGP SIGNATURE----- |
From: David G. <jdg...@ho...> - 2017-05-30 23:58:51
|
On Tuesday, May 30, 2017 3:41 PM, Keith Marshall wrote >On 30/05/17 21:06, David Gressett wrote: >>> cp: cannot stat ‘rts/standard.ads.h’: No such file or directory >>> >>> which may be (potentially) more disturbing. >> >> I do not have that. >> >> Does your build tree contain gnatdll.exe? >Yes, as gcc/gnatdll.exe >> If it does exist, does your install log show an attempt to install >> it? >A successful attempt; it appears at $prefix/bin/gnatdll.exe. It is also >installed (incorrectly) into my cross-compiler tree, as gnatdll, whereas >it should be installed as mingw32-gnatdll. It installs for me as gnatdll.exe >> In my install-strip log, a set of twelve gnat tools (gnatbind, gnatchop, >> gnat, etc are installed in a loop; >These are also installed, for me, and (correctly) named with the host >prefix, in the cross-compiler tree ... I get the same thing , with the host prefixes, which are incorrect for a native build; I fix them manually after the build completes. There are several executables that get a host prefix from another source, and so get a double dose; for example, i get mingw32-mingw32-gcc.exe, which I rename to mingw32-gcc.exe. The configure system seems to have a problem getting the differences between a native and cross build exactly right. I see other signs of this when I build gcc with gmp, mpfr, and mpc in-tree; I get warnings in my compile log that I am using cross tools not prefixed with the host triplet and that the none host is obsolete. This does not happen when I build the gmp, mpfr, and mpc DLLs as standalone builds. I get compilers that work, however, even with the GCC-7.1.0 builds. >> a few lines down, I see gnatdll.exe installed separately. >... and it is presumably in that separate installation, that the host >prefix is omitted, in the cross-compiler installation. ... and is also omitted for me in my native installation. It looks as if in both cross and native builds, the set of twelve get the prefix and the single gnatdll does not, with different consequences for the Ada DLLs. This leads me to believe that your failure to get the Ada DLLs is the result of the cross build system looking for mingw32-gnatdll and not finding it in the compile part of the build, but my native build looks for gnatdll and finds it. My guess: Those parts of the GCC compiler collection that are used in the middle of the compile process are built early on with the prefix because the cross build needs to use them. gnatdll is handled separately, and incorrectly at one crucial point. The same screwup happens in the native build and accidentally works. ... snip ... |
From: Keith M. <kei...@us...> - 2017-05-30 21:27:45
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/05/17 21:41, Keith Marshall wrote: > The "cannot stat rts/standard.ads.h" issue is evident in both my install > and install-strip logs. Further investigation reveals that, at some point in the build phase, a symbolic link has been created at $top_builddir/gcc/ada/standard.ads.h; it refers to non-existent $top_srcdir/gcc/ada/standard.ads.h, and the "cannot stat" issue arises when attempting to resolve that symbolic link during the install (or install-strip) phase. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZLePJAAoJEMCtNsY0flo/1IgQAKDxHRJSr/CRYnrziIHfLtFF /4ouuyIk84Sneq9IjJrGZVR5RTxsnIm3e7c/hNh3KTuJxiqpqi6od4TjMs4zeXCd rAD7q1NqyWI0rzOxzdyhdf68HNg55k2S8SXK+R3Hsvy81vGN5Ac5t9ZvjV/w8VUk jmjeB41jvZB2j0NPLfsVD0ySl3e7GfvzwSEyRn9LC0B7ijN5lpd/X3CXQxtMPH/R 706KJuDylajkLGjmGdI9WY388ZPYv9LjIyt2M01f+9sKoYKsI133OHc3klePcyjM kpV42R3c+f002iAoxuJ/DG6Gd+gso3Gm/OwPAq8TBWsc3yfwTaSTFdaddDXWRKUu GSRcCH1yiSubU8c63AmDaaC+x4WDBrEMB4L3vVqlqyCOdWNuNiSu983XKeVDe2Uh /r+H2TAhwI5fZrpcc5geJO2sFH5DECb2PahuUPSyNnGT7zORjSYRC+RmAF0MQGiu Igr3SJ4D+5+VQHu985hVOwCeD22LUX8fKPkm2iFuHzDMbp3KIkaghnb9+6ABCSPE j2ilysKSNmmS/ogOrAhAtxXSAh/R6Xk+yCOD7uOxunKiT2C979DfHVEz9mT8SnnX ekAPFfSTW2Gvwui/nX8lohe91CpCFOQQPmknCo9o4ILcMUgBnxGRIovmo3sKpRJD f0cR/JHCm7+SgwXyyzem =H3uI -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2017-05-30 20:41:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/05/17 21:06, David Gressett wrote: >> cp: cannot stat ‘rts/standard.ads.h’: No such file or directory >> >> which may be (potentially) more disturbing. > > I do not have that. > > Does your build tree contain gnatdll.exe? Yes, as gcc/gnatdll.exe > If it does exist, does your install log show an attempt to install > it? A successful attempt; it appears at $prefix/bin/gnatdll.exe. It is also installed (incorrectly) into my cross-compiler tree, as gnatdll, whereas it should be installed as mingw32-gnatdll. > In my install-strip log, a set of twelve gnat tools (gnatbind, gnatchop, > gnat, etc are installed in a loop; These are also installed, for me, and (correctly) named with the host prefix, in the cross-compiler tree ... > a few lines down, I see gnatdll.exe installed separately. ... and it is presumably in that separate installation, that the host prefix is omitted, in the cross-compiler installation. FWIW, I used "install-strip" too, when staging the distribution, but, cognizant of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720, I also checked the effect of "install", in case there was a similar omission for the Ada DLLs. I also included the attached patch, to correct the (long-time ignored) PR-54720 bug, in *our* distribution. The "cannot stat rts/standard.ads.h" issue is evident in both my install and install-strip logs. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZLdjvAAoJEMCtNsY0flo/No8P/RLz+93l9EEEQIopuaNXh47h bcOuIfIiFODr4r6ilMAlNUgGCLm6EtXUpvZAv/yVCbRvjxGVby8P+Fca1zZ3ufI5 ovfkg7LJ/HlFOuLoZFQ5BvgJrDj66WBIkaxfG3O+04uxZgwu+1jiwedy0GdCUKSa soe63Gdx5yKTgHEGR+dyLgTbC+fy3mv5ysPngbv5ZJuoaZa4Q17tMrgC7JSMDWr+ vC9/KxntJE1JXji9NbFjpqGSMy3zAoo0yKn5OliLHmwqdUpREtS63beaqtU4oGrj yc/wnFH6O8/yyxFUWYreiLlIwkLM4ZGrybY5qnQ1HxRd6qUJM1LKkpVJLmc2ZskS 1IJ3vRpXgB2Y1gTMQH15ixWIDLMoVrCxO8qBlzbIBNRxMEPokXRA49u0Bdfx7HCI 9W8Hiki2zgvZUDujI6ZXzRDfrzr3j7pFZgyvLFN31VU1H7ofy7zjIxSVafWE+Odx gznzvJQr7ECFZ+pAnC1/o9g6NES4eACtSaX76nlh+6vRtjIa2PnAldWAClViWw+U o/QwquE3M+3RIOaaOUrb8rbIMHENx26g6zUoht57OI0zVHC4Qf4HtjdT1HdJxp0z qtfVSbebj2G/d4YxzNcgV0ehc6fbzI5kRGltjmPB2c0cw5EDHJCkKWaJm4TFXW5o lJJHzR2uIuz7dpLNc/kS =pkoq -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2017-05-30 20:06:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/05/17 20:11, Keith Marshall wrote: > I see: > > gcc/ada/rts/libgnarl.a > gcc/ada/rts/libgnat.a > > but no corresponding DLLs or .dll.a import libraries I submitted: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921 - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZLdDAAAoJEMCtNsY0flo/8j8QAIYSzBvtJLKItPUrxzCKgj66 JKiqCsQZJKBLRp3mmnzAbmBZjXsXJc40SUMuj6rT/a2evbAbI4KXnzE7Hsr9G1Ho TMc+qswkMPQdLhg2RHFOe3GbeYcAsVoRwMdDw1+BXQUxoYEYsakfQCGcJEIkdCwQ rKuFk7g7B6wY8TMuvhpr/HebOLtB/uI16hMmaxea2jm849rIcddOLJ/X+Cyiw6lV E4oSxNiKpkZ17aIR559cSyls/z6YPQuQMKrAKZbHighTtpmPzbdFSvDsRJMjAm3s QThZ8sdl+0M8zMZCATPonq4uLXR/xFD4QEbayar6VvYQSlh/W6+Z97i+ZbBjBzF7 0HtLN9A6fL3PDfAKU2XPo8myo1ukK+Zq9Z1fGZrFZ4e6ddDmDbU5ZE/h1Dj2cO+0 ea8yPYekjJKEIduGge35SguK7Y3jwKVRmGSdRcoMwbXhDOSUJxHZd7QJxpAiWAcZ YBzmpqIO2/zYSln2COX5imnahyEZBWkQiun9i/HCUCAJjj9newO/qUHHJjBeOd8e tYHXQVwPcQGrDQhyupE/lKbpt/9H/Dq5k9q2tjk/rX46Elf3peiTFN5Hdiz5R+Cf l51TRK66AChRIUUNEa05XljjMLpMOJdDZq922iV0xnQa6r5XuEOlvtlHHN0neru/ bf+Rqxw6IGXwWqQ2wT1O =cIrV -----END PGP SIGNATURE----- |
From: David G. <jdg...@ho...> - 2017-05-30 20:06:11
|
OnTuesday, May 30, 2017 2:11 PM Keith Marshall wrote >On 30/05/17 18:31, David Gressett wrote: > > > On Sunday, May 28, 2017 10:48 AM Keith Marshall wrote: > ... snip ... >>> [*] I think I've applied all your patches, but I still don't get any >>> Ada associated DLLs built. >> >> My builds do not put them in the usual place. Look in >> >> /mingw/lib/gcc/mingw32/6.3.0/adalib >> >> In that directory, I have libgnarl.a, libgnarl-6.dll, libgnarl-6.dll.a, >> libgnat.a, libgnat-6.dll, and libgnat-6.dll.a >I've already searched my entire build tree, and staged install tree; in >the build tree, I see: > gcc/ada/rts/libgnarl.a > gcc/ada/rts/libgnat.a >but no corresponding DLLs or .dll.a import libraries; In my build tree, i do have the corresponding DLLs and import libraries in gcc/ada/rts. >in the install >tree, I see that these have been copied to: > $prefix/lib/gcc/mingw32/6.3.0/adalib/libgnarl.a > $prefix/lib/gcc/mingw32/6.3.0/adalib/libgnat.a >Among the messages from "make install", I see conditional attempts to >install the corresponding DLLs, IFF they exist in gcc/ada/rts, which of >course they don't. Among those messages, I also see: I see the same conditional attempts. ( I am looking at the results of "make install-strip", so some parts are different) In my case they succeed, since I do have the pieces that your build tree does not have. > cp: cannot stat ‘rts/standard.ads.h’: No such file or directory >which may be (potentially) more disturbing. I do not have that. Does your build tree contain gnatdll.exe? if not, the patch that enables its construction may not have happened. If it does exist, does your install log show an attempt to install it? In my install-strip log, a set of twelve gnat tools (gnatbind, gnatchop, gnat, etc are installed in a loop; a few lines down, I see gnatdll.exe installed separately. |