Compiling Code (1/3): qtpfsgui

[Yuv]

Hi all,

I took a few hours this evening to try to compile the software I need
to produce my artwork like http://www.photopla.net/070618assnat/

There will be three reports following, in three separate threads.
Let's start with qtpfsgui.

Reason to compile: the pre-compiled package works well on my 32bit
ubuntu 7.10 but makes a quirky output on 64bit ubuntu 7.04 at maximum
resolution.

I asked Giuseppe for help and he asked me if I can build and test on
my box with a few different configurations. I'm no expert, but once
the dependencies were figured out, it is a straight-forward process.

Dependencies:
# sudo apt-get install libqt4-dev libexiv2-dev fftw3-dev openexr pkg-
config build-essential libtiff-dev libopenexr-dev

First I compiled from the last release:

# wget http://kent.dl.sourceforge.net/sourceforge/qtpfsgui/qtpfsgui-1.8.12.tar.gz
# tar zxvf qtpfsgui-1.8.12.tar.gz
# cd qtpfsgui-1.8.12/
# qmake-qt4
# make
# sudo checkinstall

Then I adventured into SVN, checking out the latest revision which
happened to be 181
# svn co https://qtpfsgui.svn.sourceforge.net/svnroot/qtpfsgui
qtpfsgui
# cd qtpfsgui/trunk/qtpfsgui
# qmake-qt4
# make
# sudo make install

Results: SVN built on both 32bit and 64bit. It worked well on 32bit.
On 64bit it showed the same quirky output at full resolution. I
notified Giuseppe of the bug.

Consequences for me: the last step of my process runs on the 32bit
box. Since it can handle the filesize, the only inconvenience is the
slower performance of the older 32bit box.

next...

Yuv

[Stephan Hegel]

Hi Yuv,

Yuv wrote:
> Results: SVN built on both 32bit and 64bit. It worked well on 32bit.
> On 64bit it showed the same quirky output at full resolution. I
> notified Giuseppe of the bug.
>
> Consequences for me: the last step of my process runs on the 32bit
> box. Since it can handle the filesize, the only inconvenience is the
> slower performance of the older 32bit box.

Wouldn't it be possible to run the 32Bit binary on a 64Bit box ? Sure,
you have to transfer the required 32Bit libraries to the 64 Bit machine.

E.g., on my 64Bit-openSUSE 10.3 I do have to run a 32Bit Firefox just
because there is no 64Bit Java plugin available from Sun and the
ns plugin wrapper doesn't work with Sun's Java.

Here, 64Bit libs are stored in the "lib64" subdirectory whereas 32Bit
libs are stored as usual in "lib".

As of compiling qpfsgui on openSUSE 10.3, qmake for Qt4 is in /usr/bin
(qmake for Qt3 is in /usr/lib/qt3/bin/qmake) when the devel package is
installed. After that the "make" procedure works fine.

Regards,
Stephan.

[Yuv]

Hi Stephan,

On Nov 18, 1:39 am, Stephan Hegel <stephan.he...@gmx.de> wrote:
> Wouldn't it be possible to run the 32Bit binary on a 64Bit box ? Sure,
> you have to transfer the required 32Bit libraries to the 64 Bit machine.
>
> E.g., on my 64Bit-openSUSE 10.3 I do have to run a 32Bit Firefox just
> because there is no 64Bit Java plugin available from Sun and the
> ns plugin wrapper doesn't work with Sun's Java.

thank you for the advice. I see in ubuntu 64bit a "/lib32" and a "/
lib" folder. Similarly I see "/usr/lib32" and "/usr/lib". So probably
it would work. Since I anyway have the 32bit box around and I often
keep them both busy, I can live with tonemapping being done on the
32bit.

Being a noob, I have no idea how the 32bit on 64bit would work. Simply
copying the binary into /usr/bin and the libraries it needs to /usr/
lib32? would compiling qtpfsgui statically make things even easier?
what would I do to compile it statically?

Giuseppe gave me a couple of pointers and when I come back from my
next trip, in ten days, I will be learning about valgrind and
providing him with (hopefully) valuable testing feedback to hunt the
bug. Somehow I am more attracted to bug-hunting than to workarounds,
even if the workaround you suggest seems to be a very simple and valid
option.

> As of compiling qpfsgui on openSUSE 10.3, qmake for Qt4 is in /usr/bin
> (qmake for Qt3 is in /usr/lib/qt3/bin/qmake) when the devel package is
> installed. After that the "make" procedure works fine.

thank you for sharing this information. I created a panotools.org wiki
page for qtpfsgui at http://wiki.panotools.org/Qtpfsgui and linked it
from the HDR Software overview http://wiki.panotools.org/HDR_Software_overview

have a good week!
Yuv

[Stephan Hegel]

Hi Yuv,

Yuv wrote:
> Being a noob, I have no idea how the 32bit on 64bit would work. Simply
> copying the binary into /usr/bin and the libraries it needs to /usr/
> lib32?

Yes, I think so. Plus making the this library path visible to the link
loader by adding it to /etc/ld.so.conf - if not already done - and
running ldconf (as root) to update the ld cache.

A short survey with the "file" command in /usr/bin, /opt/kde/bin and
/opt/gnome/bin revealed that there are more applications which are
32-bit. Among them e.g. wine. Probably they haven't been ported to
64-bit or need to be 32-bit but they work out of the box on my x86_64
Intel Dual-Core PC.

Generally, for openSUSE users it is quite easy as one can select the
i586 version in Yast2 and the required 32-bit libraries are installed
automatically.

> would compiling qtpfsgui statically make things even easier?
> what would I do to compile it statically?

I remember the linker options "-static" and "static-libgcc" but AFAIR
you need the static versions of all libs (lib*.a). However, I haven't
tried this. In case of qtpfsqui this would be a lot of work ... ldd
lists 39 (!) shared libraries here.

> Giuseppe gave me a couple of pointers and when I come back from my
> next trip, in ten days, I will be learning about valgrind and
> providing him with (hopefully) valuable testing feedback to hunt the
> bug. Somehow I am more attracted to bug-hunting than to workarounds,
> even if the workaround you suggest seems to be a very simple and valid
> option.

Good luck to you ... :).

Regards,
Stephan.