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?
On Sun, Sep 20, 2009 at 12:33 AM, Jim Watters <jwatters@...:
> 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
> 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
> 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
> 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 <bruno@...
> > <mailto:bruno@...>> 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
> 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!
> PanoTools-devel mailing list