upgraded to Kubuntu 11.4 - trying to get hugin to work

[kfj]

Hi all!

I've upgraded my Kubuntu system to 11.4, now I'm trying to get hugin
to run on that. I managed to install 2010.4 from the ppa, but it took
some fiddling - I first had to deinstall an old libpano and install a
new one - and I also needed libexiv2-9, which I had to download
manually from

http://packages.debian.org/sid/i386/libexiv2-9/download

since kpackagekit didn't know of it. So now it looks like I have the
readymade running at least. Next thing of course is to compile my own
- after all I want to use hsi/hpi. This is what I get:

kfj@Anja:~/src/hugin/hpi12/hpi12.b$ make
[ 4%] Built target makefilelib
make[2]: *** Keine Regel vorhanden, um das Target »/usr/lib/
libpthread.so«,
benötigt von »src/foreign/vigra/vigra_impex/libhuginvigraimpex.so.
0.0«, zu erstellen. Schluss.
make[1]: *** [src/foreign/vigra/vigra_impex/CMakeFiles/
huginvigraimpex.dir/all] Fehler 2
make: *** [all] Fehler 2

Has anyone been there? Any helpful hints?

Kay

[Kornel Benko]

Am Dienstag, 3. Mai 2011 schrieb kfj:

> Hi all!

>

> I've upgraded my Kubuntu system to 11.4, now I'm trying to get hugin

> to run on that. I managed to install 2010.4 from the ppa, but it took

> some fiddling - I first had to deinstall an old libpano and install a

> new one - and I also needed libexiv2-9, which I had to download

> manually from

>

> http://packages.debian.org/sid/i386/libexiv2-9/download

>

> since kpackagekit didn't know of it. So now it looks like I have the

> readymade running at least. Next thing of course is to compile my own

> - after all I want to use hsi/hpi. This is what I get:

>

> kfj@Anja:~/src/hugin/hpi12/hpi12.b$ make

> [ 4%] Built target makefilelib

> make[2]: *** Keine Regel vorhanden, um das Target »/usr/lib/

> libpthread.so«,

You need the package libc6-dev. At least on kubuntu 10.10 it would be so.

> benötigt von »src/foreign/vigra/vigra_impex/libhuginvigraimpex.so.

> 0.0«, zu erstellen. Schluss.

> make[1]: *** [src/foreign/vigra/vigra_impex/CMakeFiles/

> huginvigraimpex.dir/all] Fehler 2

> make: *** [all] Fehler 2

>

> Has anyone been there? Any helpful hints?

>

> Kay

Kornel

[kfj]

On 3 Mai, 16:31, Kornel Benko <Kornel.Be...@berlin.de> wrote:
libpthread.so«,

>
> You need the package libc6-dev. At least on kubuntu 10.10 it would be so.
>

libc6-dev is installed.

If I ask kpackagekit to look for libpthread, it offers libpthread-
stubs0 and libpthread-stubs0.dev and says they are 'pthread stubs not
provided by native libc'. It finds no other packages.

Kay

[Kornel Benko]

Am Dienstag, 3. Mai 2011 schrieb kfj:

Sorry, since I don't have this system, I cannot help you more.

Searching for the file-list for libc6 gives me for natty on

"http://packages.ubuntu.com/natty/i386/libc6/filelist"

that there is a file /lib/i386-linux-gnu/libpthread.so.0

You could try to make appropriate symlink. (I know, this is hacking)

ln -s whatever/libpthread.so.0 /usr/lib/libpthread.so

and compile again.

Kornel

[kfj]

On 3 Mai, 19:12, Kornel Benko <Kornel.Be...@berlin.de> wrote:

> Sorry, since I don't have this system, I cannot help you more.

