From: Thomas S. <tks...@gm...> - 2009-09-19 22:44:26
|
Thanks, Kornel On Sat, Sep 19, 2009 at 1:24 PM, Kornel Benko <Kor...@be...>wrote: > Hi Thomas, > I could not resist to look into sources. > > There is this in sys_ansi.c:54 > if( JavaUI ){ > JPrintError( toPrint ); > ... > blame gives me dmg 639, which means it was there since 27.7.2006. > The current source has some HAVE_JAVA conditionals so that Java is not required by default. > > I see it now. If NOT JAVA we have to use javastub.c. > With that stub it compiles OK without Java, and it does link OK on Linux. But on Windows there are a lot of Java APIs exported in the .def file for the DLL version of libpano13, which cause linker errors. I can eliminate those by using a .def file version without those exports. So the CMake script can select the appropriate .def according to HAVE_JAVA. HOWEVER I still have problems with the .def exporting other undefined symbols: > 1>Linking... > 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol DLLInit > 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol DispPrg > 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol InfoPrg > 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol > SetWindowOwner > 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol TIFFClose > 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol > TIFFGetField > 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol TIFFOpen > 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol > TIFFReadDirectory > 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol > TIFFReadScanline > 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol > TIFFScanlineSize > 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol > TIFFSetDirectory > 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol > TIFFSetField > 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol > TIFFWriteDirectory > 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol > TIFFWriteScanline > 1>C:\Users\Public\HuginSDK\libpano13-build\Debug\pano13.lib : fatal error > LNK1120: 14 unresolved externals > The TIFF ones actually are declared in the tiff headers, but presumably not in a way that makes them exportable as dll entry points (this using the wxWidgets distribution of libtiff for Windows). About the other 4 I have no idea. Does anyone know why they are a problem? Regards, Tom |
From: Jim W. <jwa...@ph...> - 2009-09-20 04:33:40
|
I have been using a MS Visual Studio solution and project to build panotools and the tools for many years. I have not used the CMake tools. It has been a while since I have created pano13 into a dll but I am able to do it. I have several configurations that I can build Command | GUI Debug | Release Lib | DLL The combinations give a total of 8. All of them are built with Java support. I was able to build GUI & DLL in both Debug and Release. I was not able to build Command & DLL. I get 20 unresolved external symbal errors 1>pano13vc.def : error LNK2001: unresolved external symbol DLLInit The difference between the two is if sys_ansi or sys_win is used in the project. For the GUI applications like the Photoshop Plugins it requires sys_win but for the command tools like PTMender it requires the sys_ansi. I am using pano13vc.def as the def file. The PS Plugins use the following functions FourToThreeBPP SetWindowOwner CopyImageData SetImageDefaults filter_main writePSD writePSDwithLayer myfree Jim Watters Thomas Sharpless wrote: > I would agree that the Java APIs are unnecessary in libpano13. It is > also my impression that with the current source Java is entirely > optional and that libpano13 builds without it by default. So what's > the problem? > > A much bigger problem in my mind is building the library as a Windows > DLL. I can build it as a static library without trouble, but there > seem to be some serious discrepancies between the source code and the > .def file that tells the Windows linker what symbols are to be > exported. It is tempting to just remove the .def file lines that > generate errors, but some of them may be referenced by client programs > and need to be fixed instead. So I have some questions for the PT > developers... > > -- Can anyone actually build a current libpano (12 or 13) as a Windows > DLL? > -- Does any app link to a libpano DLL "by ordinal number"? Or are C > names enough? > -- Can anyone produce a list of libpano13 entry points that are > actually usable? (i.e. not only declared but implemented and working) > -- Can anyone produce a list of such entry points that are actually > called by some app? > > At a more specific level, does anyone know if any of the following > entry points should be considered necessary? > > DLLInit > DispPrg > InfoPrg > SetWindowOwner > > All are listed in the .def file but not found in the code by the linker. > > The same is true for about 10 libtiff function names. Does anyone > know of a reason why libpano should be exporting the functions of an > independent library? Does any app actually call them via libpano? > > Yours in perplexity, Tom > > > On Sat, Sep 19, 2009 at 8:21 PM, Bruno Postle <br...@po... > <mailto:br...@po...>> wrote: > > On Sat 19-Sep-2009 at 16:05 -0700, Daniel M. German wrote: > >I never understood how and why Java is used by libpano. > >It would be really nice if we could abstract the java UI (I think > >that is what it is used for) into a different package. > > ptpicker and pteditor are java and use libpano12. They are > abandoned and can't be relinked against libpano13, so it is a bit > pointless having an interface for them. > > -- > Bruno > -- Jim Watters http://photocreations.ca |
From: Thomas S. <tks...@gm...> - 2009-09-20 12:48:24
|
Thanks Dan & Jim The problem I'm having with building a Windows DLL is that the .def file in the SVN calls for a great many exports that are not present in the compiled code. The solution ought to be to provide a correct .def (actually a pair, one without Java, one with). Eveidently you have those, Jim; maybe you could put them in the SVN trunk? Regards, Tom On Sun, Sep 20, 2009 at 12:33 AM, Jim Watters <jwa...@ph...>wrote: > I have been using a MS Visual Studio solution and project to build > panotools and the tools for many years. I have not used the CMake tools. > > It has been a while since I have created pano13 into a dll but I am able > to do it. > I have several configurations that I can build > Command | GUI > Debug | Release > Lib | DLL > > The combinations give a total of 8. All of them are built with Java > support. > > I was able to build GUI & DLL in both Debug and Release. > I was not able to build Command & DLL. I get 20 unresolved external > symbal errors > 1>pano13vc.def : error LNK2001: unresolved external symbol DLLInit > > The difference between the two is if sys_ansi or sys_win is used in the > project. > For the GUI applications like the Photoshop Plugins it requires sys_win > but for the command tools like PTMender it requires the sys_ansi. > > I am using pano13vc.def as the def file. > > The PS Plugins use the following functions > FourToThreeBPP > SetWindowOwner > CopyImageData > SetImageDefaults > filter_main > writePSD > writePSDwithLayer > myfree > > Jim Watters > > > Thomas Sharpless wrote: > > I would agree that the Java APIs are unnecessary in libpano13. It is > > also my impression that with the current source Java is entirely > > optional and that libpano13 builds without it by default. So what's > > the problem? > > > > A much bigger problem in my mind is building the library as a Windows > > DLL. I can build it as a static library without trouble, but there > > seem to be some serious discrepancies between the source code and the > > .def file that tells the Windows linker what symbols are to be > > exported. It is tempting to just remove the .def file lines that > > generate errors, but some of them may be referenced by client programs > > and need to be fixed instead. So I have some questions for the PT > > developers... > > > > -- Can anyone actually build a current libpano (12 or 13) as a Windows > > DLL? > > -- Does any app link to a libpano DLL "by ordinal number"? Or are C > > names enough? > > -- Can anyone produce a list of libpano13 entry points that are > > actually usable? (i.e. not only declared but implemented and working) > > -- Can anyone produce a list of such entry points that are actually > > called by some app? > > > > At a more specific level, does anyone know if any of the following > > entry points should be considered necessary? > > > > DLLInit > > DispPrg > > InfoPrg > > SetWindowOwner > > > > All are listed in the .def file but not found in the code by the linker. > > > > The same is true for about 10 libtiff function names. Does anyone > > know of a reason why libpano should be exporting the functions of an > > independent library? Does any app actually call them via libpano? > > > > Yours in perplexity, Tom > > > > > > On Sat, Sep 19, 2009 at 8:21 PM, Bruno Postle <br...@po... > > <mailto:br...@po...>> wrote: > > > > On Sat 19-Sep-2009 at 16:05 -0700, Daniel M. German wrote: > > >I never understood how and why Java is used by libpano. > > >It would be really nice if we could abstract the java UI (I think > > >that is what it is used for) into a different package. > > > > ptpicker and pteditor are java and use libpano12. They are > > abandoned and can't be relinked against libpano13, so it is a bit > > pointless having an interface for them. > > > > -- > > Bruno > > > > > -- > Jim Watters > http://photocreations.ca > > > > ------------------------------------------------------------------------------ > 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: Jim W. <jwa...@ph...> - 2009-11-08 03:07:23
|
Thomas Sharpless wrote: > The problem I'm having with building a Windows DLL is that the .def > file in the SVN calls for a great many exports that are not present in > the compiled code. The solution ought to be to provide a correct .def > (actually a pair, one without Java, one with). Eveidently you have > those, Jim; > maybe you could put them in the SVN trunk? > > Regards, Tom The DLL version of libpano13 should not be distributed. All the tools should be statically linked to libpano13.lib I continue to build the DLL version just to make sure nothing gets broken. The following changes allow building both a GUI and CMD version of the DLL without Java. I commented out these. They should not be called directly. They get called by filter_main but not an outside app. ; DispPrg@16 = DispPrg @8 ; SetCPrefs@16 = SetCPrefs @9 ; SetLumOpt@16 = SetLumOpt @11 ; DLLInit@12 = DLLInit @12 ; SetRadOpt@16 = SetRadOpt @13 ; SetHorOpt@16 = SetHorOpt @15 ; SetVerOpt@16 = SetVerOpt @16 ; SetScOpt@16 = SetScOpt @17 ; SetShOpt@16 = SetShOpt @18 ; SetCrOpt@16 = SetCrOpt @19 ; SetAdPrefs@16 = SetAdPrefs @20 ; SetPerspPrefs@16 = SetPerspPrefs @21 ; SetRem@16 = SetRem @22 ; SetSiz@16 = SetSiz @23 ; SetIntp@16 = SetIntp @24 ; InfoPrg@16 = InfoPrg @26 ; SetCutOpt@16 = SetCutOpt @27 ; SetPanOpt@16 = SetPanOpt @28 ; SetFrPrefs@16 = SetFrPrefs @29 I commented out these, I might be wrong about them but I don't think they should be exported. ; readImage @73 ; writeImage @74 ; makeTempPath @76 ; VerifyTiffsAreCompatible @177 ; AddStitchingMasks @178 ; CreatePSD @180 ; TiffSetImageParameters @185 ; TiffGetImageParameters @186 These functions have been updated with pano as a prefix. panoFlattenTIFF @179 panoCreatePanorama @181 panoReplaceExt @183 I have also commented out the java functions. That way they are not lost if they get migrated over to another project. There are two versions, one for VC and one for gcc. With the above changes then only one file is need again. I created empty two functions in sys_ansi to allow building CMD version of the DLL. void SetWindowOwner(HWND Owner); void CenterDialog(HWND hDlg); I am also checking in my updated version of the VisualStudio Solution and project files -- Jim Watters http://photocreations.ca |
From: dmg <dm...@uv...> - 2009-09-19 23:05:48
|
I never understood how and why Java is used by libpano. It would be really nice if we could abstract the java UI (I think that is what it is used for) into a different package. My name in the blame is the result of the refactoring/cleaning up I did few years ago. --dmg 2009/9/19 Thomas Sharpless <tks...@gm...>: > Thanks, Kornel > > On Sat, Sep 19, 2009 at 1:24 PM, Kornel Benko <Kor...@be...> > wrote: >> >> Hi Thomas, >> I could not resist to look into sources. >> >> There is this in sys_ansi.c:54 >> if( JavaUI ){ >> JPrintError( toPrint ); >> ... >> blame gives me dmg 639, which means it was there since 27.7.2006. > > The current source has some HAVE_JAVA conditionals so that Java is not > required by default. >> >> I see it now. If NOT JAVA we have to use javastub.c. > > With that stub it compiles OK without Java, and it does link OK on Linux. > But on Windows there are a lot of Java APIs exported in the .def file for > the DLL version of libpano13, which cause linker errors. I can eliminate > those by using a .def file version without those exports. So the CMake > script can select the appropriate .def according to HAVE_JAVA. > > HOWEVER I still have problems with the .def exporting other undefined > symbols: >> >> 1>Linking... >> 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol DLLInit >> 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol DispPrg >> 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol InfoPrg >> 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol >> SetWindowOwner >> 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol >> TIFFClose >> 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol >> TIFFGetField >> 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol TIFFOpen >> 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol >> TIFFReadDirectory >> 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol >> TIFFReadScanline >> 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol >> TIFFScanlineSize >> 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol >> TIFFSetDirectory >> 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol >> TIFFSetField >> 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol >> TIFFWriteDirectory >> 1>pano13vc_noJava.def : error LNK2001: unresolved external symbol >> TIFFWriteScanline >> 1>C:\Users\Public\HuginSDK\libpano13-build\Debug\pano13.lib : fatal error >> LNK1120: 14 unresolved externals > > > The TIFF ones actually are declared in the tiff headers, but presumably not > in a way that makes them exportable as dll entry points (this using the > wxWidgets distribution of libtiff for Windows). > > About the other 4 I have no idea. Does anyone know why they are a problem? > > Regards, Tom > > > > > ------------------------------------------------------------------------------ > 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 > > -- --dmg --- Daniel M. German http://turingmachine.org |
From: Bruno P. <br...@po...> - 2009-09-20 00:43:04
|
On Sat 19-Sep-2009 at 16:05 -0700, Daniel M. German wrote: >I never understood how and why Java is used by libpano. >It would be really nice if we could abstract the java UI (I think >that is what it is used for) into a different package. ptpicker and pteditor are java and use libpano12. They are abandoned and can't be relinked against libpano13, so it is a bit pointless having an interface for them. -- Bruno |
From: Thomas S. <tks...@gm...> - 2009-09-20 01:19:23
|
I would agree that the Java APIs are unnecessary in libpano13. It is also my impression that with the current source Java is entirely optional and that libpano13 builds without it by default. So what's the problem? A much bigger problem in my mind is building the library as a Windows DLL. I can build it as a static library without trouble, but there seem to be some serious discrepancies between the source code and the .def file that tells the Windows linker what symbols are to be exported. It is tempting to just remove the .def file lines that generate errors, but some of them may be referenced by client programs and need to be fixed instead. So I have some questions for the PT developers... -- Can anyone actually build a current libpano (12 or 13) as a Windows DLL? -- Does any app link to a libpano DLL "by ordinal number"? Or are C names enough? -- Can anyone produce a list of libpano13 entry points that are actually usable? (i.e. not only declared but implemented and working) -- Can anyone produce a list of such entry points that are actually called by some app? At a more specific level, does anyone know if any of the following entry points should be considered necessary? > DLLInit > DispPrg > InfoPrg > SetWindowOwner > All are listed in the .def file but not found in the code by the linker. The same is true for about 10 libtiff function names. Does anyone know of a reason why libpano should be exporting the functions of an independent library? Does any app actually call them via libpano? Yours in perplexity, Tom On Sat, Sep 19, 2009 at 8:21 PM, Bruno Postle <br...@po...> wrote: > On Sat 19-Sep-2009 at 16:05 -0700, Daniel M. German wrote: > >I never understood how and why Java is used by libpano. > >It would be really nice if we could abstract the java UI (I think > >that is what it is used for) into a different package. > > ptpicker and pteditor are java and use libpano12. They are > abandoned and can't be relinked against libpano13, so it is a bit > pointless having an interface for them. > > -- > Bruno > > > ------------------------------------------------------------------------------ > 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: D M G. <dm...@uv...> - 2009-09-20 02:20:04
|
Thomas> -- Can anyone produce a list of such entry points that are actually called by some app? This is what the tools/* use: panoCreatePanorama panoFeatherFile panoFileExists panoFileMakeTemp panoFileName panoFileOutputNamesCreate panoFlattenTIFF panoPSDCreate panoProjectionFeaturesQuery panoReplaceExt panoStitchReplaceMasks panoTiffDisplayInfo panoTiffRead panoTiffVerifyAreCompatible -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |