building libpano on windows using cmake

[allard]

Hi all,

I've fixed most of the problems I had building libpano (SVN1093 a.k.a.
beta3) with CMake on windows, but there's one little thing I still
can't get right. First the solved problems:

I had to replace "ADD_DEFINITIONS(-D__Win__)" in Cmakelists.txt with
"ADD_DEFINITIONS(-D__Ansi__)" to get rid of some unresolved symbol
errors (thanks for the tip Jim Watters)

In fftn.c, the following line of code produced 'not found' errors
# include __FILE__
so I replaced it by
# include "fftn.c"

Then, there is apparently some confusion about where the pano13.lib is
supposed to be located. When building the debug version, it is created
in the folder 'Debug', which is created under the build directory. But
subsequent tools sometimes expect it to be in the 'tools' folder.
Copying pano13.lib there eliminates the errors. <edit> upgrading to
svn1098 also

After this, a lot of unresolved symbol errors related to getopt kept
showing up. Copying the compat_win32 folder all over the place didn't
help. Finally, I managed to get rid of them by adding the following
line to PTCommon.c:
#include "tools/compat_win32/getopt.c"
Only the .h file was included, apparently this was not enough.

I don't know if all of these solutions I found by trial and error are
good practice, but they seem to have worked. Suggestions for how to do
it better are welcome. All tools build now, except for PTBlender. This
gives an error that says:

"pano13.lib(ColourBrightness.obj) : error LNK2019: unresolved external
symbol _htons@4 referenced in function _OutputPhotoshopCurve"

Any idea what could cause that?

Allard

[Kornel Benko]

Am Tuesday 13 October 2009 schrieb allard:
>
> Hi all,

Hi Allard,

> I've fixed most of the problems I had building libpano (SVN1093 a.k.a.
> beta3) with CMake on windows, but there's one little thing I still
> can't get right.

Nice :)

> First the solved problems:
>
> I had to replace "ADD_DEFINITIONS(-D__Win__)" in Cmakelists.txt with
> "ADD_DEFINITIONS(-D__Ansi__)" to get rid of some unresolved symbol
> errors (thanks for the tip Jim Watters)

What is your compiler, maybe we could do it compiler-dependent

> In fftn.c, the following line of code produced 'not found' errors
> # include __FILE__

How is it possible, that _FILE_ does not expand to a valid path on your system?

> so I replaced it by
> # include "fftn.c"
>
> Then, there is apparently some confusion about where the pano13.lib is
> supposed to be located. When building the debug version, it is created
> in the folder 'Debug', which is created under the build directory. But
> subsequent tools sometimes expect it to be in the 'tools' folder.
> Copying pano13.lib there eliminates the errors. <edit> upgrading to
> svn1098 also

This Debug-folder was new to me. Somehow I start to think, that even cmake is very platform independent.
Don't have here appropiate windows machine, so cannot help much.

You may try add this library in tools/CMakeLists.txt

line 18++:
if(WIN32)
list(APPEND commands panoinfo)
list(APPEND _common_libs ../Debug/pano13.lib)
endif()

> After this, a lot of unresolved symbol errors related to getopt kept
> showing up. Copying the compat_win32 folder all over the place didn't
> help. Finally, I managed to get rid of them by adding the following
> line to PTCommon.c:
> #include "tools/compat_win32/getopt.c"
> Only the .h file was included, apparently this was not enough.

Here I would add tools/compat_win32/getopt.c to the list of sources ov pano13 lib

like (from line 46 on):
IF(WIN32)
SET(wxWidgets_ROOT_DIR ${SOURCE_BASE_DIR}/wxWidgets-2.8.10)
ADD_DEFINITIONS(-D__Win__)
FIND_PACKAGE(wxWidgets REQUIRED)
SET(win_c tools/compat_win32/getopt.c)
ENDIF(WIN32)