I have a good first impression from it. I first did an install from
scratch from a Ubuntu 11.4 CD to a USB drive, and the WLAN worked out
of the box (it didn't on my system with 10.10), and everything else
wasn't too hard to get running either - just suspend-to-RAM I couldn't
get running.

Then I did a distribution update on my productive system, and apart
from deleting core.img from my grub installation, so that I couldn't
boot until I chrooted into it and did an update-grub, all went well.
At least it didn't totally wreck the installation. Silly me for trying
yet again, so far I haven't managed once to have a running system
after a 'distribution update'.

> Searching for the file-list for libc6 gives me for natty on
>         "http://packages.ubuntu.com/natty/i386/libc6/filelist"
> that there is a file /lib/i386-linux-gnu/libpthread.so.0
>
> You could try to make appropriate  symlink. (I know, this is hacking)
>
>         ln -s whatever/libpthread.so.0 /usr/lib/libpthread.so
>
> and compile again.

This libpthread hack seems to work. It got me about 0.5% further -
next in line is libjpeg. I suppose I have a recent version installed,
but there's certainly no /usr/lib/libjpeg.so - they libjpegs on offer
all seem to have version numbers (8 or 62) and I haven't quite figured
out where they are so I can play dirty linking tricks on them as
well... I seem to vaguely recollect having built libjpeg and libtiff
from source the last time round, and the result was installed in /usr/
lib - but per default it's certainly not there:

[ 4%] Built target makefilelib
make[2]: *** Keine Regel vorhanden, um das Target »/usr/lib/

libjpeg.so«,

benötigt von »src/foreign/vigra/vigra_impex/libhuginvigraimpex.so.
0.0«, zu erstellen. Schluss.
make[1]: *** [src/foreign/vigra/vigra_impex/CMakeFiles/
huginvigraimpex.dir/all] Fehler 2
make: *** [all] Fehler 2

I'll look at the matter tomorrow and call it a day now. Thanks for
your help!

Kay

[Kornel Benko]

Am Dienstag, 3. Mai 2011 schrieb kfj:
>

Normally this meant that the respective -dev package were not installed. It was this package providing the links here.

Kornel

[kfj]

On 4 Mai, 07:15, Kornel Benko <Kornel.Be...@berlin.de> wrote:

> Normally this meant that the respective -dev package were not installed. It was this package providing the links here.

Kornel, thank you for pointing me in the right direction. I had to
istall some more packages, but the main problem was that the relevant
libraries were in /usr/lib/i386-linux-gnu and not in /usr/lib. Some
were there with a plain .so ending, some with additional numbers. Once
I'd linked them into usr/lib, the compile ran fine.

The libraries were libtiff, libjpeg, libz, libpng and they were
required for src/foreign/vigra/vigra_impex/libhuginvigraimpex.so.0.0.
Later on I also had to do the same for libSM, libICE, libX11, libXext
and libXi which were needed for src/hugin_base/libhuginbase.so.0.0. I
wonder if my system is lacking a general link that links all stuff
from /usr/lib/i386-linux-gnu into /usr/lib. Or maybe the cmake code
could make the compiler look in there as well if the compile is done
on an intel system?

I managed to build a package from the python_scripting branch and
install it. The resulting hugin doesn't run properly yet (crashes on
loading a pto) but I have an idea what the problem is.

Kay

[Kornel Benko]

The next what comes in mind is: Did you clean the cache-file CMakeCache.txt?

It may well be, there are some old settings valid in your previous OS.

Cmake should be able to find the correct paths...

Kornel

[kfj]

On 4 Mai, 13:54, Kornel Benko <Kornel.Be...@berlin.de> wrote:

> The next what comes in mind is: Did you clean the cache-file CMakeCache.txt?
> It may well be, there are some old settings valid in your previous OS.
> Cmake should be able to find the correct paths...

'clean' it - how do I do that?

Kay

[Kornel Benko]

Am Mittwoch, 4. Mai 2011 schrieb kfj:

I mean remove the build directory. Or alternativelly (on linux)

# cd build-dir

# make clean

# rm CMakeCache.txt

Kornel

[kfj]

On 4 Mai, 18:20, Kornel Benko <Kornel.Be...@berlin.de> wrote:

> I mean remove the build directory. Or alternativelly (on linux)
>         # cd build-dir
>         # make clean
>         # rm CMakeCache.txt

Thanks. And, since I'm building the python_scripting branch, I had to
also issue a new cmake command with the relevant defines:

cmake ../hugin.hg -DENABLE_LAPACK=YES -DCPACK_BINARY_DEB:BOOL=ON -
DCPACK_BINARY_NSIS:BOOL=OFF -DCPACK_BINARY_RPM:BOOL=OFF -
DCPACK_BINARY_STGZ:BOOL=OFF -DCPACK_BINARY_TBZ2:BOOL=OFF -
DCPACK_BINARY_TGZ:BOOL=OFF -DCPACK_BINARY_TZ:BOOL=OFF -
DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_HSI=ON

There was a problem in the cmake code in CMakeLists.txt in the
python_scripting directory, as the Python Version in 11.4 is given as
2.7.1+ in the version string. The detection of the python version is
done quite laboriously and maybe clumsily - it would deserve being
looked at. The code first scans the Python version string:

FILE(STRINGS "${PYTHON_INCLUDE_PATH}/patchlevel.h" PYTHON_VERSION_H
REGEX "#define PY_VERSION")

and proceeds to pick the version from the string

STRING(REGEX REPLACE ".*#define +PY_VERSION.*\"([0-9]+.[0-9]+.[0-9]+)
\".*" "\\1" PYTHON_VERSION "${PYTHON_VERSION_H}")

This doesn't work here (11.4), since the actual string in patchlevel.h
on this system is defined thusly:

#define PY_VERSION "2.7.1+"

(notice the trailing plus). With the RE in the cmake code, this went
terribly wrong; cmake printed this:

