From: Wayne S. <sta...@ve...> - 2013-09-03 19:39:38
|
As of version 4 of win32api, wxWidgets 2.9.x fails to build with both gcc 4.7.2 and the latest 4.8.1 with the following error: In file included from C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/msw/gccpriv.h:22:0, from C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/platform.h:455, from C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/defs.h:28, from C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/wxprec.h:13: C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/src/msw/treectrl.cpp: In member function 'virtual bool wxTreeCtrl::MSWOnNotify(int, WXLPARAM, WXLPARAM*)': C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/src/msw/treectrl.cpp:3280:17: error: 'NMTVDISPINFOWW' was not declared in this scope TV_DISPINFO *info = (TV_DISPINFO *)lParam; ^ It appears that TV_DISPINFO is getting defined as NMTVDISPINFOWW instead of NMTVDISPINFOW. I'm not sure where the problem is occurring. I grepped the wxWidgets source and I don't see TV_DISPINFO being manipulated anywhere so I'm guessing it somewhere in the new win32api headers. This error first occurred when I updated my existing MinGW installation last week and it also occurs on completely clean install as of today. I verified there a no other SDK header files in my $PATH that could cause issues and I do not have mingw32-wsl_rc installed. I want to make sure I'm (or wxWidgets is) not doing anything wrong before I file a bug report. Thanks in advance for the help. Wayne |
From: Earnie B. <ea...@us...> - 2013-09-03 21:30:00
|
On Tue, Sep 3, 2013 at 3:39 PM, Wayne Stambaugh wrote: > As of version 4 of win32api, wxWidgets 2.9.x fails to build with both > gcc 4.7.2 and the latest 4.8.1 with the following error: > > In file included from > C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/msw/gccpriv.h:22:0, > from > C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/platform.h:455, > from > C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/defs.h:28, > from > C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/wxprec.h:13: > C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/src/msw/treectrl.cpp: > In member function 'virtual bool wxTreeCtrl::MSWOnNotify(int, WXLPARAM, > WXLPARAM*)': > C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/src/msw/treectrl.cpp:3280:17: > error: 'NMTVDISPINFOWW' was not declared in this scope > TV_DISPINFO *info = (TV_DISPINFO *)lParam; > ^ > > It appears that TV_DISPINFO is getting defined as NMTVDISPINFOWW instead > of NMTVDISPINFOW. I'm not sure where the problem is occurring. I > grepped the wxWidgets source and I don't see TV_DISPINFO being > manipulated anywhere so I'm guessing it somewhere in the new win32api > headers. This error first occurred when I updated my existing MinGW > installation last week and it also occurs on completely clean install as > of today. I verified there a no other SDK header files in my $PATH that > could cause issues and I do not have mingw32-wsl_rc installed. I want > to make sure I'm (or wxWidgets is) not doing anything wrong before I > file a bug report. Thanks in advance for the help. If you edit line 2217 of /mingw/include/commctrl.h to read #define TV_DISPINFO NMTVDISPINFO instead of #define TV_DISPINFO __AW(NMTVDISPINFO) Does it help? -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Wayne S. <sta...@ve...> - 2013-09-04 13:05:39
|
On 9/3/2013 5:29 PM, Earnie Boyd wrote: > On Tue, Sep 3, 2013 at 3:39 PM, Wayne Stambaugh wrote: >> As of version 4 of win32api, wxWidgets 2.9.x fails to build with both >> gcc 4.7.2 and the latest 4.8.1 with the following error: >> >> In file included from >> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/msw/gccpriv.h:22:0, >> from >> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/platform.h:455, >> from >> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/defs.h:28, >> from >> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/wxprec.h:13: >> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/src/msw/treectrl.cpp: >> In member function 'virtual bool wxTreeCtrl::MSWOnNotify(int, WXLPARAM, >> WXLPARAM*)': >> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/src/msw/treectrl.cpp:3280:17: >> error: 'NMTVDISPINFOWW' was not declared in this scope >> TV_DISPINFO *info = (TV_DISPINFO *)lParam; >> ^ >> >> It appears that TV_DISPINFO is getting defined as NMTVDISPINFOWW instead >> of NMTVDISPINFOW. I'm not sure where the problem is occurring. I >> grepped the wxWidgets source and I don't see TV_DISPINFO being >> manipulated anywhere so I'm guessing it somewhere in the new win32api >> headers. This error first occurred when I updated my existing MinGW >> installation last week and it also occurs on completely clean install as >> of today. I verified there a no other SDK header files in my $PATH that >> could cause issues and I do not have mingw32-wsl_rc installed. I want >> to make sure I'm (or wxWidgets is) not doing anything wrong before I >> file a bug report. Thanks in advance for the help. > > If you edit line 2217 of /mingw/include/commctrl.h to read > > #define TV_DISPINFO NMTVDISPINFO > > instead of > > #define TV_DISPINFO __AW(NMTVDISPINFO) > > Does it help? > That fixed it. Thanks. Do you want me to file a bug report against this? I wonder if there are any other definitions that use the __AW() macro that also suffer from this problem. |
From: Earnie B. <ea...@us...> - 2013-09-04 20:35:35
|
On Wed, Sep 4, 2013 at 9:05 AM, Wayne Stambaugh wrote: > On 9/3/2013 5:29 PM, Earnie Boyd wrote: >> On Tue, Sep 3, 2013 at 3:39 PM, Wayne Stambaugh wrote: >>> As of version 4 of win32api, wxWidgets 2.9.x fails to build with both >>> gcc 4.7.2 and the latest 4.8.1 with the following error: >>> >>> In file included from >>> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/msw/gccpriv.h:22:0, >>> from >>> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/platform.h:455, >>> from >>> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/defs.h:28, >>> from >>> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/wxprec.h:13: >>> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/src/msw/treectrl.cpp: >>> In member function 'virtual bool wxTreeCtrl::MSWOnNotify(int, WXLPARAM, >>> WXLPARAM*)': >>> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/src/msw/treectrl.cpp:3280:17: >>> error: 'NMTVDISPINFOWW' was not declared in this scope >>> TV_DISPINFO *info = (TV_DISPINFO *)lParam; >>> ^ >>> >>> It appears that TV_DISPINFO is getting defined as NMTVDISPINFOWW instead >>> of NMTVDISPINFOW. I'm not sure where the problem is occurring. I >>> grepped the wxWidgets source and I don't see TV_DISPINFO being >>> manipulated anywhere so I'm guessing it somewhere in the new win32api >>> headers. This error first occurred when I updated my existing MinGW >>> installation last week and it also occurs on completely clean install as >>> of today. I verified there a no other SDK header files in my $PATH that >>> could cause issues and I do not have mingw32-wsl_rc installed. I want >>> to make sure I'm (or wxWidgets is) not doing anything wrong before I >>> file a bug report. Thanks in advance for the help. >> >> If you edit line 2217 of /mingw/include/commctrl.h to read >> >> #define TV_DISPINFO NMTVDISPINFO >> >> instead of >> >> #define TV_DISPINFO __AW(NMTVDISPINFO) >> >> Does it help? >> > > That fixed it. Thanks. Do you want me to file a bug report against > this? I wonder if there are any other definitions that use the __AW() > macro that also suffer from this problem. I'll open the report. There maybe others, especially if they are similar to this one. I long for a good testing system for each element. Even an external build bot that runs a testing sequence and creates an online report. Dreaming ... -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Lothar <lot...@lo...> - 2013-11-02 13:30:11
|
Hi, I have the same issue because i have implemented a mingw installer for my source code. This has worked for some time when I released my software. As it gets the latest release of mingw now I am stuck and try to stick on an older mingw release. I think one thing would be providing a patch file (replacing commctrl.h by a modified after mingw has been installed). But what happens with future changes in mingw if I still get the latest version? To overcome this I tried to use this batch file to stick on a version that I have tested: @rem This batch will download and install MinGW by mingw-get %1 is 4.6.* in my case Develop\Tools\MinGW\bin\mingw-get install "mingw=%1" Develop\Tools\MinGW\bin\mingw-get install "mingw32-make" Develop\Tools\MinGW\bin\mingw-get install "g++=%1" @rem Required to compile ACE Develop\Tools\MinGW\bin\mingw-get install msys But then I get other errors. How could I stick on a release around the date 2013/7/20? Thanks, Lothar Beside the issue: I am trying to automate my deployment with these batch files that are called optionally from my Innosetup installer. This may for me a starting point into Continuous Delivery http://en.wikipedia.org/wiki/Continuous_delivery Am 04.09.2013 um 22:35 schrieb Earnie Boyd: > On Wed, Sep 4, 2013 at 9:05 AM, Wayne Stambaugh wrote: >> On 9/3/2013 5:29 PM, Earnie Boyd wrote: >>> On Tue, Sep 3, 2013 at 3:39 PM, Wayne Stambaugh wrote: >>>> As of version 4 of win32api, wxWidgets 2.9.x fails to build with both >>>> gcc 4.7.2 and the latest 4.8.1 with the following error: >>>> >>>> In file included from >>>> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/msw/gccpriv.h:22:0, >>>> from >>>> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/platform.h:455, >>>> from >>>> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/defs.h:28, >>>> from >>>> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/include/wx/wxprec.h:13: >>>> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/src/msw/treectrl.cpp: >>>> In member function 'virtual bool wxTreeCtrl::MSWOnNotify(int, WXLPARAM, >>>> WXLPARAM*)': >>>> C:/MinGW/msys/1.0/home/Wayne/src/wxWidgets-2.9.5/src/msw/treectrl.cpp:3280:17: >>>> error: 'NMTVDISPINFOWW' was not declared in this scope >>>> TV_DISPINFO *info = (TV_DISPINFO *)lParam; >>>> ^ >>>> >>>> It appears that TV_DISPINFO is getting defined as NMTVDISPINFOWW instead >>>> of NMTVDISPINFOW. I'm not sure where the problem is occurring. I >>>> grepped the wxWidgets source and I don't see TV_DISPINFO being >>>> manipulated anywhere so I'm guessing it somewhere in the new win32api >>>> headers. This error first occurred when I updated my existing MinGW >>>> installation last week and it also occurs on completely clean install as >>>> of today. I verified there a no other SDK header files in my $PATH that >>>> could cause issues and I do not have mingw32-wsl_rc installed. I want >>>> to make sure I'm (or wxWidgets is) not doing anything wrong before I >>>> file a bug report. Thanks in advance for the help. >>> >>> If you edit line 2217 of /mingw/include/commctrl.h to read >>> >>> #define TV_DISPINFO NMTVDISPINFO >>> >>> instead of >>> >>> #define TV_DISPINFO __AW(NMTVDISPINFO) >>> >>> Does it help? >>> >> >> That fixed it. Thanks. Do you want me to file a bug report against >> this? I wonder if there are any other definitions that use the __AW() >> macro that also suffer from this problem. > > I'll open the report. There maybe others, especially if they are > similar to this one. I long for a good testing system for each > element. Even an external build bot that runs a testing sequence and > creates an online report. Dreaming ... > > -- > Earnie > -- https://sites.google.com/site/earnieboyd > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Ginsterweg 4 65760 Eschborn |
From: Nathan R. <zer...@ho...> - 2014-05-31 06:02:55
|
>>> If you edit line 2217 of /mingw/include/commctrl.h to read >>> >>> #define TV_DISPINFO NMTVDISPINFO >>> >>> instead of >>> >>> #define TV_DISPINFO __AW(NMTVDISPINFO) >>> >>> Does it help? >>> >> >> That fixed it. Thanks. Do you want me to file a bug report against >> this? I wonder if there are any other definitions that use the __AW() >> macro that also suffer from this problem. > > I'll open the report. There maybe others, especially if they are > similar to this one. I long for a good testing system for each > element. Even an external build bot that runs a testing sequence and > creates an online report. Dreaming ... What is the status of this? In w32api-4.0.3-1, TV_DISPINFO still seems to be defined as __AW(NMTVDISPINFO), and as a result, wxWidgets still does not compile. (And people are recommending using MinGW-w64 instead as a solution [1].) Thanks, Nate [1] http://stackoverflow.com/questions/19476533/error-while-compiling-wxwidgets-2-8-12-on-mingw-with-gcc-4-8-1 |
From: Manolo <man...@gm...> - 2014-05-31 14:49:42
|
El 31/05/14 08:02, Nathan Ridge escribió: > In w32api-4.0.3-1, TV_DISPINFO still seems to be defined as > __AW(NMTVDISPINFO), and as a result, wxWidgets still does not > compile. (And people are recommending using MinGW-w64 instead > as a solution [1].) In the stackoverflow-link we can see 'NMTVDISPINFOWW' (notice the two 'W') There's a problem (I don't know where) of a double use of __AW() macro. Regards, Manolo |
From: Nathan R. <zer...@ho...> - 2014-05-31 19:37:12
|
>> In w32api-4.0.3-1, TV_DISPINFO still seems to be defined as >> __AW(NMTVDISPINFO), and as a result, wxWidgets still does not >> compile. (And people are recommending using MinGW-w64 instead >> as a solution [1].) > > In the stackoverflow-link we can see 'NMTVDISPINFOWW' (notice the two 'W') > There's a problem (I don't know where) of a double use of __AW() macro. The problem is on the line immediately below: #define TV_DISPINFO __AW(NMTVDISPINFO) #define NMTVDISPINFO __AW(NMTVDISPINFO) Perhaps the correct solution is to omit the second line. Either way, the point is, this is a bug in the MinGW headers that's preventing the compilation of a major open-source C++ project, and it really should be fixed. Regards, Nate |
From: Keith M. <kei...@us...> - 2014-06-01 07:06:15
|
On 31/05/14 20:37, Nathan Ridge wrote: >>> In w32api-4.0.3-1, TV_DISPINFO still seems to be defined as >>> __AW(NMTVDISPINFO), and as a result, wxWidgets still does not >>> compile. (And people are recommending using MinGW-w64 instead >>> as a solution [1].) >> >> In the stackoverflow-link we can see 'NMTVDISPINFOWW' (notice the two 'W') >> There's a problem (I don't know where) of a double use of __AW() macro. > > The problem is on the line immediately below: > > #define TV_DISPINFO __AW(NMTVDISPINFO) > #define NMTVDISPINFO __AW(NMTVDISPINFO) Right. The intent of this is correct: MSDN tells us that TV_DISPINFO is a deprecated name for the structure now known as NMTVDISPINFO, so it is correct that TV_DISPINFO should map to one or other of NMTVDISPINFOA or NMTVDISPINFOW, according to whether the context is ANSI or Unicode. The problem lies in the definition of TV_DISPINFO, given that the __AW macro expands its argument recursively: NMTVDISPINFO itself expands to NMTVDISPINFOA or NMTVDISPINFOW, as appropriate, and the recursive round trip to expand TV_DISPINFO then adds a second A or W suffix to the already expanded result. > Perhaps the correct solution is to omit the second line. Nope. If either is wrong, then it is the first; it could, perhaps, simply delegate the expansion to NMTVDISPINFO: #define TV_DISPINFO NMTVDISPINFO but perhaps the real problem is in the (overly complicated) definition of __AW itself; does it really need to be expanded recursively? > Either way, the point is, this is a bug in the MinGW headers that's > preventing the compilation of a major open-source C++ project, and > it really should be fixed. So, fix it and submit a patch: http://www.mingw.org/wiki/SubmitPatches Better yet, join the project, and actively participate in maintaining it. Version 4.x of the MinGW runtime and W32API is TARFU; until the original perpetrator of the shambles (Earnie) can find the time to fix it, or someone else steps up to the plate with an offer of assistance, it is likely to remain so. Until such time, it may be better to stick with version 3.20 of mingwrt, and 3.17 of w32api. -- Regards, Keith. |
From: Nathan R. <zer...@ho...> - 2014-06-01 07:49:44
|
> but perhaps the real problem is in the (overly complicated) definition > of __AW itself; does it really need to be expanded recursively? The comment before its definition says "This is accomplished by macro expansion of the symbol passed and concatenating either A or W to the symbol", suggesting that expanding the argument is done deliberately, and thus, presumably, for good reason. > So, fix it and submit a patch: http://www.mingw.org/wiki/SubmitPatches I filed https://sourceforge.net/p/mingw/bugs/2217/ and posted a patch there. > Version 4.x of the MinGW runtime and W32API is TARFU; until the > original perpetrator of the shambles (Earnie) can find the time to fix > it, or someone else steps up to the plate with an offer of assistance, > it is likely to remain so. Until such time, it may be better to stick > with version 3.20 of mingwrt, and 3.17 of w32api. Perhaps it would be better if mingw-get installed these versions by default, then? Regards, Nate |
From: Keith M. <kei...@us...> - 2014-06-01 09:05:46
|
On 01/06/14 08:49, Nathan Ridge wrote: >> Version 4.x of the MinGW runtime and W32API is TARFU; until the >> original perpetrator of the shambles (Earnie) can find the time to fix >> it, or someone else steps up to the plate with an offer of assistance, >> it is likely to remain so. Until such time, it may be better to stick >> with version 3.20 of mingwrt, and 3.17 of w32api. > > Perhaps it would be better if mingw-get installed these versions by > default, then? Of course it would. The issue still remains, that _someone_ needs to step up to the plate, and take responsibility for making that happen. -- Regards, Keith. |
From: Nathan R. <zer...@ho...> - 2014-06-01 22:37:46
|
> On 01/06/14 08:49, Nathan Ridge wrote: >>> Version 4.x of the MinGW runtime and W32API is TARFU; until the >>> original perpetrator of the shambles (Earnie) can find the time to fix >>> it, or someone else steps up to the plate with an offer of assistance, >>> it is likely to remain so. Until such time, it may be better to stick >>> with version 3.20 of mingwrt, and 3.17 of w32api. >> >> Perhaps it would be better if mingw-get installed these versions by >> default, then? > > Of course it would. The issue still remains, that _someone_ needs to > step up to the plate, and take responsibility for making that happen. I don't know much about how mingw-get works, but shouldn't it be as simple as modifying an XML or manifest file that says what the latest version of w32api is, to say 3.17 instead of 4.x? Regards, Nate |
From: Keith M. <kei...@us...> - 2014-08-26 22:00:44
|
On 01/06/14 23:37, Nathan Ridge wrote: >> On 01/06/14 08:49, Nathan Ridge wrote: >>>> Version 4.x of the MinGW runtime and W32API is TARFU; until the >>>> original perpetrator of the shambles (Earnie) can find the time to fix >>>> it, or someone else steps up to the plate with an offer of assistance, >>>> it is likely to remain so. Until such time, it may be better to stick >>>> with version 3.20 of mingwrt, and 3.17 of w32api. >>> >>> Perhaps it would be better if mingw-get installed these versions by >>> default, then? >> >> Of course it would. The issue still remains, that _someone_ needs to >> step up to the plate, and take responsibility for making that happen. > > I don't know much about how mingw-get works, but shouldn't it be > as simple as modifying an XML or manifest file that says what the > latest version of w32api is, to say 3.17 instead of 4.x? Not quite that simple, I'm afraid. Anyhow, since Earnie has not taken any corrective action in positively ages, I've taken it upon myself to revert mingw32-runtime.xml to its pre-4.x state, and to adjust all GCC dependencies, to remove any "requires" references for 4.x. For any users who are experiencing problems with mingwrt-4.x, or with w32api-4.x, I strongly recommend that you: $ mingw-get update $ mingw-get remove mingwrt w32api $ mingw-get install mingwrt w32api to revert your installation to 3.x -- Regards, Keith. |