From: D M G. <dm...@uv...> - 2009-09-18 20:23:10
|
I have a problem with the cmake configuration for libpano. ---------------------------------------------------------------------- dmg@phosphorus:~/hacking/libpano$ cmake CMakeLists.txt CMake Error at CMakeLists.txt:38 (include): include could not find load file: HuginMacros CMake Error at /usr/share/cmake-2.6/Modules/FindPackageHandleStandardArgs.cmake:57 (MESSAGE): Could NOT find wxWidgets (missing: wxWidgets_FOUND) Call Stack (most recent call first): /usr/share/cmake-2.6/Modules/FindwxWidgets.cmake:765 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:54 (FIND_PACKAGE) -- Configuring incomplete, errors occurred! dmg@phosphorus:~/hacking/libpano$ ---------------------------------------------------------------------- Libpano is defined as dependent of hugin and wxWidgets. In my laptop I don't have neither one, so it fails. Libpano should not depend on hugin and wxwidgets. As far as I know, there is nothing on libpano that depends on hugin. Is this really necessary? libpano should depend only on zlib, java, libpng, libjpg, and libtiff. --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Bruno P. <br...@po...> - 2009-09-18 20:34:20
|
On Fri 18-Sep-2009 at 13:22 -0700, Daniel M. German wrote: > >Libpano is defined as dependent of hugin and wxWidgets. In my laptop I >don't have neither one, so it fails. > >Libpano should not depend on hugin and wxwidgets. As far as I know, >there is nothing on libpano that depends on hugin. The cmake build system in libpano13 is primarily to make things easier for building on Windows - wxwidgets contains local copies of libtiff, libpng and libjpeg so these are used in the Windows build. -- Bruno |
From: D M G. <dm...@uv...> - 2009-09-18 20:44:07
|
Bruno Postle twisted the bytes to say: Bruno> On Fri 18-Sep-2009 at 13:22 -0700, Daniel M. German wrote: >> >> Libpano is defined as dependent of hugin and wxWidgets. In my laptop I >> don't have neither one, so it fails. >> >> Libpano should not depend on hugin and wxwidgets. As far as I know, >> there is nothing on libpano that depends on hugin. Bruno> The cmake build system in libpano13 is primarily to make things Bruno> easier for building on Windows - wxwidgets contains local copies of Bruno> libtiff, libpng and libjpeg so these are used in the Windows build. thanks Bruno, Would it be easy to add a test for Windows, and only have these rules used in windows? --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: dmg <dm...@uv...> - 2009-09-18 21:07:17
|
Hi Kornel, Why don't you commit the changes, to test your svn write access? --dmg On Fri, Sep 18, 2009 at 1:53 PM, Kornel Benko <Kor...@be...> wrote: > Am Freitag 18 September 2009 schrieb D M German: >> I have a problem with the cmake configuration for libpano. >> >> ---------------------------------------------------------------------- >> dmg@phosphorus:~/hacking/libpano$ cmake CMakeLists.txt >> CMake Error at CMakeLists.txt:38 (include): >> include could not find load file: >> >> HuginMacros >> >> >> CMake Error at >> /usr/share/cmake-2.6/Modules/FindPackageHandleStandardArgs.cmake:57 >> (MESSAGE): Could NOT find wxWidgets (missing: wxWidgets_FOUND) >> Call Stack (most recent call first): >> /usr/share/cmake-2.6/Modules/FindwxWidgets.cmake:765 >> (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:54 (FIND_PACKAGE) >> >> >> -- Configuring incomplete, errors occurred! >> dmg@phosphorus:~/hacking/libpano$ >> ---------------------------------------------------------------------- >> >> >> Libpano is defined as dependent of hugin and wxWidgets. In my laptop I >> don't have neither one, so it fails. >> >> Libpano should not depend on hugin and wxwidgets. As far as I know, >> there is nothing on libpano that depends on hugin. >> >> Is this really necessary? >> >> libpano should depend only on zlib, java, libpng, libjpg, and libtiff. >> >> --dmg > > We could make it dependent on WIN32. > In fact, here it compiles. > =================================================================== > --- CMakeLists.txt (revision 1057) > +++ CMakeLists.txt (working copy) > @@ -34,8 +34,10 @@ > set(CMAKE_MODULE_PATH ${SOURCE_BASE_DIR}/hugin/CMakeModules ) > ENDIF ( HUGIN_BASE_DIR ) > > -## load the Hugin cmake modules > -include(HuginMacros) > +if(WIN32) > + ## load the Hugin cmake modules > + include(HuginMacros) > +endif() > include(CheckIncludeFiles) > > ## global setup > > Kornel > -- > Kornel Benko > Kor...@be... -- --dmg --- Daniel M. German http://turingmachine.org |
From: Thomas S. <tks...@gm...> - 2009-09-18 21:21:53
|
Hi All I did write the CMake script for libpano mainly as a convenience for building on Windows with the Hugin SDK. However I hoped it would work on Linux with the dependencies in the "standard places", without looking for WxWidgets. If I understand correctly that Kornel's patch achieves that, then it should definitely be committed. Regards, Tom On Fri, Sep 18, 2009 at 5:06 PM, dmg <dm...@uv...> wrote: > Hi Kornel, > > Why don't you commit the changes, to test your svn write access? > > --dmg > > On Fri, Sep 18, 2009 at 1:53 PM, Kornel Benko <Kor...@be...> > wrote: > > Am Freitag 18 September 2009 schrieb D M German: > >> I have a problem with the cmake configuration for libpano. > >> > >> ---------------------------------------------------------------------- > >> dmg@phosphorus:~/hacking/libpano$ cmake CMakeLists.txt > >> CMake Error at CMakeLists.txt:38 (include): > >> include could not find load file: > >> > >> HuginMacros > >> > >> > >> CMake Error at > >> /usr/share/cmake-2.6/Modules/FindPackageHandleStandardArgs.cmake:57 > >> (MESSAGE): Could NOT find wxWidgets (missing: wxWidgets_FOUND) > >> Call Stack (most recent call first): > >> /usr/share/cmake-2.6/Modules/FindwxWidgets.cmake:765 > >> (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:54 (FIND_PACKAGE) > >> > >> > >> -- Configuring incomplete, errors occurred! > >> dmg@phosphorus:~/hacking/libpano$ > >> ---------------------------------------------------------------------- > >> > >> > >> Libpano is defined as dependent of hugin and wxWidgets. In my laptop I > >> don't have neither one, so it fails. > >> > >> Libpano should not depend on hugin and wxwidgets. As far as I know, > >> there is nothing on libpano that depends on hugin. > >> > >> Is this really necessary? > >> > >> libpano should depend only on zlib, java, libpng, libjpg, and libtiff. > >> > >> --dmg > > > > We could make it dependent on WIN32. > > In fact, here it compiles. > > =================================================================== > > --- CMakeLists.txt (revision 1057) > > +++ CMakeLists.txt (working copy) > > @@ -34,8 +34,10 @@ > > set(CMAKE_MODULE_PATH ${SOURCE_BASE_DIR}/hugin/CMakeModules ) > > ENDIF ( HUGIN_BASE_DIR ) > > > > -## load the Hugin cmake modules > > -include(HuginMacros) > > +if(WIN32) > > + ## load the Hugin cmake modules > > + include(HuginMacros) > > +endif() > > include(CheckIncludeFiles) > > > > ## global setup > > > > Kornel > > -- > > Kornel Benko > > Kor...@be... > > > > -- > --dmg > > --- > Daniel M. German > http://turingmachine.org > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > |
From: Kornel B. <Kor...@be...> - 2009-09-18 21:37:46
|
Am Freitag 18 September 2009 schrieb dmg: > Hi Kornel, > > Why don't you commit the changes, to test your svn write access? > > --dmg Because I am used to discuss patches before commiting. But OK, I have a patch, which is not breaking anything. It additionally handles the manual installation. Will try, but let me check first. Kornel -- Kornel Benko Kor...@be... |
From: Thomas S. <tks...@gm...> - 2009-09-19 02:01:13
|
Hey Kornel The latest line you added to CMakelists.txt, "install(TARGETS pano13 LIBRARY DESTINATION lib)" breaks my Windows build, as the name "lib" is not resolved. It would probably be best to make these install instructions conditional on Linux. On Windows there is no good way to install from a makefile; however it would be nice to put a simulated "install" directory tree inside the build tree created by CMake, as the Hugin scripts do. Regards, Tom 2009/9/18 Kornel Benko <Kor...@be...> > Am Freitag 18 September 2009 schrieb dmg: > > Hi Kornel, > > > > Why don't you commit the changes, to test your svn write access? > > > > --dmg > Because I am used to discuss patches before commiting. > But OK, I have a patch, which is not breaking anything. It additionally > handles the manual > installation. > Will try, but let me check first. > > > Kornel > -- > Kornel Benko > Kor...@be... > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > |
From: Thomas S. <tks...@gm...> - 2009-09-19 02:22:36
|
The current CMakelists.txt also fails on my Ubuntu Linux system because I have a version 2.4.7 of CMake, which requires that "if(some expression)" be closed with "endif(some expression)", and you have used "endif()" in numerous places. I suppose recent CMake versions allow that. My solution will be to insert the required expressions and commit, unless you feel that a more recent CMake version is really required to get the build to work -- in which case you should change line 26, "cmake_minimum_required(VERSION 2.4)". Cheers, Tom On Fri, Sep 18, 2009 at 10:01 PM, Thomas Sharpless <tks...@gm...>wrote: > Hey Kornel > > The latest line you added to CMakelists.txt, > "install(TARGETS pano13 LIBRARY DESTINATION lib)" > breaks my Windows build, as the name "lib" is not resolved. > > It would probably be best to make these install instructions conditional on > Linux. On Windows there is no good way to install from a makefile; however > it would be nice to put a simulated "install" directory tree inside the > build tree created by CMake, as the Hugin scripts do. > > Regards, Tom > > > > 2009/9/18 Kornel Benko <Kor...@be...> > >> Am Freitag 18 September 2009 schrieb dmg: >> > Hi Kornel, >> > >> > Why don't you commit the changes, to test your svn write access? >> > >> > --dmg >> Because I am used to discuss patches before commiting. >> But OK, I have a patch, which is not breaking anything. It additionally >> handles the manual >> installation. >> Will try, but let me check first. >> >> >> Kornel >> -- >> Kornel Benko >> Kor...@be... >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register >> now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> PanoTools-devel mailing list >> Pan...@li... >> https://lists.sourceforge.net/lists/listinfo/panotools-devel >> >> > |
From: Thomas S. <tks...@gm...> - 2009-09-19 02:36:36
|
Well I guess your script really does require a newer CMake, now I get... > tommy@HPubu:~/hugin-et-al/libpano13$ cmake . > -- Found TIFF: /usr/include > -- Found JPEG: /usr/include > -- Found PNG: /usr/include > CMake Error: Error in cmake code at > /home/tommy/hugin-et-al/libpano13/CMakeLists.txt:221: > FILE does not recognize sub-command STRINGS > Current CMake stack: > [1] /home/tommy/hugin-et-al/libpano13/CMakeLists.txt > -- svnversion = /usr/bin/svnversion > -- Configuring done > tommy@HPubu:~/hugin-et-al/libpano13$ > But after installing CMake 2.6 all builds OK. Apparently without any reference to WxWidgets, though that is installed here. So I am going to change that line 26 to require CMake 2.6... Regards, Tom On Fri, Sep 18, 2009 at 10:22 PM, Thomas Sharpless <tks...@gm...>wrote: > The current CMakelists.txt also fails on my Ubuntu Linux system because I > have a version 2.4.7 of CMake, which requires that "if(some expression)" be > closed with "endif(some expression)", and you have used "endif()" in > numerous places. I suppose recent CMake versions allow that. > > My solution will be to insert the required expressions and commit, unless > you feel that a more recent CMake version is really required to get the > build to work -- in which case you should change line 26, > "cmake_minimum_required(VERSION 2.4)". > > Cheers, Tom > > > > On Fri, Sep 18, 2009 at 10:01 PM, Thomas Sharpless <tks...@gm...>wrote: > >> Hey Kornel >> >> The latest line you added to CMakelists.txt, >> "install(TARGETS pano13 LIBRARY DESTINATION lib)" >> breaks my Windows build, as the name "lib" is not resolved. >> >> It would probably be best to make these install instructions conditional >> on Linux. On Windows there is no good way to install from a makefile; >> however it would be nice to put a simulated "install" directory tree inside >> the build tree created by CMake, as the Hugin scripts do. >> >> Regards, Tom >> >> >> >> 2009/9/18 Kornel Benko <Kor...@be...> >> >>> Am Freitag 18 September 2009 schrieb dmg: >>> > Hi Kornel, >>> > >>> > Why don't you commit the changes, to test your svn write access? >>> > >>> > --dmg >>> Because I am used to discuss patches before commiting. >>> But OK, I have a patch, which is not breaking anything. It additionally >>> handles the manual >>> installation. >>> Will try, but let me check first. >>> >>> >>> Kornel >>> -- >>> Kornel Benko >>> Kor...@be... >>> >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry® Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9-12, 2009. Register >>> now! >>> http://p.sf.net/sfu/devconf >>> _______________________________________________ >>> PanoTools-devel mailing list >>> Pan...@li... >>> https://lists.sourceforge.net/lists/listinfo/panotools-devel >>> >>> >> > |
From: Thomas S. <tks...@gm...> - 2009-09-19 04:00:25
|
I have found the explanation for the error about "install(TARGETS pano13 LIBRARY DESTINATION lib)" . Apparently for Windows you have to either specify destinations for all of LIBRARY, ARCHIVE, and RUNTIME (the preferred way) or for none of them (which works but doesn't put dlls with the executables). With that change, CMake configures successfully and creates working MSVC projects. BUT there is still a problem for me: > set( pano13_res > pano13.rc > pano13vc.def > ) > > which leads to: > 1>Linking... > 1>pano13vc.def : error LNK2001: unresolved external symbol DLLInit > 1>pano13vc.def : error LNK2001: unresolved external symbol DispPrg > 1>pano13vc.def : error LNK2001: unresolved external symbol InfoPrg > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_pteditor_CExtract > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_pteditor_CGetImageHeight > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_pteditor_CGetImageRow > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_pteditor_CGetImageWidth > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_pteditor_CInsert > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_pteditor_CLoadImage > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_pteditor_CSaveImage > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_pteditor_CSetImageHeight > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_pteditor_CSetImageRow > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_pteditor_CSetImageWidth > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CAlignPoint > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CCallOptimizer > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CCreateProject > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetCP_1n > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetCP_1t > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetCP_1x > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetCP_1y > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetControlPointCount > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetHfov > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetImageCount > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetImageFormat > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetImageHeight > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetImageName > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetImageRow > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetImageWidth > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetIndex > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetPitch > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetRoll > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetTR_1i > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetTR_1v > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetTriangleCount > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CGetYaw > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CLaunchAndSendScript > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CLoadImage > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CLoadProject > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CReduce > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CSaveProject > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CSetCP > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CSetControlPointCount > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CSetImageName > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CSetTR > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CSetTriangleCount > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CShowScript > 1>pano13vc.def : error LNK2001: unresolved external symbol > Java_ptutils_CTriangulate > 1>pano13vc.def : error LNK2001: unresolved external symbol SetWindowOwner > 1>pano13vc.def : error LNK2001: unresolved external symbol TIFFClose > 1>pano13vc.def : error LNK2001: unresolved external symbol TIFFGetField > 1>pano13vc.def : error LNK2001: unresolved external symbol TIFFOpen > 1>pano13vc.def : error LNK2001: unresolved external symbol > TIFFReadDirectory > 1>pano13vc.def : error LNK2001: unresolved external symbol TIFFReadScanline > 1>pano13vc.def : error LNK2001: unresolved external symbol TIFFScanlineSize > 1>pano13vc.def : error LNK2001: unresolved external symbol TIFFSetDirectory > 1>pano13vc.def : error LNK2001: unresolved external symbol TIFFSetField > 1>pano13vc.def : error LNK2001: unresolved external symbol > TIFFWriteDirectory > 1>pano13vc.def : error LNK2001: unresolved external symbol > TIFFWriteScanline > 1>C:\Users\Public\HuginSDK\libpano13-build\Debug\pano13.lib : fatal error > LNK1120: 58 unresolved externals > I don't have a working Java SDK, and don't include the Java headers while compiling -- that seems OK . But this .res file is assuming I do. I don't know if the TIFFxxxx symbols really represent real errors either. However just omitting the .res file leads to a bunch of different link errors, which do include those tifflib symbols. So in short I am still not able to build the full dll form of libpano13 on Windows using MSVC. Any suggestions? Regards, Tom On Fri, Sep 18, 2009 at 10:36 PM, Thomas Sharpless <tks...@gm...>wrote: > Well I guess your script really does require a newer CMake, now I get... > >> tommy@HPubu:~/hugin-et-al/libpano13$ cmake . >> -- Found TIFF: /usr/include >> -- Found JPEG: /usr/include >> -- Found PNG: /usr/include >> CMake Error: Error in cmake code at >> /home/tommy/hugin-et-al/libpano13/CMakeLists.txt:221: >> FILE does not recognize sub-command STRINGS >> Current CMake stack: >> [1] /home/tommy/hugin-et-al/libpano13/CMakeLists.txt >> -- svnversion = /usr/bin/svnversion >> -- Configuring done >> tommy@HPubu:~/hugin-et-al/libpano13$ >> > > But after installing CMake 2.6 all builds OK. Apparently without any > reference to WxWidgets, though that is installed here. > > So I am going to change that line 26 to require CMake 2.6... > > Regards, Tom > > > On Fri, Sep 18, 2009 at 10:22 PM, Thomas Sharpless <tks...@gm...>wrote: > >> The current CMakelists.txt also fails on my Ubuntu Linux system because I >> have a version 2.4.7 of CMake, which requires that "if(some expression)" be >> closed with "endif(some expression)", and you have used "endif()" in >> numerous places. I suppose recent CMake versions allow that. >> >> My solution will be to insert the required expressions and commit, unless >> you feel that a more recent CMake version is really required to get the >> build to work -- in which case you should change line 26, >> "cmake_minimum_required(VERSION 2.4)". >> >> Cheers, Tom >> >> >> >> On Fri, Sep 18, 2009 at 10:01 PM, Thomas Sharpless <tks...@gm... >> > wrote: >> >>> Hey Kornel >>> >>> The latest line you added to CMakelists.txt, >>> "install(TARGETS pano13 LIBRARY DESTINATION lib)" >>> breaks my Windows build, as the name "lib" is not resolved. >>> >>> It would probably be best to make these install instructions conditional >>> on Linux. On Windows there is no good way to install from a makefile; >>> however it would be nice to put a simulated "install" directory tree inside >>> the build tree created by CMake, as the Hugin scripts do. >>> >>> Regards, Tom >>> >>> >>> >>> 2009/9/18 Kornel Benko <Kor...@be...> >>> >>>> Am Freitag 18 September 2009 schrieb dmg: >>>> > Hi Kornel, >>>> > >>>> > Why don't you commit the changes, to test your svn write access? >>>> > >>>> > --dmg >>>> Because I am used to discuss patches before commiting. >>>> But OK, I have a patch, which is not breaking anything. It additionally >>>> handles the manual >>>> installation. >>>> Will try, but let me check first. >>>> >>>> >>>> Kornel >>>> -- >>>> Kornel Benko >>>> Kor...@be... >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Come build with us! The BlackBerry® Developer Conference in SF, CA >>>> is the only developer event you need to attend this year. Jumpstart your >>>> developing skills, take BlackBerry mobile applications to market and >>>> stay >>>> ahead of the curve. Join us from November 9-12, 2009. Register >>>> now! >>>> http://p.sf.net/sfu/devconf >>>> _______________________________________________ >>>> PanoTools-devel mailing list >>>> Pan...@li... >>>> https://lists.sourceforge.net/lists/listinfo/panotools-devel >>>> >>>> >>> >> > |
From: Kornel B. <Kor...@be...> - 2009-09-19 06:53:01
|
Am Samstag 19 September 2009 schrieb Thomas Sharpless: > I have found the explanation for the error about "install(TARGETS pano13 > LIBRARY DESTINATION lib)" . > Apparently for Windows you have to either specify destinations for all of > LIBRARY, ARCHIVE, and RUNTIME (the preferred way) or for none of them > (which works but doesn't put dlls with the executables). With that change, > CMake configures successfully and creates working MSVC projects. You mean with the line "install(TARGETS pano13 LIBRARY DESTINATION lib)" is now working for windows too? > BUT there is still a problem for me: > > set( pano13_res > > pano13.rc > > pano13vc.def > > ) > > > > which leads to: > > > > 1>Linking... > > 1>pano13vc.def : error LNK2001: unresolved external symbol DLLInit > > 1>pano13vc.def : error LNK2001: unresolved external symbol DispPrg > > 1>pano13vc.def : error LNK2001: unresolved external symbol InfoPrg > > 1>pano13vc.def : error LNK2001: unresolved external symbol > > Java_pteditor_CExtract ... Sorry for this. Don't know, how to omit, without looking into the sources. That is definitelly not my doing. I get this Java-errors too, when not setting HAVE_JAVA, so it is not windows specific. > I don't have a working Java SDK, and don't include the Java headers while > compiling -- that seems OK . But this .res file is assuming I do. > I don't know if the TIFFxxxx symbols really represent real errors either. > However just omitting the .res file leads to a bunch of different link > errors, which do include those tifflib symbols. > > So in short I am still not able to build the full dll form of libpano13 on > Windows using MSVC. Any suggestions? Only to look into sources. The cmake-files look correct, at first glance. > Regards, Tom > Kornel -- Kornel Benko Kor...@be... |
From: Thomas S. <tks...@gm...> - 2009-09-19 16:24:42
|
Hi Kornel The new install command that works on windows is > install(TARGETS pano13 LIBRARY DESTINATION lib${LIB_SUFFIX} > ARCHIVE DESTINATION lib${LIB_SUFFIX} > RUNTIME DESTINATION bin ) > I copied this from a discussion on the web. I guess the RUNTIME DESTINATION is where a dll will go. I have tried this version on Ubuntu and no problem, so will commit. But first I shall update as it seems there is a lot of activity on this file now. I have also inserted a Windows-only line that sets the install prefix to "${CMAKE_CURRENT_BINARY_DIR}/INSTALL/FILES" which is what the Hugin script does. With this you can make a mock installation for testing. But I have not tested that yet as I can't build on Windows yet. As for the other problems: Making Java optional is possible, my original CMake script in fact worked without it. But it could only build libpano13 that way, of course you need Java to build the PanoTools. And it only built the static library, as required by Hugin. I don't know if that is still feasible with the current script, but will try when I get back to Windows Making a Windows DLL is probably also feasible, but needs some work on the .def file and an alternate .def for the Java-free option. Not a top priority for me. Regards, Tom 2009/9/19 Kornel Benko <Kor...@be...> > Am Samstag 19 September 2009 schrieb Thomas Sharpless: > > I have found the explanation for the error about "install(TARGETS pano13 > > LIBRARY DESTINATION lib)" . > > Apparently for Windows you have to either specify destinations for all of > > LIBRARY, ARCHIVE, and RUNTIME (the preferred way) or for none of them > > (which works but doesn't put dlls with the executables). With that > change, > > CMake configures successfully and creates working MSVC projects. > > > You mean with the line > "install(TARGETS pano13 LIBRARY DESTINATION lib)" > is now working for windows too? > > > > BUT there is still a problem for me: > > > set( pano13_res > > > pano13.rc > > > pano13vc.def > > > ) > > > > > > which leads to: > > > > > > 1>Linking... > > > 1>pano13vc.def : error LNK2001: unresolved external symbol DLLInit > > > 1>pano13vc.def : error LNK2001: unresolved external symbol DispPrg > > > 1>pano13vc.def : error LNK2001: unresolved external symbol InfoPrg > > > 1>pano13vc.def : error LNK2001: unresolved external symbol > > > Java_pteditor_CExtract > ... > Sorry for this. Don't know, how to omit, without looking into the sources. > That is definitelly not my doing. > I get this Java-errors too, when not setting HAVE_JAVA, so it is not > windows specific. > > > > I don't have a working Java SDK, and don't include the Java headers while > > compiling -- that seems OK . But this .res file is assuming I do. > > I don't know if the TIFFxxxx symbols really represent real errors either. > > However just omitting the .res file leads to a bunch of different link > > errors, which do include those tifflib symbols. > > > > So in short I am still not able to build the full dll form of libpano13 > on > > Windows using MSVC. Any suggestions? > > > Only to look into sources. The cmake-files look correct, at first glance. > > > > Regards, Tom > > > Kornel > -- > Kornel Benko > Kor...@be... > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > |
From: Kornel B. <Kor...@be...> - 2009-09-19 16:54:56
|
Am Samstag 19 September 2009 schrieb Thomas Sharpless: > Hi Kornel > > The new install command that works on windows is > > > install(TARGETS pano13 LIBRARY DESTINATION lib${LIB_SUFFIX} > > ARCHIVE DESTINATION lib${LIB_SUFFIX} > > RUNTIME DESTINATION bin ) > > I copied this from a discussion on the web. I guess the RUNTIME > DESTINATION is where a dll will go. > I have tried this version on Ubuntu and no problem, so will commit. But > first I shall update as it seems there is a lot of activity on this file > now. OK, I wait for your commit, then will try with ubuntu. > I have also inserted a Windows-only line that sets the install prefix to > "${CMAKE_CURRENT_BINARY_DIR}/INSTALL/FILES" which is what the Hugin script > does. With this you can make a mock installation for testing. But I have > not tested that yet as I can't build on Windows yet. > > As for the other problems: > > Making Java optional is possible, my original CMake script in fact worked > without it. But it could only build libpano13 that way, of course you need > Java to build the PanoTools. And it only built the static library, as > required by Hugin. I don't know if that is still feasible with the current > script, but will try when I get back to Windows Yes, worked, but there must have been something latelly. Because, before I started to change things, I got this unsatisfied externals. (The only change I had at that time was STATIC -> SHARED) I got errors at link stage, not at creation of the library. > Making a Windows DLL is probably also feasible, but needs some work on the > .def file and an alternate .def for the Java-free option. Not a top > priority for me. > > Regards, Tom > OK. Kornel -- Kornel Benko Kor...@be... |
From: Thomas S. <tks...@gm...> - 2009-09-20 01:21:25
|
One more thing. How does one build a static library with the present CMake script? We need one for Hugin, and on Windows the DLL is not yet even buildable. -- Tom On Sat, Sep 19, 2009 at 12:54 PM, Kornel Benko <Kor...@be...>wrote: > Am Samstag 19 September 2009 schrieb Thomas Sharpless: > > Hi Kornel > > > > The new install command that works on windows is > > > > > install(TARGETS pano13 LIBRARY DESTINATION lib${LIB_SUFFIX} > > > ARCHIVE DESTINATION lib${LIB_SUFFIX} > > > RUNTIME DESTINATION bin ) > > > > I copied this from a discussion on the web. I guess the RUNTIME > > DESTINATION is where a dll will go. > > I have tried this version on Ubuntu and no problem, so will commit. But > > first I shall update as it seems there is a lot of activity on this file > > now. > > OK, I wait for your commit, then will try with ubuntu. > > > I have also inserted a Windows-only line that sets the install prefix to > > "${CMAKE_CURRENT_BINARY_DIR}/INSTALL/FILES" which is what the Hugin > script > > does. With this you can make a mock installation for testing. But I > have > > not tested that yet as I can't build on Windows yet. > > > > As for the other problems: > > > > Making Java optional is possible, my original CMake script in fact worked > > without it. But it could only build libpano13 that way, of course you > need > > Java to build the PanoTools. And it only built the static library, as > > required by Hugin. I don't know if that is still feasible with the > current > > script, but will try when I get back to Windows > > Yes, worked, but there must have been something latelly. Because, before I > started to change > things, I got this unsatisfied externals. > (The only change I had at that time was STATIC -> SHARED) > I got errors at link stage, not at creation of the library. > > > Making a Windows DLL is probably also feasible, but needs some work on > the > > .def file and an alternate .def for the Java-free option. Not a top > > priority for me. > > > > Regards, Tom > > > > OK. > > Kornel > > -- > Kornel Benko > Kor...@be... > |
From: Kornel B. <Kor...@be...> - 2009-09-20 06:16:59
|
Am Sonntag 20 September 2009 schrieb Thomas Sharpless: > One more thing. How does one build a static library with the present CMake > script? We need one for Hugin, and on Windows the DLL is not yet even > buildable. I compile on ubuntu, and don't need static library. But I could try to create this one too. > -- Tom Kornel -- Kornel Benko Kor...@be... |
From: Kornel B. <Kor...@be...> - 2009-09-20 06:55:03
Attachments:
CMakeLists.txt.diff
|
Am Sonntag 20 September 2009 schrieb Kornel Benko: > Am Sonntag 20 September 2009 schrieb Thomas Sharpless: > > One more thing. How does one build a static library with the present > > CMake script? We need one for Hugin, and on Windows the DLL is not yet > > even buildable. > > I compile on ubuntu, and don't need static library. But I could try to > create this one too. > > > -- Tom > > Kornel Ok, here I am creating now both types. Requires cmake >= 2.2, which we use. I don't see any drawbacks. If no one screams, I will commit. Kornel -- Kornel Benko Kor...@be... |
From: Thomas S. <tks...@gm...> - 2009-09-20 12:35:56
|
Hi Kornel Please do commit the change to allow building static libpano; I will try it on Windows. Regards, Tom On Sun, Sep 20, 2009 at 2:16 AM, Kornel Benko <Kor...@be...>wrote: > Am Sonntag 20 September 2009 schrieb Thomas Sharpless: > > One more thing. How does one build a static library with the present > CMake > > script? We need one for Hugin, and on Windows the DLL is not yet even > > buildable. > > I compile on ubuntu, and don't need static library. But I could try to > create this one too. > > > -- Tom > > Kornel > -- > Kornel Benko > Kor...@be... > |
From: Kornel B. <Kor...@be...> - 2009-09-20 12:44:27
|
Am Sonntag 20 September 2009 schrieb Thomas Sharpless: > Hi Kornel > > Please do commit the change to allow building static libpano; I will try it > on Windows. > > Regards, Tom Did it. Kornel -- Kornel Benko Kor...@be... |
From: Thomas S. <tks...@gm...> - 2009-09-21 01:05:22
|
Hi Kornel I don't think that it is feasible with MSVC to build both static and dll libraries at once; so I have added a variable LIBPANO13_TYPE ("shared" or "static" to select one or the other. With this I can build a static libpano13 OK, however it turns out that the target name has to be "pano13" rather than "pano13a" otherwise the linker does not find the library (directory problem, name is OK). However, as it stands the tools still do not link correctly -- none of the image format libraries or getopt is seen by the linker, and the following are also undefined (whose source I don't know): _htons@4, _CenterDialog, _SetWindowOwner, _wndOwner, _hDllInstance So the script and / or source tree still needs some work to build on Windows. Regards, Tom 2009/9/20 Kornel Benko <Kor...@be...> > Am Sonntag 20 September 2009 schrieb Thomas Sharpless: > > Hi Kornel > > > > Please do commit the change to allow building static libpano; I will try > it > > on Windows. > > > > Regards, Tom > > Did it. > > Kornel > > -- > Kornel Benko > Kor...@be... > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > |
From: Kornel B. <Kor...@be...> - 2009-09-21 06:19:24
|
Am Monday 21 September 2009 schrieb Thomas Sharpless: > Hi Kornel > > I don't think that it is feasible with MSVC to build both static and dll > libraries at once; so I have added a variable LIBPANO13_TYPE ("shared" or > "static" to select one or the other. With this I can build a static > libpano13 OK, however it turns out that the target name has to be "pano13" > rather than "pano13a" otherwise the linker does not find the library > (directory problem, name is OK). This ("pano13a" ) was needed, because of building both at the same time. It changes the name only _after_ the installation step. In windows you may need to link against pano13a for the dll. > However, as it stands the tools still do not link correctly -- none of the > image format libraries or getopt is seen by the linker, and the following > are also undefined (whose source I don't know): _htons@4, _CenterDialog, > _SetWindowOwner, _wndOwner, _hDllInstance Sorry, I can't help here. I know nearly nothing about windows builds. > So the script and / or source tree still needs some work to build on > Windows. > > Regards, Tom > Kornel -- Kornel Benko Kor...@be... |