-- Python libs version: #define PY_VERSION
"2.7.1+";#define PY_VERSION_HEX ((PY_MAJOR_VERSION << 2

When I modified the RE to

STRING(REGEX REPLACE ".*#define +PY_VERSION.*\"([0-9]+.[0-9]+.[0-9]+).*
\".*" "\\1" PYTHON_VERSION "${PYTHON_VERSION_H}")

(so, allowed for additional characters after the numeric part) It
worked fine, but it might be cleaner to use the #defines for the parts
of the Python version which exist independently in patchlevel.h:

#define PY_MAJOR_VERSION 2
#define PY_MINOR_VERSION 7
#define PY_MICRO_VERSION 1

also the cmake documentation says that:

PYTHON_INCLUDE_PATH - path to where Python.h is found
(deprecated)
PYTHON_INCLUDE_DIRS - path to where Python.h is found

so maybe it' safer using the latter cmake variable. I ended up with
the following code, which seems a bit verbose. Is there maybe a more
elegant way of getting these numbers out?:

# get version of Python libs

FILE(STRINGS "${PYTHON_INCLUDE_DIRS}/patchlevel.h"
PY_DEF_MAJOR
REGEX "#define[ \t]+PY_MAJOR_VERSION.*$")

FILE(STRINGS "${PYTHON_INCLUDE_DIRS}/patchlevel.h"
PY_DEF_MINOR
REGEX "#define[ \t]+PY_MINOR_VERSION.*$")

FILE(STRINGS "${PYTHON_INCLUDE_DIRS}/patchlevel.h"
PY_DEF_MICRO
REGEX "#define[ \t]+PY_MICRO_VERSION.*$")

STRING(REGEX
REPLACE "^.*VERSION[ \t]+([0-9]+).*" "\\1"
PYTHON_VERSION_MAJOR
"${PY_DEF_MAJOR}")

STRING(REGEX
REPLACE "^.*VERSION[ \t]+([0-9]+).*" "\\1"
PYTHON_VERSION_MINOR
"${PY_DEF_MINOR}")

STRING(REGEX
REPLACE "^.*VERSION[ \t]+([0-9]+).*" "\\1"
PYTHON_VERSION_PATCH
"${PY_DEF_MICRO}")

MESSAGE(STATUS "Python libs version: ${PYTHON_VERSION_MAJOR}.$
{PYTHON_VERSION_MINOR}.${PYTHON_VERSION_PATCH}")

... so now I'm up and running on 11.4, with Python 2.7. I haven't done
much testing yet, but loading a pto, getting a preview and running a
python plugin on it worked just fine. Phew.

Kay

[Kornel Benko]

Am Donnerstag, 5. Mai 2011 schrieb kfj:

...

> There was a problem in the cmake code in CMakeLists.txt in the

> python_scripting directory, as the Python Version in 11.4 is given as

> 2.7.1+ in the version string. The detection of the python version is

> done quite laboriously and maybe clumsily - it would deserve being

> looked at. The code first scans the Python version string:

>

> FILE(STRINGS "${PYTHON_INCLUDE_PATH}/patchlevel.h" PYTHON_VERSION_H

> REGEX "#define PY_VERSION")

...

Sorry, I don't get it. Where is this relevant CMakeLists.txt? Nothing appropriate found here.

...

>

> ... so now I'm up and running on 11.4, with Python 2.7. I haven't done

> much testing yet, but loading a pto, getting a preview and running a

> python plugin on it worked just fine. Phew.

>

> Kay

Good work,

Kornel

[kfj]

On 5 Mai, 12:27, Kornel Benko <Kornel.Be...@berlin.de> wrote:
> Am Donnerstag, 5. Mai 2011 schrieb kfj:
> ...> There was a problem in the cmake code in CMakeLists.txt in the
> > python_scripting directory, as the Python Version in 11.4 is given as
> > 2.7.1+ in the version string. The detection of the python version is
> > done quite laboriously and maybe clumsily - it would deserve being
> > looked at. The code first scans the Python version string:
>
> > FILE(STRINGS "${PYTHON_INCLUDE_PATH}/patchlevel.h" PYTHON_VERSION_H
> > REGEX "#define PY_VERSION")
>
> ...
> Sorry, I don't get it. Where is this relevant CMakeLists.txt? Nothing appropriate found here.
> ...

It's in the python_scripting branch in .../hugin.hg/src/
hugin_script_interface/CMakeLists.txt
I think you don't get to see this directory unless you go into the
branch, since it only contains hsi/hpi code. I accidentally said it
was in the 'python_scripting' directory, sorry for the confusion, I
got muddled...

Anyway, how to extract the Python version is probably a totally
tedious side issue. I'll just put my code in the next patch (I'll also
merge default in again to keep everything consistent with default and
make the merge back easy).

Kay