> I don't know if all of these solutions I found by trial and error are
> good practice, but they seem to have worked. Suggestions for how to do
> it better are welcome. All tools build now, except for PTBlender. This
> gives an error that says:
>
> "pano13.lib(ColourBrightness.obj) : error LNK2019: unresolved external
> symbol _htons@4 referenced in function _OutputPhotoshopCurve"

_htons is network. It transforms local (short) data to network order.
On OpenSuSE it is in library /usr/lib/libc.a, which is part of package glibc-devel.

> Any idea what could cause that?
>
> Allard
>

Please try and report here.

Kornel
--
Kornel Benko
Kornel...@berlin.de

[Tom Sharpless]

Hi Allard

_htons@4 is an entry point in the Windows socket library DLL;
wsock32.lib should be included in the list of libraries given to the
linker.

Are you building on Windows with or without Java support?

Regards, Tom

[allard]

Hi Tom,

ThanksI didn't seem to have that lib anywhere, now installing a
platform SDK to get it.

Where is the 'list of libraries given to the linker'?

Allard

[allard]

Hi Kornel, thanks for the tips. I got it running now even after
rolling back the insertions in the ptcommon and ptblender files.
Just the _FILE_ thing still needs my manual fiddling.

See also below

> What is your compiler, maybe we could do it compiler-dependent

I work with Visual C++ express edition 2008 and whatever is the
default compiler for that.

>
> > In fftn.c, the following line of code produced 'not found' errors
> > # include __FILE__
>
> How is it possible, that _FILE_ does not expand to a valid path on your system?

I don't know, but it seems to be a more common problem given the
commented line of code there

>
> This Debug-folder was new to me. Somehow I start to think, that even cmake is very platform independent.
> Don't have here appropiate windows machine, so cannot help much.
>
> You may try add this library in tools/CMakeLists.txt
>
> line 18++:
>         if(WIN32)
>                 list(APPEND commands panoinfo)
>                 list(APPEND _common_libs ../Debug/pano13.lib)
>         endif()
>

I think this problem has already been solved in 1098 so this is no
longer necessary

>
> Here I would add tools/compat_win32/getopt.c to the list of sources ov pano13 lib
>
> like (from line 46 on):
>         IF(WIN32)
>                 SET(wxWidgets_ROOT_DIR ${SOURCE_BASE_DIR}/wxWidgets-2.8.10)
>                 ADD_DEFINITIONS(-D__Win__)
>                 FIND_PACKAGE(wxWidgets REQUIRED)
>                 SET(win_c  tools/compat_win32/getopt.c)
>         ENDIF(WIN32)
>

That works! Thanks, allard

[allard]

OK, I got the lib and found a way to manually tell MSVC to include it
in the PTBlender project by setting it in the properties of the
project.
Build successful! But it would be nice if I knew where to change this
properly.


Next project: building the mosaic version of hugin with this
libpano...

allard
PS, not building with Java support. Would that complicate things
further?

[Kornel Benko]

Am Samstag 17 Oktober 2009 schrieb allard:
> Hi Kornel, thanks for the tips. I got it running now even after
> rolling back the insertions in the ptcommon and ptblender files.
> Just the _FILE_ thing still needs my manual fiddling.
>
> See also below
>
> > What is your compiler, maybe we could do it compiler-dependent
>
> I work with Visual C++ express edition 2008 and whatever is the
> default compiler for that.
>
> > > In fftn.c, the following line of code produced 'not found' errors
> > > # include __FILE__
> >
> > How is it possible, that _FILE_ does not expand to a valid path on your
> > system?
>
> I don't know, but it seems to be a more common problem given the
> commented line of code there

Could you please post this line?

> > This Debug-folder was new to me. Somehow I start to think, that even
> > cmake is very platform independent. Don't have here appropiate windows
> > machine, so cannot help much.
> >
> > You may try add this library in tools/CMakeLists.txt
> >
> > line 18++:
> > if(WIN32)
> > list(APPEND commands panoinfo)
> > list(APPEND _common_libs ../Debug/pano13.lib)
> > endif()
>
> I think this problem has already been solved in 1098 so this is no
> longer necessary

Good.

