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 <> 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

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 <
> <>> 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&reg; 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&#45;12, 2009. Register now&#33;
PanoTools-devel mailing list