(Probably very basic) help needed for build process on WinXP: missing files?
J. Schneider
after I installed TortoiseSVN to edit translations directly, I thought
it would be a nice idea to try building hugin myself.
Though I am not a programmer.
The explanation in the wiki is not bad, but even the very first step fails.
Maybe someone can point me to where to read further instead of mentoring
me click-by-click on this list.
System is WinXP SP3; unfortunately I installed Visual Studio in German,
so I have to translate backwards here.
I created the directory D:\huginbase\enblend
Cloned the repository, result D:\huginbase\enblend\enblend.
Now I opened enblend_msvc2003.sln.
Changed the target configuration to 'release'.
Compiled (I guess the 4th command from top in the build ("Erstellen")
menu).
I suppose I should get
D:\huginbase\enblend\enblend\INSTALLDIR but I get nothing.
I guess some of the entries about missing files in the 2 build protocols
contain the solution.
Could someone give me a hint?
best regards
Joachim
D:\huginbase\enblend\enblend\src\vigra_impex\Release\BuildLog.htm:
Kompilieren...
cl : command line warning D9035 : The option "Wp64" is deprecated and
will be removed in one of the next versions.
tiff.cxx
.\tiff.cxx(83) : fatal error C1083: File (Include) could not be opened:
"tiff.h": No such file or directory
png.cxx
.\png.cxx(66) : fatal error C1083: File (Include) could not be opened:
"png.h": No such file or directory
jpeg.cxx
.\jpeg.cxx(59) : fatal error C1083: File (Include) could not be opened:
"jpeglib.h": No such file or directory
exr.cxx
.\exr.cxx(53) : fatal error C1083: File (Include) could not be opened:
"ImfRgbaFile.h": No such file or directory
D:\huginbase\enblend\enblend\src\Release\BuildLog.htm:
Kompilieren...
cl : command line warning D9035 : The option "Wp64" is deprecated and
will be removed in one of the next versions.
getopt_long.c
getopt.c
Kompilieren...
cl : command line warning D9035 : The option "Wp64" is deprecated and
will be removed in one of the next versions.
enblend.cc
.\enblend.cc(74) : fatal error C1083: File (Include) could not be
opened: "tiffconf.h": No such file or directory
Yuval Levy
J. Schneider wrote:
> it would be a nice idea to try building hugin myself.
good idea! I'll be happy to mentor you. would it be OK for you, in
exchange for the mentoring, to use your experience and improve the Wiki
instructions?
I assume you're on
<http://wiki.panotools.org/Build_Hugin_for_Windows_with_SDK> - IIRC
there are four different ones in the Wiki and maybe at some point we
should clean a little bit up.
> System is WinXP SP3; unfortunately I installed Visual Studio in German,
> so I have to translate backwards here.
XP SP3, so you're on 32bit (there was never an SP3 for XP 64bit).
feel free to write the German output, ich verstehe. Will be easier for
you, and we can translate the terms to English for the general public
later on.
If it is OK for you, I suggest we do this mentoring session "live" on
this mailing list, so others can profit too. But if you prefer not to
expose the "dirty laundry" in public, i can contact you off-list. The
important things are that
1. you have a good experience
2. we improve the Wiki for those stepping into the same process after you
> I created the directory D:\huginbase\enblend
> Cloned the repository, result D:\huginbase\enblend\enblend.
this means that you installed all the tools, as well as Guido's SDK?
> Now I opened enblend_msvc2003.sln.
what version of Visual Studio do you have? the file to open is open
huginbase/enblend/enblend_msvc2008.sln
the repository is currently in a broken state - a recent change breaks
the MSVC (and the new CMake) build. Only autotools works.
the workaround is to step a little bit back in time, to before the state
of the repository was broken. This is not too bad - the only things that
have changed since are documentation stuff.
to step back in time, you need to look at the repository history, or
log. You have a repository log locally; and there is the repository log
of the master repository. They are not necessarily the same because you
can do changes to your local repository without pushing them to the
master one, although given that you are starting with this your
repository is most likely an exact mirror of the master repository from
which you synced.
the history of the master repository is visible on the web
http://enblend.hg.sourceforge.net/hgweb/enblend/enblend/shortlog
the change that broke the build is the one saying "Couple the source
code and the documentation more tightly".
what you need to do on your end is: right-click on the enblend folder
and select "Hg pull" from the context menu. This will pull in the latest
changes from the master repository. You want to look at the "hg log" (I
think it is available in the TortoiseHg context menu, I don't have a
Windows box in front of me right now and I am writing these instruction
out of memory). Note down the revision number associated with the
revision prior to the one saying "Couple the source code and the
documentation more tightly". Do an "hg update" (again: available form
the TortoiseHg context menu) to that revision number, with the clean
option. This will bring your enblend tree back in time. Now you can
continue with the build.
> Changed the target configuration to 'release'.
There should be multiple configurations. You want to avoid those with
'OpenMP' because to build with OpenMP you need the professional (paid)
version of MSVC. If you have a good GPU, you may try to build the
version with GPU. And if you often run out of disk space, build the
version without ImageCache. Also if your CPU supports SSE2, build the
version with SSE2. For example you can build "Release SSE2,GPU".
*but* before doing this, you need to complete the SDK. The current SDK
lacks some of the dependencies to build enblend.
IIRC it is lcms that is missing (or outdated; 1.17 in the SDK and 1.18
referred to from the MSVC project files).
* download the source from http://www.littlecms.com/lcms-1.18a.zip
* unpack inside the SDK folder
* inside lcms-1.18 there is a Projects folder. Select the MSVC2008
project. Start it.
* in the configuration manager, select to build lcms only. You do not
need the other tools (that will raise an error because they don't find
some dependencies)
once you built lcms, continue with building enblend.
> I suppose I should get
> D:\huginbase\enblend\enblend\INSTALLDIR but I get nothing.
IIRC it will be in "D:\huginbase\enblend\enblend\src\Release SSE2 GPU"
> I guess some of the entries about missing files in the 2 build protocols
> contain the solution.
yes, the TIFF/JPEG/PNG libraries are inside wxWidgets. What version of
wxWidgets do you have?
HTH
Yuv
anbue
I got the same problems as Joachim, including the German Visual C++
and the missing tiffconf.h.
If I´m understanding well what Yuv explained to us, it should be in
the wxWidgets directory ? I got wxWidgets 2.8.10 with the SDK and
Windows Search doesn´t find a tiff*.h in huginbase.
Happy not to be alone.
Andreas
J. Schneider
> Hallo Joachim,
>
> J. Schneider wrote:
>> it would be a nice idea to try building hugin myself.
>
> good idea! I'll be happy to mentor you. would it be OK for you, in
> exchange for the mentoring, to use your experience and improve the Wiki
> instructions?
> I assume you're on
> <http://wiki.panotools.org/Build_Hugin_for_Windows_with_SDK>
Yes.
> If it is OK for you, I suggest we do this mentoring session "live" on
> this mailing list, so others can profit too.
That's fine for me.
>> I created the directory D:\huginbase\enblend
>> Cloned the repository, result D:\huginbase\enblend\enblend.
>
> this means that you installed all the tools, as well as Guido's SDK?
I did. Just not wxWidgets that you mention later. Should this also be in
the list of tools to install?
I downloaded it and installed it to C:\Programme\wxWidgets-2.8.10.
>> Now I opened enblend_msvc2003.sln.
> what version of Visual Studio do you have? the file to open is open
> huginbase/enblend/enblend_msvc2008.sln
I have "Visual C++ 2008 Express Edition". I just didn't look closely
enough. Now I took ...2008.sln. (But that doesn't change the result.)
Strangely it cannot be opened by double clicking, but when dragged onto
the MSVC window it works.
> the repository is currently in a broken state - a recent change breaks
> the MSVC (and the new CMake) build. Only autotools works.
I don't know what autotools is, but I follow your steps to revert back
to the unbroken stage.
> the workaround is to step a little bit back in time, > ...
> This will bring your enblend tree back in time. Now you can
> continue with the build.
Done. "Update to revision" is the command in my TortoiseHG installation.
And 523 the rev. no.
>> Changed the target configuration to 'release'.
> There should be multiple configurations. ...
> If you have a good GPU, you may try to build the
> version with GPU. And if you often run out of disk space, build the
> version without ImageCache. Also if your CPU supports SSE2, build the
> version with SSE2. For example you can build "Release SSE2,GPU".
The GPU option doesn't work with my Intel 945 Chipset but I needn't use
it and I guess my Core2Duo T5500 (1.66GHz) supports SSE2, so "Release
SSE2,GPU" is what I chose.
> *but* before doing this, you need to complete the SDK. The current SDK
> lacks some of the dependencies to build enblend.
OK, this should be included in the wiki unless it is not fixed in the SDK.
> IIRC it is lcms that is missing (or outdated; 1.17 in the SDK and 1.18
> referred to from the MSVC project files).
Looks like missing. In D:\huginbase\enblend I don't find any lcms*.* file.
> * download the source from http://www.littlecms.com/lcms-1.18a.zip
> * unpack inside the SDK folder
So I have D:\huginbase\enblend containing enblend\ ...
No, I think first I throw all that stuff from
D:\huginbase\enblend\enblend\*.* one level up and resync it to be sure.
OK, now I have D:\huginbase\enblend\ with the enblend repository .hg in
it and
D:\huginbase\lcms-1.18\. Probably I should move it inside ...\enblend.
-> D:\huginbase\enblend\lcms-1.18\.
> * inside lcms-1.18 there is a Projects folder. Select the MSVC2008
> project. Start it.
> * in the configuration manager, select to build lcms only. You do not
> need the other tools (that will raise an error because they don't find
> some dependencies)
This results in
D:\huginbase\enblend\lcms-1.18\Projects\VC2008\LibRelease\*obj and
...\vc90.idb
and a log with 0 errors and 41 warnings like
..\..\src\cmsio1.c(964) : warning C4063: case "-1804014080" ist kein
gültiger Wert für den Schalter der Enumeration "icTagTypeSignature".
d:\huginbase\lcms-1.18\include\icc34.h(352): Siehe Deklaration
von 'icTagTypeSignature'
> once you built lcms, continue with building enblend.
Do I understand correctly that MSVC should realize wxWidgets is
installed and use the TIFF/JPEG/PNG libraries from there?
Obviously not. MSVC still complains. If I understood the output
Die temporäre Datei "d:\huginbase\enblend\src\vigra_impex\Release (GPU,
SSE2)\RSP00000160562384.rsp" wird erstellt. Inhalt:
[
/Ox /Ob2 /Oi /Ot /GL /I "..\..\..\STLport-trunk\stlport" /I "..\include"
/I "..\..\include" /I "..\..\..\tiff-3.8.2\libtiff" /I
"..\..\..\wxWidgets-2.8.10\src\jpeg" /I
"..\..\..\wxWidgets-2.8.10\src\png" /I
"..\..\..\wxWidgets-2.8.10\src\zlib" /I "..\..\..\boost_1_39_0" /I
"..\..\..\lcms-1.17\include" /I "..\..\..\libxmi-1.2" /I "." /I
"..\..\..\Deploy\include" /D "VIGRA_STATIC_LIB" /D "WIN32" /D "NDEBUG"
/D "_LIB" /D "HasTIFF" /D "HasJPEG" /D "HasPNG" /D "HasEXR" /D "_WIN32"
/D "_CRT_SECURE_NO_DEPRECATE" /D "_VC80_UPGRADE=0x0710" /D "_MBCS" /FD
/EHsc /MT /GS- /arch:SSE2 /Fo"Release (GPU, SSE2)\\" /Fd"Release (GPU,
SSE2)\vc90.pdb" /W3 /c /Wp64 /Zi /TP /wd4251 .\tiff.cxx
correctly I would probably be able to move my dirctoy wxWidgets-2.8.10
(now in C:\Programme\wxWidgets-2.8.10) in the right place.
"..\..\..\wxW..." is counting from where?
Tried moving it to D:\wxWidgets-2.8.10 and to
D:\huginbase\enblend\wxWidgets-2.8.10
but this is not where it should be either.
Some search led me to
http://www.wxwidgets.org/docs/tutorials.htm where there is a link to
"Intellisense and wxWidgets - How to get MS Visual Studio Intellisense
working with wxWidgets" which might be what I need. ->
http://www.litwindow.com/Knowhow/Intellisense/intellisense.html
But I don't really understand what I would have to do.
>> I suppose I should get
>> D:\huginbase\enblend\enblend\INSTALLDIR but I get nothing.
>
> IIRC it will be in "D:\huginbase\enblend\enblend\src\Release SSE2 GPU"
Yes, "D:\huginbase\enblend\src\Release (GPU, SSE2)" is the directory. So
the one where the build log is put is also where the result should be.
vc90.idb, vc90.pdb, filenameparse.obj is what I got apart from the log.
> HTH
Definitely!
But you see you are dealing with a severe case of ignorance. Once you
mastered bringing me to a working hugin build and we put that into the
wiki more or less everybody should manage.
> Yuv
Joachim
Yuval Levy
I'll be rebooting my workstation into Windows in a little while and will
get back to both of you with more detailed feedback.
Yes, wxWidgets comes with the SDK. Downloading and installing the
wxWidgets binaries is not the thing to do (Joachim) because there are
some (small) [modifications] required to wxWidgets before building it.
These modifications are part of the instructions to build the SDK. You
do not need to follow them. You do want to read them as they increase
your awareness of what could be going wrong.
I suspect that the problem you are experiencing is because the MSVC
projects in the enblend Hg repository is "out of sync" with the SDK -
specifically it tries to look for a newer wxWidgets version than the one
in the SDK. I'll confirm later (when my Windows system has booted up).
Yuv
[ modifications]
<http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29_Patches#wxWidgets>
Yuval Levy
J. Schneider wrote:
> I downloaded it and installed it to C:\Programme\wxWidgets-2.8.10.
not good, please uninstall. the default binaries of wxWidgets are not
ready for Hugin. They must be recompiled. And Hugin and Enblend expect
them at a different location than where the binaries install.
You should have wxWidgets-2.8.10 inside the SDK. If you don't let me
know and I'll guide you through the process of updating your SDK with
wxWidgets-2.8.10
> Done. "Update to revision" is the command in my TortoiseHG installation.
> And 523 the rev. no.
good. well done.
> The GPU option doesn't work with my Intel 945 Chipset but I needn't use
> it and I guess my Core2Duo T5500 (1.66GHz) supports SSE2, so "Release
> SSE2,GPU" is what I chose.
SSE2,GPU will not work with your chipset. Go simple Release for now.
> So I have D:\huginbase\enblend containing enblend\ ...
> No, I think first I throw all that stuff from
> D:\huginbase\enblend\enblend\*.* one level up and resync it to be sure.
yes, you want enblend's source code to be at the first level under
D:\huginbase
> OK, now I have D:\huginbase\enblend\ with the enblend repository .hg
good
> D:\huginbase\lcms-1.18\. Probably I should move it inside ...\enblend.
> -> D:\huginbase\enblend\lcms-1.18\.
no. you want to leave it D:\huginbase\lcms-1.18\ - in general you don't
want to move stuff around that came with the SDK. The only locations we
need to fix are those of the folders that you are adding inside
D:\huginbase.
>> * inside lcms-1.18 there is a Projects folder. Select the MSVC2008
>> project. Start it.
>> * in the configuration manager, select to build lcms only. You do not
>> need the other tools (that will raise an error because they don't find
>> some dependencies)
> This results in
> D:\huginbase\enblend\lcms-1.18\Projects\VC2008\LibRelease\*obj and
> ...\vc90.idb
> and a log with 0 errors and 41 warnings like
> ..\..\src\cmsio1.c(964) : warning C4063: case "-1804014080" ist kein
> gültiger Wert für den Schalter der Enumeration "icTagTypeSignature".
> d:\huginbase\lcms-1.18\include\icc34.h(352): Siehe Deklaration
> von 'icTagTypeSignature'
good. now rinse and repeat with lcms-1.18 at the right location ;-)
>> once you built lcms, continue with building enblend.
> Do I understand correctly that MSVC should realize wxWidgets is
> installed and use the TIFF/JPEG/PNG libraries from there?
maybe. it is a combination of factors.
> I would probably be able to move my dirctoy wxWidgets-2.8.10
> (now in C:\Programme\wxWidgets-2.8.10) in the right place.
> "..\..\..\wxW..." is counting from where?
> Tried moving it to D:\wxWidgets-2.8.10 and to
> D:\huginbase\enblend\wxWidgets-2.8.10
> but this is not where it should be either.
no. please don't move around SDK folders. we will fix what is in your
folders relatively to them.
> Some search led me to
> http://www.wxwidgets.org/docs/tutorials.htm where there is a link to
> "Intellisense and wxWidgets - How to get MS Visual Studio Intellisense
> working with wxWidgets" which might be what I need. ->
> http://www.litwindow.com/Knowhow/Intellisense/intellisense.html
> But I don't really understand what I would have to do.
you went too far.
>> HTH
> Definitely!
> But you see you are dealing with a severe case of ignorance. Once you
> mastered bringing me to a working hugin build and we put that into the
> wiki more or less everybody should manage.
ignorance can be easily fixed. I'm an ignorant myself. I think the last
all scient human being died two or three centuries ago. Since then,
we're all ignorants one way or another, simply because the whole body of
human knowledge would take much much more than a life time to
learn/understand.
I think I am dealing with a normal case of open source itch; and with a
severe case of impatience coupled with a healthy dose of curiosity;
ability to fiddle; willingness to take risks. A good cocktail :-)
The medicine is simple: stop. breath. think. There is time to act later.
Now here is what I want you to do:
* right-click on enblend in the property manager (on the left hand side
of the IDE). Look at its properties.
* Navigate on the left hand side to Configuration Properties -> C/C++ ->
General
* On the right and side there is an Additional Include Directories property.
* Click on it, then click on the ... button on its right to edit it. Do
not edit (unless you know what you are doing), just read the values that
are there and post them here.
* These values are folders. You want to check that these folders exist,
relative to enblend\src
* You already have most of them from the SDK, I suspect one or two may
be missing. Which ones?
* Repeat the same exercise with Configuration Properties -> Linker ->
General and the Additional Library Directories property.
you are much closer to success than you think; but you are also very
excited and willing to try things that may break your builds. Don't
worry, keep playing, the worse case scenario is that you'll have to
unpack a fresh SDK; and sync a fresh enblend checkout; and follow the
instruction from the beginning again.
cheers
Yuv
J. Schneider
>> I downloaded it and installed it to C:\Programme\wxWidgets-2.8.10.
> not good, please uninstall.
Done.
> the default binaries of wxWidgets are not
> ready for Hugin. They must be recompiled. And Hugin and Enblend expect
> them at a different location than where the binaries install.
OK, I'm going to get myself the source.
> You should have wxWidgets-2.8.10 inside the SDK. If you don't let me
> know and I'll guide you through the process of updating your SDK with
> wxWidgets-2.8.10
I guess we'll have to do this. I looked for tiff.h and wx*.* inside
huginbase and there is nothing.
Probably we should structure the instructions on the wiki like
"Ideally you get these tools and start compiling ... (whole process)
and in case dependency 1/2/... is missing/broken get it here/here/...
(describing these additional processes in later sections or on separate
pages)." But we can think about this later.
>> -> D:\huginbase\enblend\lcms-1.18\.
> no. you want to leave it D:\huginbase\lcms-1.18\
Done.
>>> * inside lcms-1.18 there is a Projects folder. Select the MSVC2008
>>> project. Start it.
>>> * in the configuration manager, select to build lcms only. You do not
>>> need the other tools (that will raise an error because they don't find
>>> some dependencies)
>> This results in
>> D:\huginbase\enblend\lcms-1.18\Projects\VC2008\LibRelease\*obj and
>> ...\vc90.idb
>> and a log with 0 errors and 41 warnings like
>> ..\..\src\cmsio1.c(964) : warning C4063: case "-1804014080" ist kein
>> gültiger Wert für den Schalter der Enumeration "icTagTypeSignature".
>> d:\huginbase\lcms-1.18\include\icc34.h(352): Siehe Deklaration
>> von 'icTagTypeSignature'
>
> good. now rinse and repeat with lcms-1.18 at the right location ;-)
Done. (I'm feeling so fresh and clean now ;-) Still same warnings, but
no errors. I leave the result where it is.
>>> once you built lcms, continue with building enblend.
>> <snip> [Tried to move my directoy wxWidgets-2.8.10 to a place
>> where MSVC finds it to compile enblend]
> no. please don't move around SDK folders. we will fix what is in your
> folders relatively to them.
OK. But for now I uninstalled it anyway and I am going to compile it
according to your instructions.
> * right-click on enblend in the property manager (on the left hand side
> of the IDE). Look at its properties.
>
> * Navigate on the left hand side to Configuration Properties -> C/C++ ->
> General
>
> * On the right and side there is an Additional Include Directories property.
>
> * Click on it, then click on the ... button on its right to edit it. Do
> not edit (unless you know what you are doing), just read the values that
> are there and post them here.
>
> * These values are folders. You want to check that these folders exist,
> relative to enblend\src
So ..\.. is huginbase and e.g.
..\..\STLport-trunk\stlport would be
huginbase\STLport-trunk\stlport. OK
>
> * You already have most of them from the SDK, I suspect one or two may
> be missing. Which ones?
..\..\STLport-trunk\stlport NO
..\include YES
..\..\include NO
..\..\tiff-3.8.2\libtiff NO
..\..\wxWidgets-2.8.10\src\jpeg all wxWidgets are missing but you are
..\..\wxWidgets-2.8.10\src\png going to tell me what to do about
..\..\wxWidgets-2.8.10\src\zlib this.
..\..\boost_1_39_0 NO
..\..\lcms-1.18\include YES
..\..\libxmi-1.2 NO
. of course
..\..\glew\include NO
..\..\glut\include NO
> * Repeat the same exercise with Configuration Properties -> Linker ->
> General and the Additional Library Directories property.
..\..\wxWidgets-2.8.10\lib\vc_lib NO, see above
..\..\lcms-1.18\Lib\MS YES
..\..\libxmi-1.2\Release NO
..\..\STLport-trunk\lib NO
..\..\Deploy\lib\Release NO
..\..\tiff-3.8.2\libtiff NO
..\..\glew\lib NO
..\..\glut\Release NO
Quite a few missing. Do I really need all of them?
> you are much closer to success than you think; but you are also very
> excited and willing to try things that may break your builds. Don't
> worry, keep playing, the worse case scenario is that you'll have to
> unpack a fresh SDK; and sync a fresh enblend checkout; and follow the
> instruction from the beginning again.
That's why I don't worry.
open-source-itching
Joachim
Yuval Levy
J. Schneider wrote:
>> the default binaries of wxWidgets are not
>> ready for Hugin. They must be recompiled. And Hugin and Enblend expect
>> them at a different location than where the binaries install.
> OK, I'm going to get myself the source.
before doing that we should try to make the wxWidgets that are inside
the SDK work. This way we'll know if the SDK needs updating.
I'm looking at the SDK (20090509, from Guido) right now, and I see the
following folders:
* wxWidgets-2.9.10
* UnxUtils
* OpenEXR
* libxml2-2.7.3
* libpano (you'll replace this one *later* - first let's get Hugin
working as-is)
* glew
* gettext
* expat-2.0.1
* exiv2-0.18.1
* exiftool
* Deploy
* boost_1_39_0
* autopano-sift-C
>> You should have wxWidgets-2.8.10 inside the SDK. If you don't let me
>> know and I'll guide you through the process of updating your SDK with
>> wxWidgets-2.8.10
> I guess we'll have to do this. I looked for tiff.h and wx*.* inside
> huginbase and there is nothing.
you might be better off starting with a new, clean huginbase. but wait,
there is something you can do before.
> Probably we should structure the instructions on the wiki like
> "Ideally you get these tools and start compiling ... (whole process)
> and in case dependency 1/2/... is missing/broken get it here/here/...
> (describing these additional processes in later sections or on separate
> pages)." But we can think about this later.
Yes. Hugin and many of the dependencies are a moving target, so there
will be often missing/broken stuff. In general it should be: try with
the SDK, and if it does not work, start updating the SDK.
There are already instructions on the wiki to build the SDK.
>>> -> D:\huginbase\enblend\lcms-1.18\.
>> no. you want to leave it D:\huginbase\lcms-1.18\
> Done.
before starting from scratch you may want to zip lcms-1.18 and save it
away. this will be an upgrade to a freshly installed SDK (huginbase).
We had already discussed this kind of incremental upgrade with Guido.
The instructions, and what you are building now, could be a step further
in the implementation.
So the instructions should be something like:
- if enblend does not find lcms.h, look at the project properties to
identify what folder it should be in. and if your don't have that
folder, or if you have e.g. lcms-0.17 while enblend require lcms-0.18,
download the lcms-0.18 replacement (incremental update to the SDK). and
only if there is no download (or if you are feeling an itch), go with
the build instructions, which should be on the wiki page describing how
to build the SDK.
>> * You already have most of them from the SDK, I suspect one or two may
>> be missing. Which ones?
> Quite a few missing. Do I really need all of them?
yes you do. and you bumped into a problem that I hope will be solved (at
least partially) with the next edition of the SDK. The current Hugin SDK
has only what it takes to *build* Hugin. Not the related tools, like
Enblend. We will change that.
First, I see from your report that your copy of the SDK is incomplete.
>
> ..\..\STLport-trunk\stlport NO
ok, we'll need to build that one. Instructions for 64 bit are at
<http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29#STLport_.2864-bit_Only.29>
we'll need to adapt them for 32bit.
you could download the source from http://sourceforge.net/projects/stlport/
or (better) get them with SVN from
https://stlport.svn.sourceforge.net/svnroot/stlport/trunk/STLport (which
is what I have in my current SDK).
the instructions to build it are in the INSTALL file, and make use of
nmake (that you have installed with MSVC).
> ..\include YES
> ..\..\include NO
I would not worry about this one for now - IIRC it will be generated
when you build enblend/enfuse
> ..\..\tiff-3.8.2\libtiff NO
ah yes, so it does not even look inside wxWidgets for tiff. you could
try to replace it with ..\..\wxWidgets-2.8.10\src\tiff - this would
solve us one extra folder. Else, we'll have to build tiff-3.8.2.
> ..\..\wxWidgets-2.8.10\src\jpeg all wxWidgets are missing but you are
> ..\..\wxWidgets-2.8.10\src\png going to tell me what to do about
> ..\..\wxWidgets-2.8.10\src\zlib this.
> ..\..\boost_1_39_0 NO
> . of course
> ..\..\glew\include NO
mhhh. something is definitely broken with the unpacked SDK. When you
unpack an SDK from the start, do you find these folders?
> ..\..\lcms-1.18\include YES
you built it :)
> ..\..\libxmi-1.2 NO
this is also Enblend-only and thus not in the current SDK.
again, Ryan wrote excellent instructions for the 64bit
<http://wiki.panotools.org/Hugin_SDK_(MSVC_2008)#libxmi-1.2.1_.2864-bit_Only.29>
You can download it from
http://sourceforge.net/projects/gnuwin32/files/libxmi/1.2-1/libxmi-1.2-1-src.zip/download
there is a libxmi.sln inside it, IIRC you just need to start it. Ask if
you have questions.
> ..\..\glut\include NO
http://www.xmission.com/~nate/glut.html - I am not sure if just
unpacking the bin.zip file inside huginbase will be enough. try that. if
it does not work, get src.zip, there are instructions inside. if you
need help, ask.
>> * Repeat the same exercise with Configuration Properties -> Linker ->
>> General and the Additional Library Directories property.
>
> ..\..\wxWidgets-2.8.10\lib\vc_lib NO, see above
> ..\..\lcms-1.18\Lib\MS YES
> ..\..\libxmi-1.2\Release NO
> ..\..\STLport-trunk\lib NO
> ..\..\Deploy\lib\Release NO
> ..\..\tiff-3.8.2\libtiff NO
> ..\..\glew\lib NO
> ..\..\glut\Release NO
all of these will be solved when you dowloaded / installed / built the
above - always inside huginbase.
ciao
Yuv
J. Schneider
real life interfered a bit in the meantime but now I am back. And next
weekend I'm going to help my sister move all across Germany and won't be
at home much, but anyway, step by step ...
> I'm looking at the SDK (20090509, from Guido) right now, and I see the
> following folders:
I don't know what I did to my SDK before but after downloading anew it
looks like this (right column is mine):
> * wxWidgets-2.9.10 wxWidgets-2.8.10
> * UnxUtils OK
> * OpenEXR OK
> * libxml2-2.7.3 OK
> * libpano (you'll replace ... OK
> * glew OK
> * gettext OK
> * expat-2.0.1 OK
> * exiv2-0.18.1 OK
> * exiftool OK
> * Deploy OK
> * boost_1_39_0 OK
> * autopano-sift-C OK
So the only difference is the wxWidgets version. Don't ask me why it
wasn't there before.
So before checking all the dependencies again I just tried compiling
enblend again. Now the errors are:
For vigra_impex:
1>.\tiff.cxx(83) : fatal error C1083: Datei (Include) kann nicht
geöffnet werden: "tiff.h": No such file or directory
I have already chnged that one dependeny to ..\..\wxWidgets-2.8.10\src\tiff
as you suggest below. Somehow it is still not found.
for enblend:
2>d:\huginbase\lcms-1.18\include\icc34.h(154) : error C2018: Unbekanntes
Zeichen '0x40'
2>d:\huginbase\lcms-1.18\include\icc34.h(154) : error C2018: Unbekanntes
Zeichen '0x40'
2>d:\huginbase\lcms-1.18\include\icc34.h(154) : error C2146:
Syntaxfehler: Fehlendes ';' vor Bezeichner 'icUInt8Number'
2>d:\huginbase\lcms-1.18\include\icc34.h(154) : error C4430: Fehlender
Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von
C++ nicht unterstützt.
and the same forth and forth.
--
So now I recheck the dependencies and there is a bit more present:
..\..\STLport-trunk\stlport NO
..\include YES
..\..\include NO
..\..\tiff-3.8.2\libtiff NO but now changed to
..\..\wxWidgets-2.8.10\src\jpeg
..\..\wxWidgets-2.8.10\src\jpeg now YES
..\..\wxWidgets-2.8.10\src\png now YES
..\..\wxWidgets-2.8.10\src\zlib now YES
..\..\boost_1_39_0 now YES
..\..\lcms-1.18\include YES
..\..\libxmi-1.2 NO
. of course
..\..\glew\include now YES
..\..\glut\include NO
>> * Repeat the same exercise with Configuration Properties -> Linker ->
>> General and the Additional Library Directories property.
..\..\wxWidgets-2.8.10\lib\vc_lib now YES
..\..\lcms-1.18\Lib\MS YES
..\..\libxmi-1.2\Release NO
..\..\STLport-trunk\lib NO
..\..\Deploy\lib\Release now YES
..\..\tiff-3.8.2\libtiff NO
..\..\glew\lib now YES
..\..\glut\Release NO
So now I go on getting what is missing as you describe. I'll begin them
all and will see for each one where I get stuck.
--
1. STLport
>> ..\..\STLport-trunk\stlport NO
>
> ok, we'll need to build that one. Instructions for 64 bit are at
> <http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29#STLport_.2864-bit_Only.29>
> we'll need to adapt them for 32bit.
Suppose this is just exchanging "x64" with "x32"
> ... get them with SVN from
> https://stlport.svn.sourceforge.net/svnroot/stlport/trunk/STLport
OK. Rev 6512. I have got STLport now in my huginbase. Is it later to be
renamed STLport-trunk?
> the instructions to build it are in the INSTALL file, and make use of
> nmake (that you have installed with MSVC).
What I read on the wiki page mentioned above seems to be the same in
short. Am I going to build the STLport iostreams library?
Anyway on the MSVC command line I get:
setenv: The command was either misspelled or couldn't be found.
Looks like I started somehow completely wrong.
--
2. libxmi-1.2
>> ..\..\libxmi-1.2 NO
> <http://wiki.panotools.org/Hugin_SDK_(MSVC_2008)#libxmi-1.2.1_.2864-bit_Only.29>
>
> You can download it from
> http://sourceforge.net/projects/gnuwin32/files/libxmi/1.2-1/libxmi-1.2-1-src.zip/download
OK, now I have libxmi-1.2-1 in my huginbase,
> there is a libxmi.sln inside it, IIRC you just need to start it.
No. But the wiki says, I have to apply the libxmi-1.2.diff patch.
Where do I get it and how to apply a patch?
--
3. glut
>> ..\..\glut\include NO
>
> http://www.xmission.com/~nate/glut.html - I am not sure if just
> unpacking the bin.zip file inside huginbase will be enough. try that. if
> it does not work, get src.zip, there are instructions inside.
Got the bin.zip (glut-3.7.6-bin.zip) and extracted to
huginbase\glut-3.7.6-bin. We'll see later if it works.
--
So far so good. If you understand German: Mühsam ernährt sich das
Eichhörnchen!" is what we say about such proceeding. Anyway, step by
step ...
Looking forward to more instructions and more spare time
Joachim
Yuval Levy
J. Schneider wrote:
> real life interfered a bit in the meantime but now I am back. And next
> weekend I'm going to help my sister move all across Germany and won't be
> at home much, but anyway, step by step ...
I hope the move went well and you did not have the same weather we're
having here (pouring rain, and cold wind).
>> * wxWidgets-2.9.10 wxWidgets-2.8.10
...
> So the only difference is the wxWidgets version. Don't ask me why it
> wasn't there before.
I think this was a typo of mine. It is 2.8.10 here too. That said,
wxWidgets evolves steadily and improves the user interface to Hugin, so
it is good to know / document how to build the latest stable version,
which currently is 2.9.0, released 2009-09-08. Info on releases at
http://www.wxwidgets.org/ and http://trac.wxwidgets.org/wiki/Roadmap
...
> ..\..\include NO
if I am not mistaken we can ignore this one.
> ..\..\tiff-3.8.2\libtiff NO but now changed to
> ..\..\wxWidgets-2.8.10\src\jpeg
I don't think it will work, and anyway it is not a good thing to do.
libtiff inside wxWidget is 3.6.1, very old. 3.8.2 was the current stable
version in 2007 IIRC. In the meantime it's 3.9.1 and they are already
releasing 4.0.0 beta.
There is a libtiff-3.8.2 in my SDK folder. I don't recall its origin,
but I have built 3.9.1 and replaced it successfully:
* homepage: http://www.libtiff.org/
* master download site ftp://ftp.remotesensing.org/pub/libtiff/
* download tiff-3.9.1.zip
* unpack into SDK folder
* inside tiff-3.9.1 folder, edit nmake.opt and add JPEG support and ZLIB
support:
JPEG_SUPPORT = 1
JPEGDIR = ../../wxWindows-2.8.10/src/jpeg
JPEG_INCLUDE = -I$(JPEGDIR)
JPEG_LIB = ../../wxWindows-2.8.10/lib/wc_lib/wxjpeg.lib
ZIP_SUPPORT = 1
ZLIBDIR = ../../wxWidgets-2.8.10/src/zlib
ZLIB_INCLUDE = -I$(ZLIBDIR)
ZLIB_LIB = ../../wxWidgets-2.8.10/lib/vc_libwxzlib.lib
* start a MSVC shell
* execute the following commands
VCVARSALL
* cd into the tiff folder
* execute the following commands
nmake /f makefile.vc clean
nmake /f makefile.vc
It will fail (while building some tools), but all we need is the library
and it is produced before.
If you are using anything else but tiff-3.8.2, remember to adjust the
project properties (C/C++ and Linker for each target) in MSVC before
launching the build.
One thing I saw different in 3.9.1 from 3.8.2 is support for JBIG-KIT, a
lossless type of compression. It seems to be patent-encumbered until
February 2011, so I did not investigate further its use (but may be
interesting later on)
> ..\..\lcms-1.18\include YES
did you document the instructions for this in the wiki (do you edit as
you go along) ?
> 1. STLport
>>> ..\..\STLport-trunk\stlport NO
>> ok, we'll need to build that one. Instructions for 64 bit are at
>> <http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29#STLport_.2864-bit_Only.29>
>> we'll need to adapt them for 32bit.
> Suppose this is just exchanging "x64" with "x32"
>> ... get them with SVN from
>> https://stlport.svn.sourceforge.net/svnroot/stlport/trunk/STLport
> OK. Rev 6512. I have got STLport now in my huginbase. Is it later to be
> renamed STLport-trunk?
yes.
>
>> the instructions to build it are in the INSTALL file, and make use of
>> nmake (that you have installed with MSVC).
> What I read on the wiki page mentioned above seems to be the same in
> short. Am I going to build the STLport iostreams library?
Is that what is said in stloport-trunk\INSTALL ?
> Anyway on the MSVC command line I get:
> setenv: The command was either misspelled or couldn't be found.
> Looks like I started somehow completely wrong.
where in the instructions did you find "setenv" ? have you followed the
instructions in stlport-trunk\INSTALL ?
I see that STLport released 5.2.1 recently
http://sourceforge.net/projects/stlport/files/
might be a good idea to switch from SVN to 5.2.1 and see if it is good
enough, rather than deal with the rough edges of an SVN checkout.
> 2. libxmi-1.2
>>> ..\..\libxmi-1.2 NO
>> <http://wiki.panotools.org/Hugin_SDK_(MSVC_2008)#libxmi-1.2.1_.2864-bit_Only.29>
>>
>> You can download it from
>> http://sourceforge.net/projects/gnuwin32/files/libxmi/1.2-1/libxmi-1.2-1-src.zip/download
> OK, now I have libxmi-1.2-1 in my huginbase,
>
>> there is a libxmi.sln inside it, IIRC you just need to start it.
> No. But the wiki says, I have to apply the libxmi-1.2.diff patch.
> Where do I get it and how to apply a patch?
I think the patch is for 64bit. you don't need to patch for your 32bit
Windows XP. is there no libxmi.sln inside?
> 3. glut
>>> ..\..\glut\include NO
>> http://www.xmission.com/~nate/glut.html - I am not sure if just
>> unpacking the bin.zip file inside huginbase will be enough. try that. if
>> it does not work, get src.zip, there are instructions inside.
> Got the bin.zip (glut-3.7.6-bin.zip) and extracted to
> huginbase\glut-3.7.6-bin. We'll see later if it works.
I am starting to lose track of things. Maybe time for an initial summary
of the steps, starting from the SDK?
have a good week
Yuv
J. Schneider
> I hope the move went well and you did not have the same weather we're
> having here (pouring rain, and cold wind).
First something you mentioned at the end of your mail:
> I am starting to lose track of things. Maybe time for an initial
> summary of the steps, starting from the SDK?
Well, if even you lose track ...
I had that same feeling as well.
> did you document the instructions for this in the wiki (do you edit as
> you go along) ?
To be honest, at the moment I feel it is a little too much trial and
error to document it "live" in the wiki. But I did this locally to
keep track of all the ramifications. Without having a real overview of
what I am doing this is really difficult.
I wrote it down and uploaded it to
http://www.joachimschneider.info/moving_target.html
As you see, I always have to remind myself what it is that I am
building, e.g. now it is a dependency of enblend (and not directly of
hugin).
Now I go on and secondly, I would like to solve one misunderstanding.
>> ..\..\tiff-3.8.2\libtiff NO but now changed to
>> ..\..\wxWidgets-2.8.10\src\jpeg
Looks like I didn't read something correctly, took a wrong line or
something like this. So how was it before? I re-entered a line
..\..\tiff-3.8.2\libtiff for the moment (though I might change it later)
and left ..\..\wxWidgets-2.8.10\src\jpeg in the list. So the list now
begins with
..\..\STLport-trunk\stlport
..\include
..\..\include
..\..\tiff-3.8.2\libtiff
..\..\wxWidgets-2.8.10\src\tiff
..\..\wxWidgets-2.8.10\src\jpeg and ... png, zlib,
I guess I fixed this. (But just to understand it better: If tiff.h is
what is needed and it is in the mentioned wxWidgests folder, then
changing the entry to that folder should generally work?)
Now trying to build libtiff:
> * start a MSVC shell
<snip>
> nmake /f makefile.vc
>
> It will fail (while building some tools), but all we need is the library
> and it is produced before.
What is it that I need? The newly created stuff inside libtiff? There is
a new libtiff.dll compiled.
Fine!
>> 1. STLport
>>>> ..\..\STLport-trunk\stlport NO
>>> ok, we'll need to build that one. Instructions for 64 bit are at
>>> <http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29#STLport_.2864-bit_Only.29>
>>> we'll need to adapt them for 32bit.
>> Suppose this is just exchanging "x64" with "x32"
>>> ... get them with SVN from
>>> https://stlport.svn.sourceforge.net/svnroot/stlport/trunk/STLport
>> OK. Rev 6512. I have got STLport now in my huginbase. Is it later to be
>> renamed STLport-trunk?
>
> yes.
>
>>> the instructions to build it are in the INSTALL file, and make use of
>>> nmake (that you have installed with MSVC).
>> What I read on the wiki page mentioned above seems to be the same in
>> short. Am I going to build the STLport iostreams library?
>
> Is that what is said in stloport-trunk\INSTALL ?
There are instructions on "Unpacking and installing STLport" and then
they say "If you DO NOT plan to use STLport iostreams and/or locale
implementation but just the STL, you do not have to build the library."
The separate instuctions to build this follow.
Now I understand that this is the actual build process and the first
steps are just preliminary actions. So building the library is not an
option in a two-part-process but it is the main thing.
And I go on.
>> Anyway on the MSVC command line I get:
>> setenv: The command was either misspelled or couldn't be found.
>> Looks like I started somehow completely wrong.
>
> where in the instructions did you find "setenv" ? have you followed the
> instructions in stlport-trunk\INSTALL ?
No, this was from the wiki. I was confuse by two instructions.
And after I changed into the STLport directory even configure --help
yields a result - I didn't understand that this command is is not part
of MSVC. OK, so
configure msvc9
gives output that looks OK, though doc\README.msvc says it is configure
-c msvcX (where X is the version), but the document is for an older
version (2005).
Same with the instruction in readme.windows: If I omit the "-c" it
states that the desired compiler has been chosen, but
"Das Sprungziel - opt_xtra wurde nicht gefunden." seems to mean that it
did not understand
--extra-cxxflag "/D_WIN32_WINNT=0x0501" in
configure msvc9 --extra-cxxflag "/D_WIN32_WINNT=0x0501"
But the instructions suggest that they are most important for older
versions of windows and since I use XP for building STLport and the same
OS for using STLport for building other software this seems to be OK.
So I leave it at
configure msvc9
and continue with the README.msvc instructions:
"cd "C:\Program Files\Microsoft Visual Studio\VC98\Bin"" seems to be
"C:\Program Files\Microsoft Visual Studio 9.0\VC\bin" in my case.
The problem with the next step
cd C:\STLport\build\lib (d:\huginbase\STLport\build\lib)
and
nmake /fmsvc.mak install
is that my \build\lib folder is empty. No msvc.mak inside. (Though
several instances in other subdirectories.)
So I get myself version 5.2.1 as you recommended
> I see that STLport released 5.2.1 recently
> http://sourceforge.net/projects/stlport/files/
better late than never.
Rename folder to STLport, start over, just that the readme.msvc is not
contained in this version, which I guess I should still follow. So I
have to get myself the svn version again to read it alongside.
Anyway: Runs without error message in the end. (Can't find a build log
that would tell me if anything occurred in between, but I guess it would
have told in the end.)
Hurray!
>> 2. libxmi-1.2
>>>> ..\..\libxmi-1.2 NO
>>> <http://wiki.panotools.org/Hugin_SDK_(MSVC_2008)#libxmi-1.2.1_.2864-bit_Only.29>
>>>
>>> You can download it from
>>> http://sourceforge.net/projects/gnuwin32/files/libxmi/1.2-1/libxmi-1.2-1-src.zip/download
>> OK, now I have libxmi-1.2-1 in my huginbase,
>>
>>> there is a libxmi.sln inside it, IIRC you just need to start it.
>> No. But the wiki says, I have to apply the libxmi-1.2.diff patch.
>> Where do I get it and how to apply a patch?
>
> I think the patch is for 64bit. you don't need to patch for your 32bit
> Windows XP. is there no libxmi.sln inside?
No, there's no *.sln inside.
In the INSTALL file it says
1. Do `./configure', `make', and `make install', as usual. This will
install both libxmi and its header file, xmi.h.
but I'm not sure if "installing" is what I want to do in this case.
So far that's what I have.
regards
Joachim
Oskar Sander
Do you recon your moving target is closing in?
/O
First something you mentioned at the end of your mail:
> I am starting to lose track of things. Maybe time for an initialWell, if even you lose track ...
> summary of the steps, starting from the SDK?
I had that same feeling as well.
To be honest, at the moment I feel it is a little too much trial and
> did you document the instructions for this in the wiki (do you edit as
> you go along) ?
error to document it "live" in the wiki. But I did this locally to
keep track of all the ramifications. Without having a real overview of
what I am doing this is really difficult.
I wrote it down and uploaded it to
http://www.joachimschneider.info/moving_target.html
As you see, I always have to remind myself what it is that I am
building, e.g. now it is a dependency of enblend (and not directly of
hugin).
--
/O
J. Schneider
> I'd like to set up a Windows hugin development environment, but the
> terrifying length of this thread is somewhat deterrent.
>
> Do you recon your moving target is closing in?
can yield more steps. Or end and lead back to "trunk", i.e. the main
objective to build hugin. But if you just follow the actual steps
(http://www.joachimschneider.info/moving_target.html) and leave out all
my errors, mistakes and misapprehensions it is not so much you actually
have to do (to reach whatever intermediate result it is that I have got).
regards
Joachim
Yuval Levy
exactly! Actually you're very close. I could just limit you in your
creativity and curiosity and tell you to do A/B/C and that's it. But
this would not help you nor me. Part of the mentoring job is to deal
with things that I took for granted and look at them anew. Another part
of it is to help you develop that perspective on your own terms.
Following instructions blindly will inevitably break at the code, the
dependencies, or both. Understanding the interaction (which is what you
are doing now) is key to being able to understand what went wrong and
fix it. First fix small things (you already have the tools, you know how
to manipulate project properties in MSVC); then larger things (such as
finding either binaries or source code packages of the dependencies and
integrating them into your build process).
In terms of "just following instructions" (Oskar's question) Windows is
not the easiest platform. You can speed through the Ubuntu instructions
on the wiki and be up and running in less than an hour, and given its
statistics and the feedback we get from it I guess that hundreds if not
thousands of people have done it.
Most people will stop there. It works for them, fine. It does not, they
will look for alternatives but won't have the courage to admit it. Some
actually come here on the list and make us aware of the changes that
broke the instructions. Few make the step to really understand what's
going on. Some make the step to update / edit the wiki. The more
dangerous are those that make the step to edit the wiki (or to suggest
changes) without understanding them. But we keep those at bay (I am
known to bark and sometimes I even bite ;-) ). The best ones are those
like Joachim, who are driven by curiosity and will peek and poke
fiddling at things until they get them working.
I actually fear the day when the Windows (or OSX) build will be
documented as well as the Ubuntu one. There is so much that can go wrong
in Windows; and then people take things for granted and when they don't
work as expected it is Hugin's fault.
Your documentation is excellent, Joachim. It's a good summary of what
you did. At some point you'll need to split it into different levels:
which one is an update of the SDK (e.g. tiff-3.8.2) and which are part
of building with an existing SDK; and how to find out what makes a build
with the existing SDK fail, and how to fix those failures.
You're on the good road and in the right direction.
I'm not sure yet how much time I can dedicate to this in the coming
week, but our common journey is on my todo list, so you'll hear from me.
Yuval Levy
J. Schneider wrote:
> I wrote it down and uploaded it to
> http://www.joachimschneider.info/moving_target.html
looks good and very logical to me.
> I guess I fixed this. (But just to understand it better: If tiff.h is
> what is needed and it is in the mentioned wxWidgests folder, then
> changing the entry to that folder should generally work?)
a .h file is a header file. you also need either the associated source
code (.c or .cpp) or the associated binary object file (.o) - I might be
wrong on the detail - before hacking into Hugin I only did a little bit
of C twenty years ago, so the concepts are pretty rusty in my head.
Others may explain things better.
> What is it that I need? The newly created stuff inside libtiff? There is
> a new libtiff.dll compiled.
.dll are for dynamic linking. we link statically, so what we need is .lib
> So I get myself version 5.2.1 as you recommended
>> I see that STLport released 5.2.1 recently
>> http://sourceforge.net/projects/stlport/files/
> better late than never.
> Rename folder to STLport, start over, just that the readme.msvc is not
> contained in this version, which I guess I should still follow. So I
> have to get myself the svn version again to read it alongside.
> Anyway: Runs without error message in the end. (Can't find a build log
> that would tell me if anything occurred in between, but I guess it would
> have told in the end.)
> Hurray!
so you built STLport successfully? well done! It is better not to rename
it, but to change the project properties. Renaming makes it more
difficult to keep track of the version.
>>> 2. libxmi-1.2
> In the INSTALL file it says
> 1. Do `./configure', `make', and `make install', as usual. This will
> install both libxmi and its header file, xmi.h.
> but I'm not sure if "installing" is what I want to do in this case.
these are standard instruction for Linux/Unix. They don't work for MSVC.
Also IIRC you just want to unpack it there, not necessarily
build/install it. But I may be wrong. I'm currently on Linux and it's
late. I shall look at my Windows box soon.
Yuv
J. Schneider
hope the surprise back home was not too bad.
>> I guess I fixed this. (But just to understand it better: If tiff.h is
>> what is needed and it is in the mentioned wxWidgests folder, then
>> changing the entry to that folder should generally work?)
>
> a .h file is a header file. you also need either the associated source
> code (.c or .cpp) or the associated binary object file (.o) - I might be
> wrong on the detail - ...
I was asking just because tiff.h was the file the compiler complained
about it were missing.
Anyway there are heaps of .obj and .c files in tiff-3.9.1\libtiff but no
tiff.obj or tiff.c.
Maybe we'll see later what MSVC will complain about.
>> What is it that I need? The newly created stuff inside libtiff? There is
>> a new libtiff.dll compiled.
the process is so new to me that I don't know what to expect as the
result of a build, if not simply an .exe.
> .dll are for dynamic linking. we link statically, so what we need is .lib
present as well.
>> So I get myself version 5.2.1 as you recommended
>>> I see that STLport released 5.2.1 recently
>>> http://sourceforge.net/projects/stlport/files/
>> better late than never.
>> Rename folder to STLport, start over, just that the readme.msvc is not
>> contained in this version, which I guess I should still follow. So I
>> have to get myself the svn version again to read it alongside.
>> Anyway: Runs without error message in the end. (Can't find a build log
>> that would tell me if anything occurred in between, but I guess it would
>> have told in the end.)
>> Hurray!
>
> so you built STLport successfully? well done! It is better not to rename
> it, but to change the project properties. Renaming makes it more
> difficult to keep track of the version.
Logical. I tried to find why I did this and I think I misunderstood in
INSTALL: "Make sure you do not rename this "stlport" subdirectory - that
may result in compilation errors." But the SUBdirectory stlport is meant.
But now I rename it back to STLport-5.2.1 that it probably was before.
Changed the two occurrences in the project properties. Corrected in
moving_target.html
>>>> 2. libxmi-1.2
>> In the INSTALL file it says
>> 1. Do `./configure', `make', and `make install', as usual. This will
>> install both libxmi and its header file, xmi.h.
>> but I'm not sure if "installing" is what I want to do in this case.
>
> these are standard instruction for Linux/Unix. They don't work for MSVC.
> Also IIRC you just want to unpack it there, not necessarily
> build/install it. But I may be wrong. I'm currently on Linux and it's
> late. I shall look at my Windows box soon.
OK, let's keep this one for later.
Best regards
Joachim
Nicolas Pelletier
Yuval Levy
Nicolas Pelletier wrote:
> I update the wiki
merci!
> why use png and jpg from one lib, and tiff from another?
lazyness? you probably could also use tiff from wxWidget, but it is an
older version. IIRC tifflib has added features that are worth the effort
compared to what is in wxWidgets (and does not get updated frequently).
I don't recall what it was. Mabye larger file size?
I think it would make sense to use png and jpg directly rather than
through wxWidgets, but first you want to get Enblend up and running with
the current setting.
keep up the good work!
Yuv
Yuv
Enblend)
Did I answer your questions? What is the status of
http://www.joachimschneider.info/moving_target.html ?
I see at the end of moving_target.html something about copying enblend
and enfuse. Does this mean that you built them successfully?
Yuv
J. Schneider
Yuv schrieb:
> Did I answer your questions?
The question about libxmi? no, not yet. So far I did just what I wrote
in moving_target: I unzipped it inside huginbase.
> What is the status of
> http://www.joachimschneider.info/moving_target.html ?
> I see at the end of moving_target.html something about copying enblend
> and enfuse. Does this mean that you built them successfully?
No, this was only the instruction (yours or the wiki's) what to do after
building. When I compiled all information about the process I had I also
included steps that I hadn't executed yet myself.
I think I have put everything so far into moving_target, I think it is
up to date (just fixed a typo in the libxmi section).
After I had some hardware trouble I think I'm back now. (I'm just
verifying that the machine runs reliably even under heavy load by
processing a 60000px wide pano and mailing and browsing at the same
time. Couldn't drive it into blue screen so far.)
regards
Joachim
Yuval Levy
J. Schneider wrote:
> After I had some hardware trouble I think I'm back now.
welcome back. feel free to ask questions again when you've resumed the
process.
Yuv
J. Schneider
I took my moving_target.html and my huginbase directory to reconsider
where I was standing.
- trying to build enblend
- lcms built successfully
- wxWidgets found again after it looked like missing
- libtiff built sucessfully
- STLport: Got the source and did that configure thing - but actually
I don't exactly know (or remember) what this produced. Anyway there
is an STLport folder now.
- libxmi: Got the source and unzipped it. Is this it?
This is where I stopped and the last question was, whether I should do
anything more than unzipping it:
>>>> In the INSTALL file it says
>>>> 1. Do './configure', 'make', and 'make install', as usual. This
>>>> will install both libxmi and its header file, xmi.h.
>>>> but I'm not sure if "installing" is what I want to do in this case.
>>
>> these are standard instruction for Linux/Unix. They don't work for
>> MSVC. Also IIRC you just want to unpack it there, not necessarily
>> build/install it. But I may be wrong. I'm currently on Linux and it's
>> late. I shall look at my Windows box soon.
that I believe I solved I reran a build. The logs are below.
First thing I wondered about is that two projects are built: first
vigra_impex and then enblend. But I found out that I have to chose from
a submenu to build only a certain part.
Next thing is that it complains about missing tiff.h when building
vigra. There was still tiff-3.8.2 listed in it's properties and with
changing it to 3.9.1 this was solved.
(Updated moving_target.html accordingly.)
Building enblend didn't fail any more because of some dependency missing
but because of too many other errors occurring. I put the complete log
at http://www.joachimschneider.info/BuildLog.htm, but beginning and end
are cited here:
2>------ Erstellen gestartet: Projekt: enblend, Konfiguration: Release
Win32 ------
2>Kompilieren...
2>cl : Befehlszeile warning D9035 : Die Option "Wp64" ist veraltet und
wird in einer der n�chsten Versionen entfernt.
2>getopt_long.c
<snip>
2>d:\huginbase\lcms-1.18\include\icc34.h(781) : error C2146:
Syntaxfehler: Fehlendes ';' vor Bezeichner 'count'
2>d:\huginbase\lcms-1.18\include\icc34.h(781) : fatal error C1003: Mehr
als 100 Fehler gefunden; Kompilierung wird abgebrochen.
Ergebnisse Das Buildprotokoll wurde unter
"file://d:\huginbase\enblend\src\Release\BuildLog.htm" gespeichert.
enblend - 264 Fehler, 1 Warnung(en)
I'm not sure if this is some progress. But at least it is a new kind of
failing. I don't know if MSVC had found anything else missing if it
hadn't stopped at some point. (Probably this is configurable, but I
didn't find where.)
Can you give me the next hints?
regards
Joachim
Ryan Sleevi
http://sourceforge.net/tracker/?func=detail&aid=2789320&group_id=77506&atid=
550443
Look at the diff files for libxmi-1.2 and lcms-1.18
tiff.h can be found in wxWidgets, unless you're specifically linking against
a newer version for the larger file support (note: if doing so, make sure
you're not duplicating symbols in wxWidgets)
More details are at http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29
> <snip>
> 2>d:\huginbase\lcms-1.18\include\icc34.h(781) : error C2146:
> Syntaxfehler: Fehlendes ';' vor Bezeichner 'count'
> 2>d:\huginbase\lcms-1.18\include\icc34.h(781) : fatal error C1003: Mehr
> als 100 Fehler gefunden; Kompilierung wird abgebrochen.
> Ergebnisse Das Buildprotokoll wurde unter
> "file://d:\huginbase\enblend\src\Release\BuildLog.htm" gespeichert.
> enblend - 264 Fehler, 1 Warnung(en)
>
> I'm not sure if this is some progress. But at least it is a new kind of
> failing. I don't know if MSVC had found anything else missing if it
> hadn't stopped at some point. (Probably this is configurable, but I
> didn't find where.)
>
> Can you give me the next hints?
> regards
> Joachim
>
> You received this message because you are subscribed to the Google
> Groups "hugin and other free panoramic software" group.
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugi...@googlegroups.com
> To unsubscribe from this group, send email to hugin-
> ptx+uns...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/hugin-ptx
J. Schneider
> where I was standing.
In the properties of enblend I don't see come include folders any more
that used to be listed there (at least according to my email): glew and
glut. No clue why, but I'll add them again.
..\..\glew\include
..\..\glut\include
regards
Joachim
J. Schneider
> See
> http://sourceforge.net/tracker/?func=detail&aid=2789320&group_id=77506&atid=
> 550443
>
> Look at the diff files for libxmi-1.2 and lcms-1.18
>
> tiff.h can be found in wxWidgets, unless you're specifically linking against
> a newer version for the larger file support (note: if doing so, make sure
> you're not duplicating symbols in wxWidgets)
>
> More details are at http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29
programmer at all. (You can't count the remainders of some TurboPascal
from the late 80s.) So I barely know what a diff is, let alone read it.
Neither do I have a clue what a symbol is (I would guess some kind of
variable).
My trying to build hugin is something like the effort to make an SDK or
a documentation that is foolproof, and I kind of volunteer as the fool
needed therefore ...
But do I understand you correctly: If I have tiff-3.xx listed separately
in my list of include directories (instead of
wxWidgets-2.8.10\include\wx where tiff.h is found as well) something can
go wrong or special measures have to be taken. I think Yuv said that the
larger file support (and some other improvements?) make it worth while
using the latest tiff version. What would I have to do to avoid
duplicating symbols - or would using the wxWidgets version be a shorter
(though less perfect) solution to a working build?
And: would using the wxWidgets version work just as simple as putting
wxWidgets-2.8.10\include\wx into the include list instead of tiff-3.xx?
Best regards
Joachim
Douglas Wilkins
Joachim
--
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
J. Schneider
although the wiki paage looks like all the patches from the package
should be applied, I started with patching only libxmi and lcms.
Then I had a look at what MSVC would say and I thought "build new" (or
whatever "neu erstellen" is in the English version) would be a better
choice than just "build". Anyway vigra succeeded (though with a heap of
warnings - is this OK?) and enblend failed. This time with less warnings
and then
"LINK : fatal error LNK1181: Eingabedatei 'libxmi.lib' kann nicht
ge�ffnet werden."
(... "Input file 'libxmi.lib' can't be opened")
(Actually there was one step in between: first libtif.lib couldn't be
found. Had a look at the list of include dirs in the properties and saw
that the entries that I had changed yesterday are not changed/changes
not saved. Changed them again, saved, reopened - not saved again. Could
somebody tell me where this data is stored? Anyway what I don't
understand is that I open *.sln and when I save *.ncb and *.suo are
saved. *.sln is untouched. How do I deal properly with these files?)
Now I look at my no. 6.6 in
http://www.joachimschneider.info/moving_target.html
and see that it reads
1. Download http://sourceforge.net/projects/gnuwin32/files/
libxmi/1.2-1/libxmi-1.2-1-src.zip/download
2. there is a libxmi.sln inside it, just start it.
of which I seem to have done only 1 so far.
There is no *.sln included but only a libxmi.vcproj which I can open in
MSVC.
Set to "Release"When I try "build" it suggests libxmi.sln as output file
name. When I accept this it complains (translated) "The project file
'libxmi' has been changed outside the environment. Click 'load again' to
reload from disk or 'ignore' to ignore the external changes. They will
be used when opening the project next time."
But anyway it builds.
So I give enblend another try: Now it says "fatal error LNK1120: 15
unsolved external references."
BuildLog: http://www.joachimschneider.info/BuildLog_enblend-20081118-01.htm
(The previously announced one is BuildLog_enblend-20081115-01.htm now.)
What I haven't done yet is applying all patches from the zip file and
changing the reference to tiff-3.9.1 to the path in wxWidgets where I
find tiff.h.
This will be the next try. Tomorrow.
Ryan Sleevi schrieb:
Ryan Sleevi
solution properties (right click the solution, properties), you want to make
sure for C/C++ Configuration, that the additional include directories are
specified.
You then need to check under the Linker -> General options that the
"Additional Library Directories" is set to point to the proper paths.
Finally, you need to make sure there aren't any hardcoded paths in Linker ->
Input -> Additional Dependencies
> (Actually there was one step in between: first libtif.lib couldn't be
> found. Had a look at the list of include dirs in the properties and saw
> that the entries that I had changed yesterday are not changed/changes
> not saved. Changed them again, saved, reopened - not saved again. Could
> somebody tell me where this data is stored? Anyway what I don't
> understand is that I open *.sln and when I save *.ncb and *.suo are
> saved. *.sln is untouched. How do I deal properly with these files?)
use. The .ncb and .sou files are internal files used by Visual Studio. .slns
don't automagically save until you choose to Save (or Save All) or close
Visual Studio (when it will prompt you)
> Now I look at my no. 6.6 in
> http://www.joachimschneider.info/moving_target.html
> and see that it reads
> 1. Download http://sourceforge.net/projects/gnuwin32/files/
> libxmi/1.2-1/libxmi-1.2-1-src.zip/download
> 2. there is a libxmi.sln inside it, just start it.
> of which I seem to have done only 1 so far.
> There is no *.sln included but only a libxmi.vcproj which I can open in
> MSVC.
> Set to "Release"When I try "build" it suggests libxmi.sln as output
> file
> name. When I accept this it complains (translated) "The project file
> 'libxmi' has been changed outside the environment. Click 'load again'
> to
> reload from disk or 'ignore' to ignore the external changes. They will
> be used when opening the project next time."
> But anyway it builds.
until you apply the patch, when it is created. Building .vsproj's directly
is not supported by Visual Studio.
> So I give enblend another try: Now it says "fatal error LNK1120: 15
> unsolved external references."
> BuildLog: http://www.joachimschneider.info/BuildLog_enblend-20081118-
> 01.htm
> (The previously announced one is BuildLog_enblend-20081115-01.htm now.)
to begin with helping you resolve the issues, because there are all sorts of
weird things. The "simplest" answer is - You're missing libxmi, you're
missing vigra, you're missing the CRT (or linking against the wrong one)
> What I haven't done yet is applying all patches from the zip file and
> changing the reference to tiff-3.9.1 to the path in wxWidgets where I
> find tiff.h.
> This will be the next try. Tomorrow.
like you're trying to do this on your own, without directions. Are you
trying to follow the steps on the Wiki? The 64-bit build steps contain
everything and every step you need to build enblend-enfuse-3.2 (32-bit or
64-bit). I would strongly, STRONGLY encourage that you walk through those
steps, get familiar with the process, and bring up any problems you have
following those.
Once you've got 3.2, there are just a few more dependencies for 4.0, which
can be easily added.
Unfortunately, I'm not sure if I'll be able to be much more help, and I
don't want to discourage you, but that really is the best path for learning
that I can recommend, and will likely save you many questions.