> > Here I would add tools/compat_win32/getopt.c to the list of sources ov
> > pano13 lib
> >
> > like (from line 46 on):
> > IF(WIN32)
> > SET(wxWidgets_ROOT_DIR
> > ${SOURCE_BASE_DIR}/wxWidgets-2.8.10) ADD_DEFINITIONS(-D__Win__)
> > FIND_PACKAGE(wxWidgets REQUIRED)
> > SET(win_c tools/compat_win32/getopt.c)
> > ENDIF(WIN32)
>
> That works! Thanks, allard

Ok, I will add it.

--
Kornel Benko
Kornel...@berlin.de

[Kornel Benko]

Am Samstag 17 Oktober 2009 schrieb allard:

> OK, I got the lib and found a way to manually tell MSVC to include it
> in the PTBlender project by setting it in the properties of the
> project.
> Build successful! But it would be nice if I knew where to change this
> properly.
>

This lib should be added to ${_common_libs}
CMakeLists.txt:68

set(_common_libs ${TIFF_LIBRARIES} ${ZLIB_LIBRARIES} ${JPEG_LIBRARIES} ${PNG_LIBRARIES})
if(WIN32)
find_library(WXSOCK32 wsock32)
if(NOT ${WXSOCK32} MATCHES "-NOTFOUND")
list(APPEND _common_libs ${WXSOCK32})
endif()
endif(WIN32)

...
> Allard

[Jim Watters]

Panotools already has ENDIAN aware file i/o functions in filter.h
These should have been used instead of using another package for this
one function.

--
Jim Watters
http://photocreations.ca

[Tom Sharpless]

Hi Jim,

Are you saying that some source line that calls htons() should be
rewritten to call something declared in filter.h instead? That sounds
right -- it seems stupid to make a program that does not use network I/
O depend on a sockets library.

But what source file has this silly call in it? If it is a standard
package of some kind, then creating a local version could create more
problems than it solves. If it is something that is already local to
libpano, then by all means rewrite it.

-- Tom

[Kornel Benko]

Am Sonntag 18 Oktober 2009 schrieb Tom Sharpless:
> Hi Jim,
>
> Are you saying that some source line that calls htons() should be
> rewritten to call something declared in filter.h instead? That sounds
> right -- it seems stupid to make a program that does not use network I/
> O depend on a sockets library.

This is, what he was saying.

Instead of calling
x = htons(y)
we should use
short * px = &x;
SHORTNUMBER(y, px);

or better define own function

short our_htons(short y)
{
short x;
short * px = &x;
SHORTNUMBER(y, px);
return(x);
}

The only file which uses htons is ColourBrightness.c, not much work.

Kornel

--
Kornel Benko
Kornel...@berlin.de

[allard]

Hi Kornel,

Saw your question a bit late, sorry. I meant this bit of code:
/* we use CPP to re-include this same file for double/float cases */
//#if !defined (lint) && !defined (__FILE__)
//Error: your compiler is sick! define __FILE__ yourself (a string)
//eg, something like -D__FILE__=\"fftn.c\"
//#endif


Cheers, allard

> Kornel.Be...@berlin.de
>
>  signature.asc
> < 1KViewDownload

[Kornel Benko]

Am Wednesday 21 October 2009 schrieb allard:
>
> Hi Kornel,
>

> Saw your question a bit late, sorry. I meant this bit of code:
> /* we use CPP to re-include this same file for double/float cases */
> //#if !defined (lint) && !defined (__FILE__)
> //Error: your compiler is sick! define __FILE__ yourself (a string)
> //eg, something like -D__FILE__=\"fftn.c\"
> //#endif
>
>
> Cheers, allard

I missed that one.

Back to the problem.

If nobody objects, I will
1.) replace calls to htons() in ColourBrightness.c with local implementation using macro SHORTNUMBER()
2.) Add "tools/compat_win32/getopt.c" to ${win_c} in CMakeLists.txt

The problem with __FILE__ (in fftn.c) will still be there without general solution.

[Kornel Benko]

Done, since nobody objected.