From: Kyle A. <kyl...@gm...> - 2009-01-25 01:30:00
|
Hi All, I am compiling PLPlot for use with wxWidgets via C++ on Windows (and eventually Linux, etc)... except that CMake doesn't find wxWidgets when setting up for PLPlot compilation. I tried to look at the FindwxWidgets.cmake file but when I set WXWIN (which seemed applicable) in the shell it didn't seem to make a difference. I did note though that the file had a large list of wxWidgets versions both higher and lower than 2.8.9, but not 2.8.9 itself. It made no difference when I added a line for that. I am using: Windows XP Pro SP3 MinGW 5.1.4 ( C:/MinGW ) MSYS 1.0.11 ( C:/MSYS, but removed from Path variable when running CMake) wxWidgets 2.8.9 ( C:/MinGW/wxWidgets-2.8.9, but installed into MinGW folders ) PLPlot 5.9.2 If you have any pointers, that'd be greatly appreciated. Maybe where CMAKE_LIBRARY_PATH or CMAKE_INCLUDE_PATH should point? Thanks, -kyle |
From: Werner S. <sm...@ia...> - 2009-01-25 08:58:48
|
Hi Kyle, which version of CMake do you use? Because 2.8.9 is definitely included in my FindwxWidgets.cmake, CMake Version 2.6.2. Apart from that, to begin with, you should follow exactly the instructions I wrote here: http://www.miscdebris.net/plplot_wiki/index.php?title=WxWidgets#Instructions_for_Windows If this works, we can try to change things and see where it breaks. The instructions above use the Windows CLI and not MSys. Regards, Werner Kyle Altendorf wrote: > Hi All, > > I am compiling PLPlot for use with wxWidgets via C++ on Windows (and > eventually Linux, etc)... except that CMake doesn't find wxWidgets > when setting up for PLPlot compilation. I tried to look at the > FindwxWidgets.cmake file but when I set WXWIN (which seemed > applicable) in the shell it didn't seem to make a difference. I did > note though that the file had a large list of wxWidgets versions both > higher and lower than 2.8.9, but not 2.8.9 itself. It made no > difference when I added a line for that. I am using: > > Windows XP Pro SP3 > MinGW 5.1.4 ( C:/MinGW ) > MSYS 1.0.11 ( C:/MSYS, but removed from Path variable when running CMake) > wxWidgets 2.8.9 ( C:/MinGW/wxWidgets-2.8.9, but installed into MinGW folders ) > PLPlot 5.9.2 > > If you have any pointers, that'd be greatly appreciated. Maybe where > CMAKE_LIBRARY_PATH or CMAKE_INCLUDE_PATH should point? > > Thanks, > -kyle > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general > -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Kyle A. <kyl...@gm...> - 2009-01-25 23:52:58
|
Hi Werner, Thanks for the quick reply. Once again, I overlooked the one most important line in the guide several times... and when I followed it, it worked. Well, it got a bit further. CMake now reports that it can find the wxWidgets library, but the compilation still fails when wx/wx.h is attempted to be included. I am using the following command in cmd.exe: cmake -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=install -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Release -DwxWidgets_CONFIGURATION=msw -DENABLE_MIX_CXX=ON -DwxWidgets_LIB_DIR=C:/MinGW/lib -DwxWidgets_INCLUDE_DIRS=C:/MinGW/include/wx-2.8 .. >From what I can tell, CMake is not setting the include paths for wxWidgets nor is it doing anything with the wxWidgets_INCLUDE_DIRS variable I tried specifying (based on references in both FindwxWidgets.cmake and UsewxWidgets.cmake). When I look in the build.make file from plplotd.dir the entries for wxWidgets related compilation have a -I option specified (right after $(CXX_FLAGS)) but only has a space for the value. src/CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.obj: src/CMakeFiles/plplotd.dir/flags.make src/CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.obj: ../drivers/wxwidgets_app.cpp $(CMAKE_COMMAND) -E cmake_progress_report D:\Projects\wxWidgetsTest\installationResources\plplot-5.9.2\buildmingw\CMakeFiles $(CMAKE_PROGRESS_38) @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green "Building CXX object src/CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.obj" cd D:\Projects\wxWidgetsTest\installationResources\plplot-5.9.2\buildmingw\src && C:\MinGW\bin\g++.exe $(CXX_DEFINES) $(CXX_FLAGS) -I -o CMakeFiles\plplotd.dir\__\drivers\wxwidgets_app.obj -c D:\Projects\wxWidgetsTest\installationResources\plplot-5.9.2\drivers\wxwidgets_app.cpp If I manually edit the file and put in the required -I<path> options (there are actually two), then that section builds fine and a failure occurs later on. I have not looked into the later failure, but it appears to be something similar. I realize that I may not have the files in their 'normal' locations, but I would expect to have control over the include paths same as I do with the library path via wxWidgets_LIB_DIR. Is there another option I should be using? If so, what is the syntax for multiple paths since two are required? I tried specifying CMAKE_CXX_FLAGS but it leaves the blank -I option in the g++ call which causes g++ to mis-parse the command line and get confused claiming it can't find the wxwidgets_app.obj file. Of course CMAKE_CXX_FLAGS would be less than preferable to use for wxWidgets specific includes anyways since most g++ calls wouldn't need those paths. As for the CMake version, etc. I am using CMake v2.6.2 (cmake --version reports 2.6-patch 2) downloaded from: http://www.cmake.org/files/v2.6/cmake-2.6.2-win32-x86.exe What I was referring to as far as CMake 'missing' wxWidgets-2.8.9 is based on the following excerpt from C:/Program Files/CMake 2.6/share/cmake-2.6/Modules/FindwxWidgets.cmake: PATH_SUFFIXES wxWidgets-2.9.4 wxWidgets-2.9.3 wxWidgets-2.9.2 wxWidgets-2.9.1 wxWidgets-2.9.0 wxWidgets-2.8.8 wxWidgets-2.8.7 wxWidgets-2.8.6 Based on my non-existent knowledge of CMake's inner workings, it seems that if I had C:/wxWidgets-2.8.8 then CMake would find it based on the C:/ entry under PATHS and the wxWidgets-2.8.8 entry under PATH_SUFFIXES. On the other hand, I would think that C:/wxWidgets-2.8.9 would not be found automatically since it seems to be missing from the PATH_SUFFIXES list. Thanks (again), -kyle On Sun, Jan 25, 2009 at 12:58 AM, Werner Smekal <sm...@ia...> wrote: > Hi Kyle, > > which version of CMake do you use? Because 2.8.9 is definitely included in > my FindwxWidgets.cmake, CMake Version 2.6.2. Apart from that, to begin with, > you should follow exactly the instructions I wrote here: > > http://www.miscdebris.net/plplot_wiki/index.php?title=WxWidgets#Instructions_for_Windows > > If this works, we can try to change things and see where it breaks. The > instructions above use the Windows CLI and not MSys. > > Regards, > Werner > > Kyle Altendorf wrote: >> >> Hi All, >> >> I am compiling PLPlot for use with wxWidgets via C++ on Windows (and >> eventually Linux, etc)... except that CMake doesn't find wxWidgets >> when setting up for PLPlot compilation. I tried to look at the >> FindwxWidgets.cmake file but when I set WXWIN (which seemed >> applicable) in the shell it didn't seem to make a difference. I did >> note though that the file had a large list of wxWidgets versions both >> higher and lower than 2.8.9, but not 2.8.9 itself. It made no >> difference when I added a line for that. I am using: >> >> Windows XP Pro SP3 >> MinGW 5.1.4 ( C:/MinGW ) >> MSYS 1.0.11 ( C:/MSYS, but removed from Path variable when running CMake) >> wxWidgets 2.8.9 ( C:/MinGW/wxWidgets-2.8.9, but installed into MinGW >> folders ) >> PLPlot 5.9.2 >> >> If you have any pointers, that'd be greatly appreciated. Maybe where >> CMAKE_LIBRARY_PATH or CMAKE_INCLUDE_PATH should point? >> >> Thanks, >> -kyle >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Plplot-general mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-general >> > > > -- > Dr. Werner Smekal > Institut fuer Allgemeine Physik > Technische Universitaet Wien > Wiedner Hauptstr 8-10 > A-1040 Wien > Austria > DVR-Nr: 0005886 > > email: sm...@ia... > web: http://www.iap.tuwien.ac.at/~smekal > phone: +43-(0)1-58801-13463 (office) > +43-(0)1-58801-13469 (laboratory) > fax: +43-(0)1-58801-13499 > > |
From: Werner S. <sm...@ia...> - 2009-01-28 09:20:50
|
Hi Kyle, sorry for the long time I needed to reply: On 26.01.2009, at 00:52, Kyle Altendorf wrote: > Hi Werner, > > Thanks for the quick reply. Once again, I overlooked the one most > important line in the guide several times... and when I followed it, > it worked. Well, it got a bit further. CMake now reports that it can > find the wxWidgets library, but the compilation still fails when > wx/wx.h is attempted to be included. I am using the following command > in cmd.exe: > > cmake -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=install > -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Release > -DwxWidgets_CONFIGURATION=msw -DENABLE_MIX_CXX=ON > -DwxWidgets_LIB_DIR=C:/MinGW/lib > -DwxWidgets_INCLUDE_DIRS=C:/MinGW/include/wx-2.8 .. You don't need to specify wxWidgets_LIB_DIR and wxWidgets_INCLUDE_DIRS if you set the WXWIN variable. Are you sure the WXWIN variable is set correctly? test it with set WXWIN But wait, this is completely a non standard location (c:/mingw) it's logical that FindwxWidgets doesn't find it. wxWidgets on Windows is not expected to be installed. You unzip or install the wxWidgets source code and set the WXWIN environment variable to the base path, e.g. c:\wxwidgets-2.8.9 than you cd in to build/msw and run the makefile which creates the library in the lib/gcc-dll or something similar directory. If you set the WXWIN variable correctly, FindwxWidgets.cmake is able to pick up the library information even if 2.8.9 is not in FindwxWidgets.cmake (sorry about the wrong email before, 2.8.9 is not in FindwxWidgets.cmake, but this is not problem as long as you set the WXWIN environment variable). So please try that, and don't use MSys to compile wxWidgets, stick to the Windows CLI and mingw32-make Regards, Werner > > From what I can tell, CMake is not setting the include paths for > wxWidgets nor is it doing anything with the wxWidgets_INCLUDE_DIRS > variable I tried specifying (based on references in both > FindwxWidgets.cmake and UsewxWidgets.cmake). When I look in the > build.make file from plplotd.dir the entries for wxWidgets related > compilation have a -I option specified (right after $(CXX_FLAGS)) but > only has a space for the value. > > src/CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.obj: > src/CMakeFiles/plplotd.dir/flags.make > src/CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.obj: > ../drivers/wxwidgets_app.cpp > $(CMAKE_COMMAND) -E cmake_progress_report > D:\Projects\wxWidgetsTest\installationResources > \plplot-5.9.2\buildmingw\CMakeFiles > $(CMAKE_PROGRESS_38) > @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green > "Building CXX object > src/CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.obj" > cd D:\Projects\wxWidgetsTest\installationResources > \plplot-5.9.2\buildmingw\src > && C:\MinGW\bin\g++.exe $(CXX_DEFINES) $(CXX_FLAGS) -I -o > CMakeFiles\plplotd.dir\__\drivers\wxwidgets_app.obj -c > D:\Projects\wxWidgetsTest\installationResources\plplot-5.9.2\drivers > \wxwidgets_app.cpp > > If I manually edit the file and put in the required -I<path> options > (there are actually two), then that section builds fine and a failure > occurs later on. I have not looked into the later failure, but it > appears to be something similar. I realize that I may not have the > files in their 'normal' locations, but I would expect to have control > over the include paths same as I do with the library path via > wxWidgets_LIB_DIR. Is there another option I should be using? If so, > what is the syntax for multiple paths since two are required? I tried > specifying CMAKE_CXX_FLAGS but it leaves the blank -I option in the > g++ call which causes g++ to mis-parse the command line and get > confused claiming it can't find the wxwidgets_app.obj file. Of course > CMAKE_CXX_FLAGS would be less than preferable to use for wxWidgets > specific includes anyways since most g++ calls wouldn't need those > paths. > > > As for the CMake version, etc. I am using CMake v2.6.2 (cmake > --version reports 2.6-patch 2) downloaded from: > > http://www.cmake.org/files/v2.6/cmake-2.6.2-win32-x86.exe > > What I was referring to as far as CMake 'missing' wxWidgets-2.8.9 is > based on the following excerpt from C:/Program Files/CMake > 2.6/share/cmake-2.6/Modules/FindwxWidgets.cmake: > > PATH_SUFFIXES > wxWidgets-2.9.4 > wxWidgets-2.9.3 > wxWidgets-2.9.2 > wxWidgets-2.9.1 > wxWidgets-2.9.0 > wxWidgets-2.8.8 > wxWidgets-2.8.7 > wxWidgets-2.8.6 > > Based on my non-existent knowledge of CMake's inner workings, it seems > that if I had C:/wxWidgets-2.8.8 then CMake would find it based on the > C:/ entry under PATHS and the wxWidgets-2.8.8 entry under > PATH_SUFFIXES. On the other hand, I would think that > C:/wxWidgets-2.8.9 would not be found automatically since it seems to > be missing from the PATH_SUFFIXES list. > > Thanks (again), > -kyle > > On Sun, Jan 25, 2009 at 12:58 AM, Werner Smekal <sm...@ia... > > wrote: >> Hi Kyle, >> >> which version of CMake do you use? Because 2.8.9 is definitely >> included in >> my FindwxWidgets.cmake, CMake Version 2.6.2. Apart from that, to >> begin with, >> you should follow exactly the instructions I wrote here: >> >> http://www.miscdebris.net/plplot_wiki/index.php?title=WxWidgets#Instructions_for_Windows >> >> If this works, we can try to change things and see where it breaks. >> The >> instructions above use the Windows CLI and not MSys. >> >> Regards, >> Werner >> >> Kyle Altendorf wrote: >>> >>> Hi All, >>> >>> I am compiling PLPlot for use with wxWidgets via C++ on Windows (and >>> eventually Linux, etc)... except that CMake doesn't find wxWidgets >>> when setting up for PLPlot compilation. I tried to look at the >>> FindwxWidgets.cmake file but when I set WXWIN (which seemed >>> applicable) in the shell it didn't seem to make a difference. I did >>> note though that the file had a large list of wxWidgets versions >>> both >>> higher and lower than 2.8.9, but not 2.8.9 itself. It made no >>> difference when I added a line for that. I am using: >>> >>> Windows XP Pro SP3 >>> MinGW 5.1.4 ( C:/MinGW ) >>> MSYS 1.0.11 ( C:/MSYS, but removed from Path variable when running >>> CMake) >>> wxWidgets 2.8.9 ( C:/MinGW/wxWidgets-2.8.9, but installed into MinGW >>> folders ) >>> PLPlot 5.9.2 >>> >>> If you have any pointers, that'd be greatly appreciated. Maybe >>> where >>> CMAKE_LIBRARY_PATH or CMAKE_INCLUDE_PATH should point? >>> >>> Thanks, >>> -kyle >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by: >>> SourcForge Community >>> SourceForge wants to tell your story. >>> http://p.sf.net/sfu/sf-spreadtheword >>> _______________________________________________ >>> Plplot-general mailing list >>> Plp...@li... >>> https://lists.sourceforge.net/lists/listinfo/plplot-general >>> >> >> >> -- >> Dr. Werner Smekal >> Institut fuer Allgemeine Physik >> Technische Universitaet Wien >> Wiedner Hauptstr 8-10 >> A-1040 Wien >> Austria >> DVR-Nr: 0005886 >> >> email: sm...@ia... >> web: http://www.iap.tuwien.ac.at/~smekal >> phone: +43-(0)1-58801-13463 (office) >> +43-(0)1-58801-13469 (laboratory) >> fax: +43-(0)1-58801-13499 >> >> -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Kyle A. <kyl...@gm...> - 2009-01-29 03:32:30
|
> sorry for the long time I needed to reply: No worries... if you're going to share your time, it should be on your schedule. :] As to the WXWIN variable, yes, it is set correctly. Also, I am being sure to use cmd.exe and to remove the MSYS folder from my path to make sure that sh won't be found. > But wait, this is completely a non standard location (c:/mingw) it's logical > that FindwxWidgets doesn't find it. wxWidgets on Windows is not expected to Because of where I put it, I would not expect wxWidgets to be found automatically. The configuration is the result of following other internet instructions for getting wxWidgets compiled and setup in an Eclipse project. Trust me, I wasn't excited about their approach either and fully plan to change it. I hate getting tied into someone else's choice of where to store files, especially when they are getting mixed up with another package (e.g., installing wxWidgets binaries into MinGW). Still, it bugs me that even when I manually specify the wxWidgets_INCLUDE_DIRS option nothing ends up in the appropriate command lines in the build.make file as I mentioned before. Not only is the path not included in the command line, but the command doesn't even make sense since it retains the -I option. cd D:\Projects\wxWidgetsTest\installationResources\plplot-5.9.2\buildmingw\src && C:\MinGW\bin\g++.exe $(CXX_DEFINES) $(CXX_FLAGS) -I -o CMakeFiles\plplotd.dir\__\drivers\wxwidgets_app.obj -c D:\Projects\wxWidgetsTest\installationResources\plplot-5.9.2\drivers\wxwidgets_app.cpp Remember that when I manually added the path I specified for the wxWidgets_INCLUDE_DIR option after the -I, the build worked fine through that section. This seems like a bug since it should at least throw an error rather than setting a blank include path even if I'm not using the right option. I guess that overall I'm not just interested in getting this working (I'll recompile wxWidgets with your approach to try to make that happen), but also in getting control over it so that I'm not tied into storing the files in a particular location or compiling with particular build options (release, unicode, shared, etc). Thanks again for your pointers, -kyle > be installed. You unzip or install the wxWidgets source code and set the > WXWIN environment variable to the base path, e.g. c:\wxwidgets-2.8.9 than > you cd in to build/msw and run the makefile which creates the library in the > lib/gcc-dll or something similar directory. If you set the WXWIN variable > correctly, FindwxWidgets.cmake is able to pick up the library information > even if 2.8.9 is not in FindwxWidgets.cmake (sorry about the wrong email > before, 2.8.9 is not in FindwxWidgets.cmake, but this is not problem as long > as you set the WXWIN environment variable). > > So please try that, and don't use MSys to compile wxWidgets, stick to the > Windows CLI and mingw32-make > > Regards, > Werner > >> >> From what I can tell, CMake is not setting the include paths for >> wxWidgets nor is it doing anything with the wxWidgets_INCLUDE_DIRS >> variable I tried specifying (based on references in both >> FindwxWidgets.cmake and UsewxWidgets.cmake). When I look in the >> build.make file from plplotd.dir the entries for wxWidgets related >> compilation have a -I option specified (right after $(CXX_FLAGS)) but >> only has a space for the value. >> >> src/CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.obj: >> src/CMakeFiles/plplotd.dir/flags.make >> src/CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.obj: >> ../drivers/wxwidgets_app.cpp >> $(CMAKE_COMMAND) -E cmake_progress_report >> >> D:\Projects\wxWidgetsTest\installationResources\plplot-5.9.2\buildmingw\CMakeFiles >> $(CMAKE_PROGRESS_38) >> @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green >> "Building CXX object >> src/CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.obj" >> cd >> D:\Projects\wxWidgetsTest\installationResources\plplot-5.9.2\buildmingw\src >> && C:\MinGW\bin\g++.exe $(CXX_DEFINES) $(CXX_FLAGS) -I -o >> CMakeFiles\plplotd.dir\__\drivers\wxwidgets_app.obj -c >> >> D:\Projects\wxWidgetsTest\installationResources\plplot-5.9.2\drivers\wxwidgets_app.cpp >> >> If I manually edit the file and put in the required -I<path> options >> (there are actually two), then that section builds fine and a failure >> occurs later on. I have not looked into the later failure, but it >> appears to be something similar. I realize that I may not have the >> files in their 'normal' locations, but I would expect to have control >> over the include paths same as I do with the library path via >> wxWidgets_LIB_DIR. Is there another option I should be using? If so, >> what is the syntax for multiple paths since two are required? I tried >> specifying CMAKE_CXX_FLAGS but it leaves the blank -I option in the >> g++ call which causes g++ to mis-parse the command line and get >> confused claiming it can't find the wxwidgets_app.obj file. Of course >> CMAKE_CXX_FLAGS would be less than preferable to use for wxWidgets >> specific includes anyways since most g++ calls wouldn't need those >> paths. >> >> >> As for the CMake version, etc. I am using CMake v2.6.2 (cmake >> --version reports 2.6-patch 2) downloaded from: >> >> http://www.cmake.org/files/v2.6/cmake-2.6.2-win32-x86.exe >> >> What I was referring to as far as CMake 'missing' wxWidgets-2.8.9 is >> based on the following excerpt from C:/Program Files/CMake >> 2.6/share/cmake-2.6/Modules/FindwxWidgets.cmake: >> >> PATH_SUFFIXES >> wxWidgets-2.9.4 >> wxWidgets-2.9.3 >> wxWidgets-2.9.2 >> wxWidgets-2.9.1 >> wxWidgets-2.9.0 >> wxWidgets-2.8.8 >> wxWidgets-2.8.7 >> wxWidgets-2.8.6 >> >> Based on my non-existent knowledge of CMake's inner workings, it seems >> that if I had C:/wxWidgets-2.8.8 then CMake would find it based on the >> C:/ entry under PATHS and the wxWidgets-2.8.8 entry under >> PATH_SUFFIXES. On the other hand, I would think that >> C:/wxWidgets-2.8.9 would not be found automatically since it seems to >> be missing from the PATH_SUFFIXES list. >> >> Thanks (again), >> -kyle >> >> On Sun, Jan 25, 2009 at 12:58 AM, Werner Smekal <sm...@ia...> >> wrote: >>> >>> Hi Kyle, >>> >>> which version of CMake do you use? Because 2.8.9 is definitely included >>> in >>> my FindwxWidgets.cmake, CMake Version 2.6.2. Apart from that, to begin >>> with, >>> you should follow exactly the instructions I wrote here: >>> >>> >>> http://www.miscdebris.net/plplot_wiki/index.php?title=WxWidgets#Instructions_for_Windows >>> >>> If this works, we can try to change things and see where it breaks. The >>> instructions above use the Windows CLI and not MSys. >>> >>> Regards, >>> Werner >>> >>> Kyle Altendorf wrote: >>>> >>>> Hi All, >>>> >>>> I am compiling PLPlot for use with wxWidgets via C++ on Windows (and >>>> eventually Linux, etc)... except that CMake doesn't find wxWidgets >>>> when setting up for PLPlot compilation. I tried to look at the >>>> FindwxWidgets.cmake file but when I set WXWIN (which seemed >>>> applicable) in the shell it didn't seem to make a difference. I did >>>> note though that the file had a large list of wxWidgets versions both >>>> higher and lower than 2.8.9, but not 2.8.9 itself. It made no >>>> difference when I added a line for that. I am using: >>>> >>>> Windows XP Pro SP3 >>>> MinGW 5.1.4 ( C:/MinGW ) >>>> MSYS 1.0.11 ( C:/MSYS, but removed from Path variable when running >>>> CMake) >>>> wxWidgets 2.8.9 ( C:/MinGW/wxWidgets-2.8.9, but installed into MinGW >>>> folders ) >>>> PLPlot 5.9.2 >>>> >>>> If you have any pointers, that'd be greatly appreciated. Maybe where >>>> CMAKE_LIBRARY_PATH or CMAKE_INCLUDE_PATH should point? >>>> >>>> Thanks, >>>> -kyle >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by: >>>> SourcForge Community >>>> SourceForge wants to tell your story. >>>> http://p.sf.net/sfu/sf-spreadtheword >>>> _______________________________________________ >>>> Plplot-general mailing list >>>> Plp...@li... >>>> https://lists.sourceforge.net/lists/listinfo/plplot-general >>>> >>> >>> >>> -- >>> Dr. Werner Smekal >>> Institut fuer Allgemeine Physik >>> Technische Universitaet Wien >>> Wiedner Hauptstr 8-10 >>> A-1040 Wien >>> Austria >>> DVR-Nr: 0005886 >>> >>> email: sm...@ia... >>> web: http://www.iap.tuwien.ac.at/~smekal >>> phone: +43-(0)1-58801-13463 (office) >>> +43-(0)1-58801-13469 (laboratory) >>> fax: +43-(0)1-58801-13499 >>> >>> > > -- > Dr. Werner Smekal > Institut fuer Allgemeine Physik > Technische Universitaet Wien > Wiedner Hauptstr 8-10 > A-1040 Wien > Austria > > email: sm...@ia... > web: http://www.iap.tuwien.ac.at/~smekal > phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) > fax: +43-(0)1-58801-13499 > > |
From: Kyle A. <kyl...@gm...> - 2009-02-09 01:51:51
|
I'm starting to feel like a helpless nag... no matter how many configurations I try for wxWidgets, PLplot or my own application I can't actually get them all to compile together. Anyways, I think I've found at least one relevant point that should be recorded in this thread. Previously I had compiled wxWidgets using ./configure within MSYS according to another guide. This resulted in the libraries being placed in a different folder structure than when using MinGW directly via cmd.exe as the PLplot wiki recommends. CMake actually offers two methods to search for wxWidgets. The variable wxWidgets_FIND_STYLE can be set as either unix or win32. Though I didn't get the find working with the unix style, I presume that that is why CMake had trouble finding my copy of wxWidgets. Back to following the instructions on the PLplot wiki. I compiled wxWidgets as release, shared and unicode. Then I moved on to CMake for PLplot specifying the mswu wxWidgets configuration and the wxWidgets_LIB_DIR. CMake found wxWidgets but failed to actually build with the following error: [ 60%] Building CXX object bindings/wxwidgets/CMakeFiles/plplotwxwidgetsd.dir/wx PLplotwindow.obj Linking CXX shared library ..\..\dll\libplplotwxwidgetsd.dll Creating library file: ..\..\dll\libplplotwxwidgetsd.dll.a CMakeFiles\plplotwxwidgetsd.dir\wxPLplotwindow.obj:wxPLplotwindow.cpp:(.text$_ZN 12wxStringBaseC2EPKc[wxStringBase::wxStringBase(char const*)]+0x27): undefined r eference to `_imp___ZN12wxStringBase8InitWithEPKcjj' collect2: ld returned 1 exit status On a side note, CMake really likes adding a 'd' onto the end of the LIB_TAG setting. I would think that for a release build this would be blank? And then? I recompiled wxWidgets (with both monolithic and not) and PLplot as static, unicode and release. Compilation of both went flawlessly, but when I compile my project I get: g++ -mthreads -DHAVE_W32API_H -D__WXMSW__ -D_UNICODE -ID:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\lib\gcc_lib\mswu -ID:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\include -Wno-ctor-dtor-privacy -pipe -fmessage-length=0 -ID:\Projects\wxWidgetsTest\Workspace\MinGW -ID:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install\include -O3 -Wall -c -fmessage-length=0 -owxGlade\wxMinimal.o ..\wxGlade\wxMinimal.cpp g++ -mthreads -DHAVE_W32API_H -D__WXMSW__ -D_UNICODE -ID:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\lib\gcc_lib\mswu -ID:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\include -Wno-ctor-dtor-privacy -pipe -fmessage-length=0 -ID:\Projects\wxWidgetsTest\Workspace\MinGW -ID:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install\include -O3 -Wall -c -fmessage-length=0 -osrc\minimal.o ..\src\minimal.cpp g++ -oMinGW.exe -mthreads -LD:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install\lib -LD:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\lib\gcc_lib wxGlade\wxMinimal.o src\minimal.o -lwxmsw28u_html -lwxmsw28u_adv -lwxmsw28u_core -lwxbase28u_xml -lwxbase28u_net -lwxbase28u -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwxregexu -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lplplotwxwidgetsd -lplplotd -lplplotcxxd -lcsirocsa D:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install\lib/libplplotd.a(wxwidgets.obj):wxwidgets.cpp:(.text+0xd2a): undefined reference to `wxStringBase::InitWith(char const*, unsigned int, unsigned int)' D:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install\lib/libplplotd.a(wxwidgets.obj):wxwidgets.cpp:(.text+0xd6e): undefined reference to `wxStringBase::InitWith(char const*, unsigned int, unsigned int)' - followed by a bunch more undefined references If I remove my one PLplot line ( plsdev("wxWidgets"); // just there to force PLplot code to be included ) and remove other include etc references to PLplot the project builds fine with just wxWidgets. I know that I need to develop my linker debugging abilities, but in the mean time, I would obviously still appreciate pointers or solutions. Thanks again, -kyle On Wed, Jan 28, 2009 at 7:32 PM, Kyle Altendorf <kyl...@gm...> wrote: >> sorry for the long time I needed to reply: > > No worries... if you're going to share your time, it should be on > your schedule. :] > > As to the WXWIN variable, yes, it is set correctly. Also, I am being > sure to use cmd.exe and to remove the MSYS folder from my path to make > sure that sh won't be found. > >> But wait, this is completely a non standard location (c:/mingw) it's logical >> that FindwxWidgets doesn't find it. wxWidgets on Windows is not expected to > > Because of where I put it, I would not expect wxWidgets to be found > automatically. The configuration is the result of following other > internet instructions for getting wxWidgets compiled and setup in an > Eclipse project. Trust me, I wasn't excited about their approach > either and fully plan to change it. I hate getting tied into someone > else's choice of where to store files, especially when they are > getting mixed up with another package (e.g., installing wxWidgets > binaries into MinGW). Still, it bugs me that even when I manually > specify the wxWidgets_INCLUDE_DIRS option nothing ends up in the > appropriate command lines in the build.make file as I mentioned > before. Not only is the path not included in the command line, but > the command doesn't even make sense since it retains the -I option. > > cd D:\Projects\wxWidgetsTest\installationResources\plplot-5.9.2\buildmingw\src > && C:\MinGW\bin\g++.exe $(CXX_DEFINES) $(CXX_FLAGS) -I -o > CMakeFiles\plplotd.dir\__\drivers\wxwidgets_app.obj -c > D:\Projects\wxWidgetsTest\installationResources\plplot-5.9.2\drivers\wxwidgets_app.cpp > > Remember that when I manually added the path I specified for the > wxWidgets_INCLUDE_DIR option after the -I, the build worked fine > through that section. This seems like a bug since it should at least > throw an error rather than setting a blank include path even if I'm > not using the right option. > > I guess that overall I'm not just interested in getting this working > (I'll recompile wxWidgets with your approach to try to make that > happen), but also in getting control over it so that I'm not tied into > storing the files in a particular location or compiling with > particular build options (release, unicode, shared, etc). > > Thanks again for your pointers, > -kyle > > >> be installed. You unzip or install the wxWidgets source code and set the >> WXWIN environment variable to the base path, e.g. c:\wxwidgets-2.8.9 than >> you cd in to build/msw and run the makefile which creates the library in the >> lib/gcc-dll or something similar directory. If you set the WXWIN variable >> correctly, FindwxWidgets.cmake is able to pick up the library information >> even if 2.8.9 is not in FindwxWidgets.cmake (sorry about the wrong email >> before, 2.8.9 is not in FindwxWidgets.cmake, but this is not problem as long >> as you set the WXWIN environment variable). >> >> So please try that, and don't use MSys to compile wxWidgets, stick to the >> Windows CLI and mingw32-make >> >> Regards, >> Werner >> >>> >>> From what I can tell, CMake is not setting the include paths for >>> wxWidgets nor is it doing anything with the wxWidgets_INCLUDE_DIRS >>> variable I tried specifying (based on references in both >>> FindwxWidgets.cmake and UsewxWidgets.cmake). When I look in the >>> build.make file from plplotd.dir the entries for wxWidgets related >>> compilation have a -I option specified (right after $(CXX_FLAGS)) but >>> only has a space for the value. >>> >>> src/CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.obj: >>> src/CMakeFiles/plplotd.dir/flags.make >>> src/CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.obj: >>> ../drivers/wxwidgets_app.cpp >>> $(CMAKE_COMMAND) -E cmake_progress_report >>> >>> D:\Projects\wxWidgetsTest\installationResources\plplot-5.9.2\buildmingw\CMakeFiles >>> $(CMAKE_PROGRESS_38) >>> @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green >>> "Building CXX object >>> src/CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.obj" >>> cd >>> D:\Projects\wxWidgetsTest\installationResources\plplot-5.9.2\buildmingw\src >>> && C:\MinGW\bin\g++.exe $(CXX_DEFINES) $(CXX_FLAGS) -I -o >>> CMakeFiles\plplotd.dir\__\drivers\wxwidgets_app.obj -c >>> >>> D:\Projects\wxWidgetsTest\installationResources\plplot-5.9.2\drivers\wxwidgets_app.cpp >>> >>> If I manually edit the file and put in the required -I<path> options >>> (there are actually two), then that section builds fine and a failure >>> occurs later on. I have not looked into the later failure, but it >>> appears to be something similar. I realize that I may not have the >>> files in their 'normal' locations, but I would expect to have control >>> over the include paths same as I do with the library path via >>> wxWidgets_LIB_DIR. Is there another option I should be using? If so, >>> what is the syntax for multiple paths since two are required? I tried >>> specifying CMAKE_CXX_FLAGS but it leaves the blank -I option in the >>> g++ call which causes g++ to mis-parse the command line and get >>> confused claiming it can't find the wxwidgets_app.obj file. Of course >>> CMAKE_CXX_FLAGS would be less than preferable to use for wxWidgets >>> specific includes anyways since most g++ calls wouldn't need those >>> paths. >>> >>> >>> As for the CMake version, etc. I am using CMake v2.6.2 (cmake >>> --version reports 2.6-patch 2) downloaded from: >>> >>> http://www.cmake.org/files/v2.6/cmake-2.6.2-win32-x86.exe >>> >>> What I was referring to as far as CMake 'missing' wxWidgets-2.8.9 is >>> based on the following excerpt from C:/Program Files/CMake >>> 2.6/share/cmake-2.6/Modules/FindwxWidgets.cmake: >>> >>> PATH_SUFFIXES >>> wxWidgets-2.9.4 >>> wxWidgets-2.9.3 >>> wxWidgets-2.9.2 >>> wxWidgets-2.9.1 >>> wxWidgets-2.9.0 >>> wxWidgets-2.8.8 >>> wxWidgets-2.8.7 >>> wxWidgets-2.8.6 >>> >>> Based on my non-existent knowledge of CMake's inner workings, it seems >>> that if I had C:/wxWidgets-2.8.8 then CMake would find it based on the >>> C:/ entry under PATHS and the wxWidgets-2.8.8 entry under >>> PATH_SUFFIXES. On the other hand, I would think that >>> C:/wxWidgets-2.8.9 would not be found automatically since it seems to >>> be missing from the PATH_SUFFIXES list. >>> >>> Thanks (again), >>> -kyle >>> >>> On Sun, Jan 25, 2009 at 12:58 AM, Werner Smekal <sm...@ia...> >>> wrote: >>>> >>>> Hi Kyle, >>>> >>>> which version of CMake do you use? Because 2.8.9 is definitely included >>>> in >>>> my FindwxWidgets.cmake, CMake Version 2.6.2. Apart from that, to begin >>>> with, >>>> you should follow exactly the instructions I wrote here: >>>> >>>> >>>> http://www.miscdebris.net/plplot_wiki/index.php?title=WxWidgets#Instructions_for_Windows >>>> >>>> If this works, we can try to change things and see where it breaks. The >>>> instructions above use the Windows CLI and not MSys. >>>> >>>> Regards, >>>> Werner >>>> >>>> Kyle Altendorf wrote: >>>>> >>>>> Hi All, >>>>> >>>>> I am compiling PLPlot for use with wxWidgets via C++ on Windows (and >>>>> eventually Linux, etc)... except that CMake doesn't find wxWidgets >>>>> when setting up for PLPlot compilation. I tried to look at the >>>>> FindwxWidgets.cmake file but when I set WXWIN (which seemed >>>>> applicable) in the shell it didn't seem to make a difference. I did >>>>> note though that the file had a large list of wxWidgets versions both >>>>> higher and lower than 2.8.9, but not 2.8.9 itself. It made no >>>>> difference when I added a line for that. I am using: >>>>> >>>>> Windows XP Pro SP3 >>>>> MinGW 5.1.4 ( C:/MinGW ) >>>>> MSYS 1.0.11 ( C:/MSYS, but removed from Path variable when running >>>>> CMake) >>>>> wxWidgets 2.8.9 ( C:/MinGW/wxWidgets-2.8.9, but installed into MinGW >>>>> folders ) >>>>> PLPlot 5.9.2 >>>>> >>>>> If you have any pointers, that'd be greatly appreciated. Maybe where >>>>> CMAKE_LIBRARY_PATH or CMAKE_INCLUDE_PATH should point? >>>>> >>>>> Thanks, >>>>> -kyle >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> This SF.net email is sponsored by: >>>>> SourcForge Community >>>>> SourceForge wants to tell your story. >>>>> http://p.sf.net/sfu/sf-spreadtheword >>>>> _______________________________________________ >>>>> Plplot-general mailing list >>>>> Plp...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/plplot-general >>>>> >>>> >>>> >>>> -- >>>> Dr. Werner Smekal >>>> Institut fuer Allgemeine Physik >>>> Technische Universitaet Wien >>>> Wiedner Hauptstr 8-10 >>>> A-1040 Wien >>>> Austria >>>> DVR-Nr: 0005886 >>>> >>>> email: sm...@ia... >>>> web: http://www.iap.tuwien.ac.at/~smekal >>>> phone: +43-(0)1-58801-13463 (office) >>>> +43-(0)1-58801-13469 (laboratory) >>>> fax: +43-(0)1-58801-13499 >>>> >>>> >> >> -- >> Dr. Werner Smekal >> Institut fuer Allgemeine Physik >> Technische Universitaet Wien >> Wiedner Hauptstr 8-10 >> A-1040 Wien >> Austria >> >> email: sm...@ia... >> web: http://www.iap.tuwien.ac.at/~smekal >> phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) >> fax: +43-(0)1-58801-13499 >> >> > |
From: Werner S. <sm...@ia...> - 2009-02-09 16:10:33
|
Hi Kyle, > I'm starting to feel like a helpless nag... no matter how many > configurations I try for wxWidgets, PLplot or my own application I > can't actually get them all to compile together. Anyways, I think > I've found at least one relevant point that should be recorded in this > thread. > > Previously I had compiled wxWidgets using ./configure within MSYS > according to another guide. This resulted in the libraries being > placed in a different folder structure than when using MinGW directly > via cmd.exe as the PLplot wiki recommends. CMake actually offers two > methods to search for wxWidgets. The variable wxWidgets_FIND_STYLE > can be set as either unix or win32. Though I didn't get the find > working with the unix style, I presume that that is why CMake had > trouble finding my copy of wxWidgets. The Unix style needs the availibility of the command wx-config, which is only available for cygwin and msys (that I'm not sure) but also only within these environments. If you then compile a program on cmd.exe, wx-config won't work anymore (you need then the win32 style for mingw/cmd.exe). > > > Back to following the instructions on the PLplot wiki. I compiled > wxWidgets as release, shared and unicode. Then I moved on to CMake > for PLplot specifying the mswu wxWidgets configuration and the > wxWidgets_LIB_DIR. CMake found wxWidgets but failed to actually build > with the following error: > > [ 60%] Building CXX object bindings/wxwidgets/CMakeFiles/ > plplotwxwidgetsd.dir/wx > PLplotwindow.obj > Linking CXX shared library ..\..\dll\libplplotwxwidgetsd.dll > Creating library file: ..\..\dll\libplplotwxwidgetsd.dll.a > CMakeFiles\plplotwxwidgetsd.dir > \wxPLplotwindow.obj:wxPLplotwindow.cpp:(.text$_ZN > 12wxStringBaseC2EPKc[wxStringBase::wxStringBase(char const*)]+0x27): > undefined r > eference to `_imp___ZN12wxStringBase8InitWithEPKcjj' > collect2: ld returned 1 exit status This is due a bug FindwxWidgets.cmake, either add add_definitions(-D_UNICODE) to CMakeLists.txt in the plplot main file. Or look for wxUNICODE in gcc_dll/mswu/setup.h (or similar) and set it to 1. This flag is always 0 even if you compiled wxWidgets with UNICODE=1, you have to do it on your own, or set the _UNICODE flag on the command line. > > > On a side note, CMake really likes adding a 'd' onto the end of the > LIB_TAG setting. I would think that for a release build this would be > blank? This also puzzled me, but "d" stands for double not for debug. > > > And then? I recompiled wxWidgets (with both monolithic and not) and > PLplot as static, unicode and release. Compilation of both went > flawlessly, but when I compile my project I get: > > g++ -mthreads -DHAVE_W32API_H -D__WXMSW__ -D_UNICODE > -ID:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\lib\gcc_lib\mswu > -ID:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\include > -Wno-ctor-dtor-privacy -pipe -fmessage-length=0 > -ID:\Projects\wxWidgetsTest\Workspace\MinGW > -ID:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install > \include > -O3 -Wall -c -fmessage-length=0 -owxGlade\wxMinimal.o > ..\wxGlade\wxMinimal.cpp > g++ -mthreads -DHAVE_W32API_H -D__WXMSW__ -D_UNICODE > -ID:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\lib\gcc_lib\mswu > -ID:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\include > -Wno-ctor-dtor-privacy -pipe -fmessage-length=0 > -ID:\Projects\wxWidgetsTest\Workspace\MinGW > -ID:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install > \include > -O3 -Wall -c -fmessage-length=0 -osrc\minimal.o ..\src\minimal.cpp > g++ -oMinGW.exe -mthreads > -LD:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install > \lib > -LD:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\lib\gcc_lib > wxGlade\wxMinimal.o src\minimal.o -lwxmsw28u_html -lwxmsw28u_adv > -lwxmsw28u_core -lwxbase28u_xml -lwxbase28u_net -lwxbase28u -lwxtiff > -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32 > -lgdi32 -lcomdlg32 -lwxregexu -lwinspool -lwinmm -lshell32 -lcomctl32 > -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 > -lplplotwxwidgetsd -lplplotd -lplplotcxxd -lcsirocsa > D:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install > \lib/libplplotd.a(wxwidgets.obj):wxwidgets.cpp:(.text+0xd2a): > undefined reference to `wxStringBase::InitWith(char const*, unsigned > int, unsigned int)' > D:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install > \lib/libplplotd.a(wxwidgets.obj):wxwidgets.cpp:(.text+0xd6e): > undefined reference to `wxStringBase::InitWith(char const*, unsigned > int, unsigned int)' > - followed by a bunch more undefined references Also because _UNICODE is not defined. > > > If I remove my one PLplot line ( plsdev("wxWidgets"); // just there to > force PLplot code to be included ) and remove other include etc > references to PLplot the project builds fine with just wxWidgets. > > I know that I need to develop my linker debugging abilities, but in > the mean time, I would obviously still appreciate pointers or > solutions. HTH, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Kyle A. <kyl...@gm...> - 2009-02-10 03:29:01
|
The recommendation of adding the _UNICODE definition to the CMakeLists.txt has yielded some progress onto other errors in my application compilation. Woohoo! :] I'll report back on that after more exploration. Now for a couple quick comments. >> Previously I had compiled wxWidgets using ./configure within MSYS >> according to another guide. This resulted in the libraries being >> placed in a different folder structure than when using MinGW directly >> via cmd.exe as the PLplot wiki recommends. CMake actually offers two >> methods to search for wxWidgets. The variable wxWidgets_FIND_STYLE >> can be set as either unix or win32. Though I didn't get the find >> working with the unix style, I presume that that is why CMake had >> trouble finding my copy of wxWidgets. > > The Unix style needs the availibility of the command wx-config, which is > only available for cygwin and msys (that I'm not sure) but also only within > these environments. If you then compile a program on cmd.exe, wx-config > won't work anymore (you need then the win32 style for mingw/cmd.exe). I was lucky enough to find a win32 port. http://wxconfig.googlepages.com/ It doesn't magically provide you with backtick support, but at least you can copy and paste the compiler and linker options into your IDE for whichever build you happened to do. >> And then? I recompiled wxWidgets (with both monolithic and not) and >> PLplot as static, unicode and release. Compilation of both went >> flawlessly, but when I compile my project I get: >> >> g++ -mthreads -DHAVE_W32API_H -D__WXMSW__ -D_UNICODE >> -ID:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\lib\gcc_lib\mswu >> -ID:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\include >> -Wno-ctor-dtor-privacy -pipe -fmessage-length=0 >> -ID:\Projects\wxWidgetsTest\Workspace\MinGW >> >> -ID:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install\include >> -O3 -Wall -c -fmessage-length=0 -owxGlade\wxMinimal.o >> ..\wxGlade\wxMinimal.cpp >> g++ -mthreads -DHAVE_W32API_H -D__WXMSW__ -D_UNICODE >> -ID:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\lib\gcc_lib\mswu >> -ID:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\include >> -Wno-ctor-dtor-privacy -pipe -fmessage-length=0 >> -ID:\Projects\wxWidgetsTest\Workspace\MinGW >> >> -ID:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install\include >> -O3 -Wall -c -fmessage-length=0 -osrc\minimal.o ..\src\minimal.cpp >> g++ -oMinGW.exe -mthreads >> -LD:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install\lib >> -LD:\Projects\wxWidgetsTest\Libraries\wxWidgets-2.8.9\lib\gcc_lib >> wxGlade\wxMinimal.o src\minimal.o -lwxmsw28u_html -lwxmsw28u_adv >> -lwxmsw28u_core -lwxbase28u_xml -lwxbase28u_net -lwxbase28u -lwxtiff >> -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32 >> -lgdi32 -lcomdlg32 -lwxregexu -lwinspool -lwinmm -lshell32 -lcomctl32 >> -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 >> -lplplotwxwidgetsd -lplplotd -lplplotcxxd -lcsirocsa >> >> D:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install\lib/libplplotd.a(wxwidgets.obj):wxwidgets.cpp:(.text+0xd2a): >> undefined reference to `wxStringBase::InitWith(char const*, unsigned >> int, unsigned int)' >> >> D:\Projects\wxWidgetsTest\Libraries\plplot-5.9.2\buildmingw\install\lib/libplplotd.a(wxwidgets.obj):wxwidgets.cpp:(.text+0xd6e): >> undefined reference to `wxStringBase::InitWith(char const*, unsigned >> int, unsigned int)' >> - followed by a bunch more undefined references > > Also because _UNICODE is not defined. Doesn't the -D_UNICODE option (specified by wx-config) define it? It is present in both compiler calls and I didn't think it would be applicable to the linker call (especially since wx-config didn't list it). Or, are you referring to defining _UNICODE back in the initial PLplot compilation? > HTH, > Werner Thanks for the continued help, -kyle |
From: Werner S. <sm...@ia...> - 2009-02-10 06:56:06
|
Hi Kyle, > > I was lucky enough to find a win32 port. > > http://wxconfig.googlepages.com/ > > It doesn't magically provide you with backtick support, but at least > you can copy and paste the compiler and linker options into your IDE > for whichever build you happened to do. Yes, this helps to find the options for your own compilation. I normally compile the minimal sample of wxwidgets (you need to supply the same options as used for the wxWidgets compilations, e.g. mingw32- make -g makefile.gcc UNICODE=1 MONOLITHIC=1 SHARED=1) and look what the command line options are. but the wxconfig above is of no use for cmake. > > >>> > Doesn't the -D_UNICODE option (specified by wx-config) define it? It > is present in both compiler calls and I didn't think it would be > applicable to the linker call (especially since wx-config didn't list > it). Or, are you referring to defining _UNICODE back in the initial > PLplot compilation? Yes, the latter one. Since PLplot wasn't compiled with the _UNICODE flag (but wxWidgets is unicode) troubles occur somewhere later (or earlier). Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Kyle A. <kyl...@gm...> - 2009-02-10 06:25:47
|
>> Back to following the instructions on the PLplot wiki. I compiled >> wxWidgets as release, shared and unicode. Then I moved on to CMake >> for PLplot specifying the mswu wxWidgets configuration and the >> wxWidgets_LIB_DIR. CMake found wxWidgets but failed to actually build >> with the following error: >> >> [ 60%] Building CXX object >> bindings/wxwidgets/CMakeFiles/plplotwxwidgetsd.dir/wx >> PLplotwindow.obj >> Linking CXX shared library ..\..\dll\libplplotwxwidgetsd.dll >> Creating library file: ..\..\dll\libplplotwxwidgetsd.dll.a >> >> CMakeFiles\plplotwxwidgetsd.dir\wxPLplotwindow.obj:wxPLplotwindow.cpp:(.text$_ZN >> 12wxStringBaseC2EPKc[wxStringBase::wxStringBase(char const*)]+0x27): >> undefined r >> eference to `_imp___ZN12wxStringBase8InitWithEPKcjj' >> collect2: ld returned 1 exit status > > This is due a bug FindwxWidgets.cmake, either add > > add_definitions(-D_UNICODE) > > to CMakeLists.txt in the plplot main file. Or look for wxUNICODE in > gcc_dll/mswu/setup.h (or similar) and set it to 1. This flag is always 0 > even if you compiled wxWidgets with UNICODE=1, you have to do it on your > own, or set the _UNICODE flag on the command line. > This worked for this stage and eventually I got my application to compile with PLplot. Hip-hip.. hoorah! Another piece of the puzzle was finding and using pkg-config for win32 to provide an appropriate set of linker flags. I didn't find this right off the bat, so here's a link for anyone else who ends up perusing this thread for help: http://www.gtk.org/download-windows.html Just remember to set the PKG_CONFIG_PATH variable to the <install>\lib\pkgconfig directory so it can find the PLplot files. Now on to actual programming and figuring out how to use this. Oh, and repeating this process from scratch so I can document it well on the wiki. > HTH, > Werner Yes, it finally did the trick. Thanks again for sticking it out and getting me to the bottom of this. -kyle |
From: Werner S. <sm...@ia...> - 2009-02-10 06:58:57
|
Hi Kyle, > > This worked for this stage and eventually I got my application to > compile with PLplot. Hip-hip.. hoorah! Another piece of the puzzle > was finding and using pkg-config for win32 to provide an appropriate > set of linker flags. I didn't find this right off the bat, so here's > a link for anyone else who ends up perusing this thread for help: > > http://www.gtk.org/download-windows.html > > Just remember to set the PKG_CONFIG_PATH variable to the > <install>\lib\pkgconfig directory so it can find the PLplot files. > Now on to actual programming and figuring out how to use this. Oh, > and repeating this process from scratch so I can document it well on > the wiki. Yes, this pkg-config you found can be used (must be used for cairo devices), but not needed. Usually to find out what parameters I need to compile my own programs I configure PLplot with the -DBUILD_TEST=ON option and then compile PLplot with make VERBOSE=1 Later on all the examples will be built and the VERBOSE flag tells make to print out actual compiler and linker calls. This helps to get your own programs running. > > Yes, it finally did the trick. Thanks again for sticking it out and > getting me to the bottom of this. > > -kyle Great! Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Kyle A. <kyl...@gm...> - 2009-02-16 21:20:40
|
I have added and updated a few sections on the wiki to include the major points from this thread. Hopefully they'll actually help someone out. Thanks for all your time Werner. -kyle On Mon, Feb 9, 2009 at 10:58 PM, Werner Smekal <sm...@ia...> wrote: > Hi Kyle, >> >> This worked for this stage and eventually I got my application to >> compile with PLplot. Hip-hip.. hoorah! Another piece of the puzzle >> was finding and using pkg-config for win32 to provide an appropriate >> set of linker flags. I didn't find this right off the bat, so here's >> a link for anyone else who ends up perusing this thread for help: >> >> http://www.gtk.org/download-windows.html >> >> Just remember to set the PKG_CONFIG_PATH variable to the >> <install>\lib\pkgconfig directory so it can find the PLplot files. >> Now on to actual programming and figuring out how to use this. Oh, >> and repeating this process from scratch so I can document it well on >> the wiki. > > Yes, this pkg-config you found can be used (must be used for cairo devices), > but not needed. Usually to find out what parameters I need to compile my own > programs I configure PLplot with the -DBUILD_TEST=ON option and then compile > PLplot with > > make VERBOSE=1 > > Later on all the examples will be built and the VERBOSE flag tells make to > print out actual compiler and linker calls. This helps to get your own > programs running. > >> >> Yes, it finally did the trick. Thanks again for sticking it out and >> getting me to the bottom of this. >> >> -kyle > > Great! > > Werner > > -- > Dr. Werner Smekal > Institut fuer Allgemeine Physik > Technische Universitaet Wien > Wiedner Hauptstr 8-10 > A-1040 Wien > Austria > > email: sm...@ia... > web: http://www.iap.tuwien.ac.at/~smekal > phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) > fax: +43-(0)1-58801-13499 > > |
From: Werner S. <sm...@ia...> - 2009-02-17 10:20:25
|
Hi Kyle, > > I have added and updated a few sections on the wiki to include the > major points from this thread. Hopefully they'll actually help > someone out. Thanks for all your time Werner. Thanks for the additional information on the wiki. Thanks, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |